直播回顾 | 不谈虚的，给传统企业一份代码级的中台落地实践（2）

近期，网易云做了多场关注数字化转型创新又落地业务的直播，
如果你刚好工作忙错过了，
或者听完不过瘾，还需要直播笔记，
那一定不能错过这个系列——我们将复盘直播内容，划好重点，干货十足！

接上篇：直播回顾 | 不谈虚的，给传统企业一份代码级的中台落地实践（1）

四、中台构建的两种类型和两种模式

接下来会说中台构建的几个方式。

第一个方式比较适合传统企业，叫做封装式。所谓的封装式是说我们采购了很多稳态后台的一个系统，但现在又想快速迭代，那么有的人是不是把这些系统全部拆散了？但传统企业往往不敢担这个风险。但是我又想达到那种可快速迭代的这种稳态的中台的效果，应该怎么办?

我们观察下来比较好的落地方式，就是中间封装一层，封装的这一层是在稳态后台的基础上，把一些前台需要敏捷迭代的功能抽象到中台上去，那么中台可以从后台获取数据，并且加上一定自己的逻辑，对前台进行服务。这样稳态的中台随着不断加厚，这时候就会使中台慢慢的形成了，或者说可复用的这一层就可以慢慢的形成了，而不是说一开始就把下面全打散了，完全变成敏态，这样其实是一个风险相对较高的方式。

像这种封装式其实是相对比较好的，封装式其实有两个步骤。

第一步是维度提升，我们会发现有些企业原有的系统所做的方式想创新的话，其实原有系统里面，它的数据结构也好，它的方式也好，其实不能满足前台的需求，比如说传统的采购和供应链的协同，比如传统的分销和O2O，类似这些都是有差别的，那么那些后台的系统你又没法改，怎么办？其实可以通过中间封装这一层，使得在传统分销系统基础上，再加上自己一定的逻辑来做这件事。那么第一步就是维度要做提升。

第二步是多维重组，也拿制造企业举例，比如说自己有很多东西要对接到电商平台上去卖，一种方式是有一个平台就对一个平台，但大家也知道电商平台或者是各种平台冒得相对比较快了，所以这时候就会有一个多维重组，所谓多维重组就是把下面的功能组合起来，来快速对接的一个方式，在传统的后台和敏捷的中台之上，这时候可能会有一个类似开放平台，或者是一键式服务平台，通过对接后面不同的敏捷中台来形成对前面的一个对接，比如说这家店商需要这样对接，那家电商需要那样对接，那么作为比较薄的一层开发层，这层就可以做到了。

第二种最像互联网公司的方式就是重构式，完全打散。但是对于传统企业来讲，其实不太建议这样使用。一个比较式路径，就是封装式，以及先做维度提升，再做维度重组的方式进行。


四、中台架构逐步演进过程详述：以一个落地案例讲述4个大步骤和25个小步骤

接下来我们看一个例子，这个例子即是网易的方式，我们自己在做中台构建或者可复用能力构建的时候，其实有自己的思路，这个思路比较符合互联网模式，但是又和我们的传统企业客户做了一定的结合，结合完了以后会发现他们有他们的现状，我们用我们的方式，两边取得了一个相对折中的方式，逐步逐层的去构建这个能力，而不是采取一下子上一个类似大平台的方式。无论哪家企业，首先肯定要从单体的一个业务架构开始。

首先，我们要做一定的规划，规划的时候要在架构委员会的领导下做一定的梳理。

（1）要梳理核心业务流程，下面的业务流程是我们内部自己做的时候梳理的内部电商的流程。

我们自己拆的时候，数据中心是data center，它只是个物理的东西，你把中台当成可复用的业务平台，等于说你的业务中有一部分你想把它拆分出来，使得它可以复用。当其他地方需要用到你的数据需要用到你的能力的时候，可以到有一个地方查到你的接口，不用重新开发就可以用了，这是中台。


我们拆之前也梳理业务流程的，并且发现DDD模型还是相对比较好的，但是互联网公司其实并没有严格按照DDD的方式去拆，DDD可能需要在会议室里讨论好久贴标签什么之类的去做这个事情，一开始要把所有的场景想的特别细，但是DDD的整个思路是好的，不过我们的整个拆分的过程中还是逐步去做这个事情。

