欢迎大家来到IT世界,在知识的湖畔探索吧!

系统设计概述

1.核心模块设计图

1.1研发总设计图

1.2核心设计：版本控制逻辑图

1.3核心业务系统的运行逻辑图

1.3.1单体项目

1.3.2前后端分离、API独立、单体架构

1.3.3前后端分离、API独立、分布式微服务架构

1.3.4前后端分离、API独立、分布式微服务架构（版本控制）

1.4.概述图

2.Vcc版本控制中心

下面我介绍一下版本控制中心。

先思考一下，我们为什么需要做这样的版本控制中心呢，什么样的场景才需要做，它实现了哪些功能，解决了什么痛点？首先如果当我们的项目使用微服务架构时，当前项目肯定是分布式部署在N台机器上，也有可能这些机器是异地部署，跨机房部署。那么有一天，生产环境在下单、交易或者其他重要业务逻辑的使用过程中突然发生异常错误，导致大量的用户无法正常使用。如果我们不能及时的响应、及时的恢复代码至有效版本的时候，那公司的损失无疑是巨大的。当系统出现异常错误如果发生在程序员下班后，往往没人能够及时的查找问题点并解决系统BUG，因为排除肯定是一个耗时耗力的过程。为了不给公司带来经济损失，我们这时候就需要用到版本控制中心，它可以随时将代码恢复至任意一个历史的版本（当然一般是恢复到最近的一个历史版本），其他各系统业务之间的调用也根据版本号来读写相关数据，版本控制中心的出现就是为了解决以上的痛点，因为它真的是可以快速解决问题，那么等待程序员第二天上班或者花费1-2个小时排除也不会给公司带来太多的经济损失，这就是它的优点和存在的意义。

当然仅仅依靠版本控制中心系统是不能处理以上问题的，这里还需要依靠其他系统配合，最终组合成一整套系统架构才能完美的解决以上问题。那么也有人会问：如果我把所有分布式环境的的代码版本都给还原了岂不是不需要你这个架构了? 问的好，我先讲一下这种传统方法的缺点：如果底层逻辑层代码分布式部署在10台机器上，web、小程序、app都通过网关随机调用任意节点接口返回数据，如果一旦线上代码发生重大问题，可能出现问题的也只是web、小程序、app其中一个调用发生异常，另外2个没有调用异常，本质上最新代码对另外2个项目不受此影响，也就不需要对这10个节点都还原，如果通过我的架构，我至少只要还原其中2个节点，让出错的一个调用方比如小程序端，只读取这2个节点服务器的接口数据，而不需要把所有10个节点服务器的代码都给还原了。如何理解这些话呢，下面让我先介绍此系统是如何通过版本控制中心互相调用接口数据的。

我们先看第一块逻辑图

web、移动app、小程序中间通过一个接口调用层api，它负责处理简单的调用层的，并不包含和谐的逻辑层数据。为什么要这样分离呢？

这里的接口调用层api和业务逻辑层接口API为什么要分开写，是因为调用层不建议也不要把核心的业务逻辑代码写在里面，调用层一般只编写当前调用者所用的简单逻辑，比如记录登录的token、session等或全局的一些基本信息、判断前端如何显示的一些基本逻辑。所有核心逻辑代码均编写在业务逻辑层API接口中，因为只要写到某一个核心功能的增删改查的接口，那么就可以提供给任意调用层api去使用。如何理解呢，比如你调用层有web网站、移动app、小程序3方，那这3方不需要重复的编写某一块增删改查接口的功能，这样往往是冗余的工作量，也不便于后期的维护。所有核心业务逻辑都写在业务逻辑接口层，那么只要改这一个地方，其他3个调研方则可以直接调用无需改动代码。

现在我们回到重点，第一块逻辑图是比较常规的比较传统的部署模式，基本所有3个调用端，都是随机的从5个节点任意的分配，这种传统的基本可以不需要用到版本控制，大部分公司也都是这么干的。

这种基本缺陷比较大，就像我们上面说的，如果一旦发布的最新代码有缺陷，那这5个节点的代码甚至更多节点的代码都要回滚至上一个版本，这样太麻烦了。下面我们介绍另外一个版本。

也就是我们第二块逻辑图

第二块的核心思想其实就是当我们某一次发布最新代码，最新一个版本上线，如果其中包含的某一些内容对我们web、app、小程序的任意一个调用端造成重大事故，我目前所画的是内容是针对小程序没有任何影响，比如小程序调用的是2个节点的接口，他们的版本是2.3.0.0。而移动端app可能BUG影响需要将其中2个节点服务器的代码还原到2.1.0.0的版本，web受此影响需要其中一个节点还原到2.0.0.0的版本。那这样的话每个调用端都各自指定自己需要访问的哪个版本号，指定明确通过网关和我们的版本控制中心，就可以做到按调用端指定的版本号来调用逻辑层所对于的版本号的服务器节点。

重点：以上说了这么多，肯定有人无法理解，也有很多疑问。那通俗的讲，假如一家上万人的大型互联网公司，某一个部门有100个研发人员同时研发一套系统，他们在某一天当中如果接收到某个大任务，平均以10个人为一组，来开发不同模块逻辑，下班前这10组人员都将代码推送到主分支，由管理人员统一发布到正式环境。如果其中某一组的10个人当中有人提及的代码存在重大bug，导致部分业务上线无法使用，可能只是小程序业务受此影响，那么PC、app没有问题，且没问题的这2个业务在线上正在使用，无法撤回至上一个版本，那在业务逻辑处理层我们只需要将其中几个部署的节点（为小程序服务的节点）撤销至上一个版本，那这时候至需要对业务逻辑层代码进行回滚，并将调用接口层API的服务版本调整到业务逻辑层回滚的版本即可。

上面只是业务如何运行的简单介绍，版本的核心控制逻辑均位于vcc版本控制中心和jenkins（定制化二次开发过的版本）当中。

下面我附上几张Vcc的系统截图：

3.Ocelot定制化的网关（版本控制）

Ocelot是我下载的官方开源的项目进行了二次开发，在原因代码的基础上增加了版本控制逻辑，由ocelot去调用vcc版本控制中心系统接口，返回当前项目所需的服务地址（如果一个项目在微服务的架构下部署了N个节点，那么每个节点都有对应的IP、端口号）。当项目按指定版本号去调用相关服务节点（每个服务自身都有对应的版本号），也就是调用曾API发出一个请求，该请求首先经过网关，网关调用vcc去寻址（寻找对应节点下的版本api接口），一旦找到后立马返回给网关做负载均衡调用。

这样就形成了一个闭环，当然在众多业务，高负载的情况下，该网关也是可以多节点部署的（每个节点可以部署一定量的服务）。当然也考虑到高负载，大量请求经过网关，网关频繁调用vcc版本控制中心接口，导致vcc的压力巨大，从而down机。我也考虑到这点，所有服务节点数据，我均存储在redis当中（redis做了集群管理：3主3从）。

下面我附上核心模块部分代码截图（网关的3种模式我只贴上其中一种）：

4.SkyNetLog天网日志

4.1首先贴上系统的截图

4.2其次是天网日志中心逻辑图

4.3大致思想

传统模式下，如果一家公司有成千上百个项目，每个项目可能都会内置一套日志模块，往往每套系统可能在当前项目下都会产生大量的系统日志，随着日志量越来越大，在不考虑硬盘空间的前提下，首先系统数据库的增删改查的速度可能会下降，第二，研发或运维人员需要在不同系统之间切换着查看日志，这反而很不方便，令人诟病。如果再遇到极端的bug，一个功能操作下来，可能该功能由多个系统接口共同完成一个功能模块的计算。

那这时候我们不知道是哪个环境哪个模块会造成此bug，那这时候我们可能把这些涉及到的系统都依次登录，依次打开这日志做对比，做分析，然而每套日志的结构可能也不一样，分析起来让相关人员非常的头疼。那么有没有这样的一套系统，我们对日志结构进行统一，所有项目的业务日志都存储到一套系统中，这样我们只需要登录一套日志系统，就可以查看所有项目的相关日志。