（2）划分核心业务逻辑，DDD给出了一个比较好的思路，即先不去从数据库的角度去考虑这个问题，而是先从业务流程以及业务领域的角度去考虑。这是一个非常好的思路，因为我们做技术的很多情况下，就喜欢说先看看库是什么样，然后再拆，因为你的库原来的耦合所导致的这种拆分方式可能往往是不合理的，如果从业务角度是不合理的，将来会导致一个问题，就是当你的业务想复用它的时候，发现直接划分也是不合理的，所以比较建议从业务的领域去看这个事情，当然从业务领域去看这个事情，是相对比较符合业务领域的拆分方式。但是同样带来另外一个问题，就是我们的数据库可能不太完全适合这种方式，接下来我们需要逐渐的梳理和拆分，不能因为现在的困难导致目标的偏差，目标还是要理顺的，但是过程我们可以逐步的去做。

右边是我们对电商平台的梳理，相对比较复杂。传统的DDD需要一开始梳理得相对比较细，但是由于我们一开始拆分的时候，其实并不需要拆分的那么细，所以一开始我们业务领域的划分也不需要拆分那么细，因为一开始你是坐在办公室里面的。DDD应该是面向应用的，而不是面向数据库的。但是你一开始做会议室里面你讨论太细的东西，到时候真正拆到细节的时候往往会发现不正确，所以说一开始也没必要，其实做相对比较大的领域拆分就可以了，后面可以上手逐段去调整。


（3）确定界限上下文以及相互之间的关系。比如说我们自己梳理自己的关系的时候，这样梳理的就是每一个组，架构委员会每个组都有代表，每个组都能梳理出来自己组的各个模块之间的关系，以及和其他的模块之间的关系。同样对于我们的客户来讲，我们也是可以帮他梳理出这个领域驱动上下关系以及上下文。

（4）按照领域进行横向的架构拆分，这其实也是领域驱动的一个方式，我们自己也是这样做的，首先拆的时候是先按横向的拆，比如说主页活动、优惠券、订单、支付、用户，将这些先拆开，拆完了以后，在每一个里面又有前端的、基础设施的、应用的、领域的和基础设施，其中基础设施两层，一个是像前面的卡车，另一个是后面的数据库和message，类似这样的方式。但是这几层一开始就没必要再拆成单独的进程了，大家都是统一的进程，每个领域一个单独的进程就可以了。这是一开始的方式，先按领域进行横向的一个拆分。

第二步，试点。规划可能会不准确，那么就需要进行逐步迭代，这时候就需要选一个试点项目来汲取经验，然后培养团队，来建立规范。

（5）构建持续集成流程和测试组合。因为做试点，需要不断的持续进行迭代了，这时候首先要构建一个持续集成的流程，这个流程比较建议一开始就把它构建好，大家都按同样的流程来，等你的业务越来越多的时候，大家才能保持代码覆盖率、code review、接口以及集成测试，都在同一个层级上。我们认为持续集成流程是一个基础。

（6）选取试点业务，横向拆分。领域驱动完以后，有这么多领域，这么多驱动，这时就要选一个进行试点，选的方式其实是有两种，我们经常叫做紧迫性和重要性，这里面其实落到代码级别就是变化多和可复用，所谓的变化多，其实就是紧迫性，它老是变。它变得时候会影响别人，这时候随着新需求的不断到来，最好顺便就把它拆了。这是其中一个方式。另外一个方式就是重要性，或者是大家都可复用的一个模块，可复用的痛点比较痛，这时候就把它先拆了。这两个方式不同的甲方是可以选择不同的业务去落地的，这我们也发现不同的企业在梳理过程中发现自己最紧迫的和最重要的其实是不一样的，但是都可以选出一个先做试点。

我们内部的例子，比如说我选取了一个假设，我们选取了一个重要的，比如订单中心，进行一定的拆分，它原来也是Oracle数据库的，各种串行化的，混合工程，很乱，类似这样一个方式，它能代表非常经典的一个场景。在很多的企业，面临营销领域的话，也会有相应的订单类似方式的存在，所以相对比较有参考价值。