让我用2副图介绍一下

传统模式下，每个系统都内置了一套系统，所有日志都是在每天独立的项目中查看，这里有很多缺点，比如：

1.每个独立业务都有各自独立的数据量，这些日志都存在在该项目的数据量中，年复一年，日志数据量大概十万、百万级，整个业务库的查询效率都会大打折扣，严重影响业务库的执行效率。

2.各个系统如果对接相关业务接口，每个业务的日志存储结构不一致，如果发生重大问题，像上面介绍的一样，需要切换几套系统联系起来分析，实在很不方便。

第二种模式：

我们将所有业务的日志统一存储到天网日志平台，这样优点是减轻各业务的数据库压力，也方便各业务系统的日志查询，极大为研发人员提供便捷。

4.4业务方代码截图

这里我贴上相关代码截图，首先是各大业务的日志发送入口。

其次是nuget包中自己封装的日志接口代码截图

4.5天网日志web平台核心逻辑

当各大业务系统通过API将日志数据发送到web平台中后，系统将在消息队列中逐一的接收、消化掉相关日志消息。

同样的问题，考虑到成千上百个项目都统一的发送大量的日志到该Web平台中，那日志中心的系统压力无疑是巨大的，我这里也是将所有业务逻辑均已微服务架构（利用Nacos）部署了N个节点，每个节点都有独立的消息队列。这样无论哪个节点接收到日志数据，都会在该节点中的消息队列中排队消化存至数据库或ES当中。

当然我是做了2种模式，一种是mysql、一种是ES，可以通过apollo的参数配置随时切换。那么核心的数据我还是存储到了ES当中，具体的优点如下。

重点：系统支持存储到mysql,oracle,sqlserver。但是都会带来一个问题，数据量达到上亿量的时候，我们的日志查询会变的异常缓慢。有没有一种查询效率很高的系统呢，那么ElasticSearch绝对是不二人选，它的查询效率比传统的查询高出N个级别，支持集群部署，支持海里的，PB级别的大数据搜索，并且支持聚合分析，关键词搜索等等。那我们将日志的相关数据全部存储到elasticsearch当中，查询效率非常高，基本是秒级。

这里设计我也有个巧妙的地方，看图：

系统分为天眼标识、服务名称、API模块、方法名。这里具体是什么意思呢？

首先每个部门的总业务项目都有一个唯一的项目ID,每个总项目可能分了部门的几个子业务项目，每个子项目都有各自的子项目名称，那么这些项目各自都有很多控制器contorl、每个控制器下有N个方法。那记录日志肯定是要将以上的信息全部带入到日志中，这样业务人员才可以根据以上信息去准确无误的筛选出日志的出处和日志内容。

4.6天网日志核心业务方代码截图

4.7 Es核心代码模块截图

5.Jenkins二次开发

Jenkins从前期的测试，研究，到后期的二次开发前后准备了有1年多的时间，重点是中间很多技术问题需要长时间的研究、查找资料。网上公开可用的资料很少，都得自己琢磨。其中powershell脚本的开发调试就用了几个月的时间，具体内容请看下文。

5.1主系统截图

5.2二次开发相关核心介绍

5.2.1发布、回滚配置

5.2.2发布直接的ip服务器

5.2.3选择所需要发布的环境

5.2.4指定发布项目的具体环境

5.2.5发布的具体项目版本

5.2.6具体核心powershell脚本部分代码截图

5.3核心思想介绍

为了配合vcc版本控制中心系统的版本控制，需要开发一套自动化编译、发布、回滚的CI/CD平台。目前开源的项目只有Jenkins可以用，但是官方的jenkins只是一个空白的容器，所有的功能需要自己独立的下载各类的插件，独立编写相关的脚本进行二次开发，只因为它支持编写各类脚本，给了我二次开发的机会。

目前我的jenkins部署在windows环境，首选当然是powershell脚本最为合适，当然部署在linux环境可以利用shell脚本编写。研究这些脚本来实现我的代码逻辑，也是研究了一段时间。

首先为了实现代码的编译、发布、回滚，就要为此开发一套平台为此提供接口（vcc）,5.2中的相关截图都是通过脚本和接口来实现相关逻辑的，下面让大概的介绍一下逻辑：

1.根据用户选择的模式（发布、回滚）执行相关的操作。

2.如果用户选择的是发布操作，那么需要根据项目本身的相关信息，去gitlab中拉去相关代码，拉去完毕后自动进行编译发布。

3.发布后的项目中生产项目的xml文件，利用次xml文件回传至vcc版本控制中心，根据内容判断该项目是否新增或修改了控制器、是否新增或修改了相关控制下的方法，一但判断有任意的控制器、方法有变更的操作，vcc会反馈给jenkins，告知用户必须要在apollo中自行升级版本号（x.x.x.x，如果是控制器变更需要升级第二位，如果是方法或者参数变更需要升级第三位，如果只是业务逻辑变更可以变更第四位，但第四位必须必须的！），这时发布工作将被取消，待用户升级版本号后，可以再次执行发布操作。以此图介绍

4.每次发布操作，一旦通过API接口检查版本号验证成功后，需要再次在内部调用接口将每次发布的数据记录在数据库中，下次再次发布项目，需要利用上一次的xml进行对比，所以每次都要存入xml文件，这里逻辑比较复杂，不再此阐述，以此图介绍：

5.一旦发布成功，还需要在内部进行生成当前项目可以用的分布式节点的IP、端口号，为ocelot网关的接口提供相关数据依据。每次发布都会更新该服务的数据，保证每次发布后都是最新的数据，同时将服务的数据记录至redis集群中，减少ocelot调用vcc的压力，以此图介绍：

为了后期项目可以执行回滚工作，内部模块还计算了相关发布数据，以此图介绍：

6.回滚操作基于已发布的记录之上，需要只少有任意一次发布成功的操作。回滚时，用户需要选择对应的版本号，执行回滚操作，以此图介绍：

5.4jenkins解决编译缓慢问题

不管是windows还是linux环境，随着编译的任务增多，jenkins会在系统的运行目录中生成大量的temp缓存垃圾，windows环境倒是好找，手段删除即可。在linux环境找起来相当费劲。但是windows也不能说一直靠人工去清理，肯定是要写出自动化脚本定期清理掉。

那么问题来了，如果众多任务在编译执行中，我们的自动化定时的脚本如果在编译的时候执行清理任务，那一旦清理掉，编译任务会立马终止，这肯定是矛盾的。既然这样肯定是要解决的，于是我尝试翻阅大量的jenkins官网文档，询问chatgpt，都没相关解决方案，只能说提供了一定的方向，而且jenkins也没有提供相关的功能，也没有相关的接口，这就头疼了。

还好我发现了一个隐藏的api（一般人根本找不到！），这个api本质上没有说直接提供哪些任务是正在执行的（只有说api返回给我们没有任务执行，我的定时清理任务才能执行清理工作）。

没事我找到了激活成功教程的办法，请看：

定时任务清理的脚本比较复杂，我实验了将近2周才搞定：

6.Nacos微服务管理中心

具体nacos可以查官网的说明文档：

https://nacos.io/zh-cn/docs/what-is-nacos.html

以下是我的环境截图：

所有底层服务必须要注册到nacos中，为此我还开发了一套基于netcore环境的nacos包，为什么要自己开发呢，因为nacos是阿里基于java开发的开源项目，netcore需要用必须要定制自己的包。

每个业务项目中需要用到nacos的包，同意ocelot网关中也需要引用nacos的包，以此图为例：

所有项目的nacos配置统一的存在apollo进行管理。因为是开源的，这里不做过多的阐述，以此图为例：

7.RabbitMQ消息队列

当前市面上mq的产品很多，比如RabbitMQ、Kafka、ActiveMQ、ZeroMQ和阿里巴巴捐献给Apache的RocketMQ，具体选择哪个看自己的需求，当初我额也是对比了相关产品的参数，每个人都有优点和缺点，找到适用的才是最重要的。