（7）需要注册中心及API规范与知识库。你现在要把订单中心从原来的大的一个叫online的工程里面把它拆出来，这时候肯定需要注册中心了，一般的企业就会想，既然我要注册中心，我用double或者SpringCloud，这事儿就搞定了。从技术角度来讲，这样想其实没有问题的，但是你没有从领导的角度去考虑问题，或者是没有从中台建设的角度去考虑这个问题，我们仅仅注册其实是不够的，我们当时做中台建设的使命就是我们要做可观测性，架构委员会要有一个地方能看到接口是否规范，架构是否有了腐化，有没有一个集装的地方可以review，另外就是可复用性，相当于这个接口注册到注册中心以后，将来有个人要用这个接口，它到底是找文档还是找我这个人，还是去同样一个地方找，所以说我们比较建议除了解决开发之间服务之间互相调用的问题，还要再在它之上封装一个比如知识库，这里面有接口的信息，有接口的文档，这些都有的话，才能解决我们刚才所说可观测性可复用的问题。如果说没有可观测性，那么仅仅是注册发现，照样可以说我拆的不合适，但是照样能不被发现，这个事其实也是存在的。

这时有一个机会去来统一制定API接口规范，来统一的制定API知识库，并且我们要保证文档和运行时是一致的，来减少沟通成本，文档运行时和开发怎么才能一致，这其实是需要CICD流程来进行保障的。

这时候你可以看到，其实已经上了两个组件了，一个是CICD的组件，另外一个这时候要上一个类似这样的注册中心，但是注册中心上面又多了一层封装的知识库，一方面在CACD的流程里面，我们要落一个微服务的接口规范，这个规范其实网易有自己的规范，但是比如说做到甲方以后会和他们商量，再落一个这个和甲方一起的一类似这样的规范，这个规范在CICD的流程里面要落下来，并且在注册中心那边也落下来，这时候整个的API注册过程中就可以比较好的看到这个东西了。

对于网易的产品来讲，我们这边会有一个可以输出的产品叫NSF框架，这个框架并不仅仅是一个SpringCloud或者double或者gRPC或者Istio的技术框架，它上面多了很多管理的部分，通过一个agant的方式就可以起来，这时候里面自然就会有一个可视化的界面，在这里面的注册发现、熔断限流、降级配置，所有这些东西都可以集中管理起来。这时候架构委员会就可以到可视化的界面去统一的去看。

（8）为保证平滑拆分，前端无感知，配备API网关。拆的时候为了让前端无感知，比如说我们的手机端或者我们的网页端无感知的话，往往要有一个API网关这样的东西，就等于说我们前端请求的时候，所有的请求，不能说后端改变的时候，一会拆一会合然后让前端url不断改， 所以还是让url都指向同样一个API网关，这时后面无论怎么拆怎么合，对前端都是透明的。这是一个，这时候又可以上一个API网关，另外还可以做另外一个事情，就是做灰度发布，比如新的订单中心拆出来，一定是好的吗？不一定。领导也不放心怎么办？那么API网关就可以做一个分流机制，先分出1%来，或者是分出一些测试流量来，分出非VIP的流量来，先试一下，不行再马上切回去，类似这样的。

这是一个让整个拆分的过程中相对比较放心的一个东西，这时候已经用了这么几个功能了，就是CICD的功能，注册中心的功能以及知识库的功能外，加上API网关的灰度发布以及服务代理的功能。同样API网关我们也是可以输出的。

（9）微服务拆分的渐进式技术方案，有一个非常小步的迭代、逐渐拆出来的一个过程。这个过程我把它总结成了6个小步骤。但是这个东西其实我们只要拆一次，第二次基本上就知道了，这里不细说这6步到底怎么拆，这个可以讲好久。