在我的项目中，我选择了RabbitMq消息队列，目前主要用于处理订单等相关业务项目，当业务的生产端发送出相关数据，消费端按队列依次消费掉。它的优点很多，比如应用解耦、异步、流量削锋、数据分发、错峰流控、日志收集等等。

目前我开发了一套netcore项目，内置了推送模式、订阅模式、主题路由模式。

生产端我已打包成nuget包，所有项目均可以在nuget中应用，消费端配合windows服务可以打包部署安装在windows服务中（其中jenkins也支持一键部署安装windows服务在任意的机器中）。

在业务项目中，只要在nuget中拉取安装了消息队列的包，完全可以用一行代码解决消息的发送问题，即简洁又方便。如图所示:

当然消费端也必须要定制相关业务的处理逻辑代码，如图所示：

8.ScheduleMasterCore统一任务调度中心

ScheduleMasterCore是net开源代码中比较和的项目，目前还没有完全可以替代它的比较好的产品，至少是net行业。为什么要选择它，重点还是它的配置比较丰富，支持单独部署（大部分业务都和项目本身进行绑定，这样对业务可造成负载压力），最让我喜欢的是它支持多节点部署，多节点执行任意一个任务（如果部署了N个节点，对于单个任务可以选择多节点执行任务）。

重点问题来了，有了定时任务平台，那必须得有提供相关定时任务的API接口层，大部分公司为了方便，直接把定时任务的相关业务API写在主线程的项目当中。不是说不可以，小公司小业务确实可以这么做。当项目业务复杂度增高，基本不能满足，主线程业务代码将会变的很重。

往往定时任务的代码主要是处理大范围数据或重点业务，执行起来，可能很吃内存和CPU，如果和主业务放在一起，那么服务器也会达到瓶颈。这种情况下必须要独立出一个项目，将核心的定时任务处理业务逻辑写在jobapi项目中（数据处理交给业务操作数据层：jobapi调用resourceapi项目执行相关数据操作）

同样，如果有客户需要合作，双方需要对接相关业务接口，所有对接的业务逻辑也不能和主业务写在一个项目中，需要独立分离出一个项目进行维护、部署，道理和定时任务的jobapi一样。

具体的业务逻辑图如图所示：

9.Sqlsugar nuget包定制

为什么要自己定制sqlsugar包，大型互联网公司遇到了什么问题？那么它解决了什么问题？想必大家也经常听到某某公司的研发人员删库跑路了，某某公司的研发人员窃取公司的数据库数据进行贩卖，等等的一系列危险行为肯定是要想办法杜绝避免的。

如果处理？那必须要做的第一步就是要在项目中完全的删除任意数据库的连接配置，杜绝数据库字符串显式配置在项目文件中，所有开发人员均无法查看到该敏感配置，这样他们也无法使用第三方客户端进行更新操作（无法删除新增更新任何表和数据）。

如果要查询、更新、删除数据怎么办，大型互联网公司为了数据权限管理，肯定是会自研或购买市面上比较成熟的web数据库。这里我不得不提一下WebCatEE，目前同程可能也是向这家公司购买了版权，后期进行了二次开发，因为我看大部分功能基本是一样的。DB数据库管理人员会给研发人员测试环境完全的查询、修改、删除权限，正式环境只给查询功能，如果需要修改、删除全部走工单申请。

现在我们回到重点，我们如何定制这样的包，如何在项目中完全删除数据库连接字符串，那么先看看我的项目是如何应用的，如图所示：

初始化数据库连接

其实就使用这一句代码即可，怎么样能做到这点，那必须要定制一套，如何定制，需要下载开源的sqlsugar.ioc项目，需要单独写相关逻辑，如图所示：

所有的配置只有公司管理人员为每个项目单独配置数据库连接信息，如图所示：

10.Apollo统一配置中心

由于很多业务的需要，配置系统参数需要立马生效而不需要重启整个项目，那必须要一套可靠的配置中心。携程开源项目刚好解决了这些问题（目前有很多产品可用，目前开源中最受欢迎的还是apollo）。

在我的业务中，我配置了4个环境：开发、测试、预发、正式。如图：

在每个业务项目中，配置好apollo的连接配置，还需要再写一个独立的方法读取apollo的配置，大部分人的会写一个很复杂的方法去读取，并且无法自动化赋值到相关model实体中（大部分人都是用最普通最不方便的方法：每次人工的传入需要用哪个参数，再取哪个值），为此我独立的写了一个比较简便的方法，几行就搞定了，如图所示：

通过这个方法，我在需要读取配置的地方直接调用，这样的好处是直接将所有配置自动转换成实体，后面使用直接运用实体来取值，如图所示：

但是随着业务的深入开发，有时候需要在特殊的业务环境中需要对apollo的配置进行自动化更改、发布（比如我的jenkins回滚时需要apollo中的版本进行降低）。我在互联网上寻找了几周，chatgpt也提供了相关方案，无一例外全部，没有任何用，于是我需要自己动手开发一套apollo的接口。

目前我基本实现了新增、修改、删除、发表的通用接口，并发布到nuget服务器（目前github、gittee中均无类似的接口，我也是翻看了携程开源的代码逐步分析调试出来的）。如图所示：

引用也是很简单，如图所示：

11.Gitlab代码库

Gitlab代码库目前是开源中比较好的项目，支持在linux环境下利用官网的release包安装，或直接使用docker部署。

如果需要将代码映射到外面，相关的配置比较复杂，目前我也实现了，不过不建议映射，避免不必要的被黑的风险（虽然被黑了拉去挖矿了）。目前我是利用源代码部署的，实现了ssh、http的代码拉取、推送等功能。

12.Openvpn深度定制开发

目前官网开源的openvpn只有一个exe的安装包，如果需要利用该软件在公司内部继续部署，必然少不了2种模式：

1.分配密钥，每个用户安装后还需要公司提供密钥才能访问，员工如果离职，公司还得写脚本在服务器段删除密钥，这样缺点是很难运维！

2.服务器端自己写复杂的脚本，并且在windows、centos环境中还需要自己写相关复杂的账号密码验证脚本，并且这些脚本网上很难找到几个有用的配置。

总体来说这2种模式对于没有相关知识储备，根本配置不出来。

目前我自己研究了一整套在windows环境的config配置脚本，重点是根据相关的脚本，为了给公司的运维人员减轻运维压力，我又独立开发了一套web管理端，所有的配置、权限、日志全部可以在web端进行控制，员工账号可以直接在该系统中进行新增账号、重置密码、禁用、删除账号，所有访问记录均保存在数据库中，目前市面上还未查看到第二套类似的系统，至少github中目前没有。客户端、服务端的配置代码我就不贴出来了，毕竟也是我的核心计算，网上基本也很难找全相关配置脚本。

目前系统的架构为：前端利用antvue开发、后端利用netcore6开发、并利用nacos微服务、ocelot定制化的网关进行开发。系统截图如下：

用户管理

日志模块

那我为什么要开发这样的东西，一方面是方便我连接家里服务器环境，一方面是为了以后的公司需要，而提前开发出这套产品！

13.MinIO文件存储对象

由于项目需要，很多情况下项目会有很多附件、图片、offcie等等需要上传至项目服务器，大部分小型项目都是内置一个文件路径，通过代码直接上传。这样是最基础的做法，随着项目的不断变大，文件的大小，硬盘的空间收到很大限制，项目管理时候也很容易误删、或者服务器系统崩溃、被黑都会导致文件丢失。

那这时候就需要独立部署一套文件服务器，将公司所有的文件统一存储到一个地方进行集中的管理，目前市面上有很多产品，百度、阿里都有付费的产品，而免费开源的项目minio就非常时候我们，我就喜欢这样的不要钱的产品。

有了这套产品，我们还需要单独写一套文件管理的系统，为其他业务系统提供可靠的API接口，该项目利用微服务做了多节点部署，如图所示：

那么项目如果调用这个接口呢，可以利用jquery、也可以通过后台代码直接将文件发送至该接口即可。