竖着拆完了以后，接下来有可能要横向再拆，什么时候横向再拆，就是为了解耦和质量属性。我们在DDD里有时候会说，一个是领域划分，另外一个是质量比如性能的问题，我们解决性能的问题，经常会采取读写分离，有时候会采取分布分表，有时候采取使用缓存，这时候会有什么样的现象呢，就像我们后端的这些基础设施，像数据库缓存每次要变的时候，所有用到数据库的前面都要变。50个工程或者50个进程太痛苦了，这时候怎么办？

（10）为了解耦和质量属性，纵向分层拆分。这时候就会横向再拆，分层的拆分，就是generic这一层，它会把对于下面的，比如说数据库的、缓存的、消息的类似于分布式数据库的这些东西都封装在它下面，一旦缓存慢慢开始换成Redis了，不用影响下面50个工程，只要影响这一层就可以。这时候是说解藕，等于说其实是下面的换了，不需要影响到前面的业务逻辑，另外就等于说我们如果有一些公共的业务逻辑，可以封装在一个compose的公共逻辑层，然后再往前面是一个场景化的业务层，这时候可以分成非常典型的一个三层，这时候要看自己的质量属性，比如说有时候你说我的数据库10年都不改，这时候也没必要拆。但是一旦要，这时候有这么一层，其实是非常好的。

（11）试点业务拆分完毕，总结服务化规范。试点业务完毕了以后，这时候我们能总结出很多服务化的经验，这里面我提取了6条，比如说分几层，引进循环调用，接口异步化，接口如何幂等，工程如何规范，工程名如何规范，类似这些都是有一定的机制的。这里面我们尤其比较建议甲方做工程名规范，就等于说将来在服务治理平台上，APM上、容器上持续集成上，包括开发、测试、发布、运维，所有这些东西全部使用一致的工程名。

这时候无论谁登到任何一个系统上，都知道现在操作了什么，操作的是哪个系统，到底操作的是order还是操作的goods。其实真正的规范可能不止这6条，这是提取出来的大家经常会问的6条，这时候其实任何一家公司的架构委员会，经过我们初期的梳理和拆分以后，比如拆完了第1个，这时候已经可以制定出我们自己服务化的一个规范了，假设你用的dubbo，你可以有double的配置规范、dubbo接口的规范、dubbo接口、dubbo修改定义的规范，SpringCloud是可以的。消息队列有什么规范，服务化的流程有什么规范？接口新增、审核有什么规范？日志怎么打？哨兵式监控系统怎么打？数据库设计应该怎么弄？工程应该什么样，日志打点一个什么样，会有一系列的规范。当然我签的这列的规范是互联网公司的规范，那么那么因为传统企业他自己也有了架构委员会，在整个过程中它也会形成一个自己规范，比如说用到消息队列，那么我们就会建议消息队列应该制定一个类似这样的规范，他说我有一个日志打点的需求，那么这时候可能也可以参考我们的规范去形成他们自己的一个规范。

（12）如何保证规范落地，质量看板，流程保障，绩效考核。下面是一个持续集成的流程。

每家公司可能不一样，但是这里面我们看到了有很多的小人，这些小人在每一步的卡点的一个人的审核机制，比如说我们这里面列举出来CI的分支，它要过这样的一个流程，我们看到是有代码覆盖率、类覆盖率这样的。质量还有看板，有红黑榜，谁的代码覆盖率太低了，谁的测试通过率太低了，类似这样的都会有一个看板。临上线之前每一个质量卡点的指标，也会有整个的测试级，我们有一个测试工具也是可以输出的，是一个测试平台，这个测试平台可以把很多的集成测试放到里面去做。这时候效能也有看板，应用的质量、产品的质量以及迭代的速度，线上bug，类似这样的一个方式，正是这些看板以及前面所有的规范，这些看板可以和这些工具进行对接的， 使得整个孵化过程中领导层包括架构委员会就可控了。


可控了以后，接下来就要做第三步，服务化。

（13）架构委员会的组织服务化分组，分组拆分。试点结束，我们就要在架构委员会的领导下，在服务化规范的指引下，各组开始制定里程碑计划，逐步进行拆分。比如说我们先分组，原来的工程是什么？打算怎么划分？具体的工程名字是谁，域名是什么？负责人是谁？工程是？计划什么时候拆完？类似会有这么一个表格，放在wiki上也行，放到哪里都行具体看各个公司的情况。