14.Elasticsearch

搭建了ES服务器，目前只要业务范围是为天网日志中心提供服务，目前所有项目的日志数据均切换至ES当中，并开发了相关web平台操作Es当中的数据。

对应电商公司、或者搜索引擎公司而言，他们基本会利用ES的分词搜索特性来为用户搜索相关产品、信息等数据，对于我的业务而已，基本还是日志为主，根据个人项目来定制就行。

对应ES在netcore项目上运用，很多研发人员喜欢自己拼接脚本（习惯类似在代码中自己拼接sql脚本），本质上都可以，看个人喜好，有些人基础好的，能熟练掌握ES脚本的，那完全可以自己拼接。但是对于不熟练的人员而言，能简单最好，这样也利于后面的人来维护，降低维护成本，基于这个思想，我研究出一套方法，基本增删改查都能通过几行代码解决，思想类似于sql的ORM，基于关系型，通过对象直接操作，而无需拼接脚本，如图所示：

对于喜欢使用客户端来拼写脚本的人而言，我这边也推荐一个好的开源工具cerebro，如图所示：

15.Redis集群服务器

目前做了3主3从，众多业务,但节点的redis已经不能满足业务需求，为了防止雪崩，有必要将redis做集群部署。

16.MyCat

由于我所有项目用的都是mysql，随着业务量增大，读写达到一定的瓶颈，读写性能越来越慢，急需分库分表，这里分不开2个概念：垂直分派、水平分片。

垂直分片是将一个数据库中的表按照列进行拆分，每个分片只包含一部分列。例如，将一个包含用户信息的表拆分为基本信息表、联系方式表、详细信息表等，每个表只包含特定的列。这样可以将不同的列存储在不同的分片上，从而实现数据的分离和扩展。

水平分片是将一个数据库中的表按照行进行拆分，将表中的数据均匀地分布在不同的分片上。例如，将一个包含订单信息的表根据订单ID进行拆分，将不同的订单ID分布在不同的分片上。这样可以实现数据的并行处理和水平扩展。

MyCat提供了分片规则的配置和管理功能，可以根据具体需求进行垂直分片或水平分片的配置。通过配置分片规则，MyCAT可以根据查询的条件自动路由到对应的分片，从而实现对分片数据的访问和操作。

需要注意的是，垂直分片和水平分片都需要考虑数据一致性、事务处理、跨分片查询等问题，因此在使用之前需要进行详细的规划和设计。同时，分片也会引入额外的管理和维护成本，需要权衡利弊来选择是否使用分片方式进行数据库扩展。

17.Portainer容器管理平台

目前我的众多系统中，也有很多是利用docker部署的，这么多的docker必须要利用一套平台进行集中管理。市面上有很多产品，可是我钟爱这一款portainer。

18.Baget—nuget管理器

对于自己定制的一些包，必须要一套nuget管理器，目前baget值得推荐，但是也考虑到项目本身安全性的问题，这些包都是在公司内部网络才能访问、加载，如果有研发人员将源代码拷贝走，脱离内网，源代码是无法编译通过的！所以公司环境下有必要整一套！

19.WebCat网页版数据库

既然WebCatEE是收费的，一些大厂不差钱肯定会购买，虽然它功能很全面，但是对于个人而言，时间充足，就是想自己开发。开源类很多大神利用Java、php开发出类似产品，但都没有一个能媲美WebCatEE。

既然这样，我纠结了几个月最终还是下定决心得自己开发一套，带权限管控、工单审核、SQL脚本纠察、日志追踪等基础功能。目前几大核心功能我基本实验成功，vue前端页面上刚开始设计页面，目前也是抽出很多休息时间，不带娃不出门，加班加点开发中。

20.Exsi虚拟化平台

目前企业主流的虚拟化平台主要分为这几种：Haper-v、Exsi、云服务、包含自建的堡垒机群等。我习惯使用Haper-v、Exsi，并且这2种也使用了近10年。我家中的服务器基本是以EXSI为主，所有系统均部署在上面,正是有了它的支撑，我才能实现各种想法和目标。