（14）每组制定里程碑计划，定时向架构委员会汇报。样例拆完后，架构委员会开始定下各个组，各自按领域分好组以后，各组可以开始做各组的服务化，这时候可以制定一些里程碑计划，比如说订单中心，自己定了一个服务化的计划，交易链路定了一个，商品中心定了一个，促销定了一个，这都是我们自己定的一个计划，把它贴到右边，就是我的功能是什么？我打算把什么东西切到什么东西，谁负责开发这个东西？大概什么时间点完成，其实中台就是架构的一个落地，所以叫落地实践了，无论前面说再多的概念，落到最下面还是一些架构的设计以及代码的设计，还有规范的一个设计。

（15）微服务拆分数目多，运维受到压力，容器化。制定了里程碑计划以后，接着就开始分组做拆分了，开始拆分了以后，那么微服务拆分的数目多，这时候就可以做一个容器化，比如说简化、运维类似这样的方式。

对于大规模容器平台的建设，网易其实也有一个最佳实践，后面的课程会详细讲。网易的容器平台其实也是可以输出的。PaaS中间件其实是基于Kubermetes Operatoe来构建的，我们也会专门有一个session去分享中PaaS中间件。

（16）服务拆分多，定位问题难，全链路监控，这时候会上一些全链路监控的一些工具，我们也会有一个APM这样的工具存在，业务有时候也会做一定的监控，这时候业务就会有实时大盘，也是可以输出的。

（17）微服务拆分数目多，统一日志中心。另外有日志中心，日志中心其实也是有一定的最佳实践的，采集、缓冲、筛选、存储、检索、展现怎么做？

（18）微服务拆分数目多，统一配置中心。配置中心我们的产品里面也有。

当遇见互联网场景遭遇性的问题的时候，进一步就开始要做第四步，微服务化。

做微服务化就到了后面的步骤了，其实传统企业走到这一步的协议相对比较少，但是为了完整性，我还是把这块大概说一下。

（19）为支撑高并发，进一步拆分，性能优化。第一个是可能会进一步拆分，比如说核心下单逻辑，它的性能实在是太受影响了，那么我们建议把它独立出来。另外还有一种方式，比如搜索把它独立出来为了应对联合查询，另外缓存是一个应对性能非常好的方式，那么缓存也应该给它采取一定的机制，比如说我们把商品服务分成前台和后台，前台访问缓存、后台定时刷新缓存，类似这样的一个机制。缓存其实也是有一定的最佳实践的，比如说我们总结出来缓存有5种场景，有3种刷新的一个策略。我们有的客户是有高并发的场景的，比如像物流业这样的，那么它就可以用类似这样的策略去做相应的事情。

（20）服务治理，防雪崩和请求堆积，这就需要一个服务的治理平台，就是我们经常听说的熔断、限流、降级所有这些工具。

（21）服务多，去Oracle，配备分布式数据库和分布式事务组件。当服务多到一定数目，Oracle就撑不住了，这时候就需要去Oracle入口，使用分布式数据库DDB。Oracle切换DDB这个流程还是相对比较复杂的，好在我们自己也做过一次，所以其实也积累了一定的最佳实践。

（22）另外多服务的分布一致性可以用类似分布式事务，比如TCC、事务消息，类似这些都可以用。网易是有分布式事务的中间件存在的，其中部分后面的课程会单独讲。

（23）容器化之后，比如测试环境多可以做流量染色。

（24）全链路压测，承载高并发。

（25）多机房高可用以及单元化。

总结：

可能会有人说太细了，其实观察到大部分传统企业做的时候，互联网公司一般经过23个步骤，基本上都会到第三部分也就是服务化，大部分全链路压测都会做，我们熟知的互联网公司其实都会做。但是传统企业现在大部分处在先做规划，再做试点，以及做服务化的三个阶段，甚至有的先做规划，接着做了一定的试点，并且现在服务化在逐渐进行的过程中，正在走服务化的阶段。