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

《网易轻舟“中台落地实践”系列直播课程干货回顾》

第1篇 | No.1 

本文12900字，阅读约需22分钟

网易云编辑部整理

—— 以下是正文——

为什么这个题目叫《不谈虚的，给传统企业一份代码级的中台落地实践》，其实在春节前有一波讨论中台的高潮，大家有的说虚，有的说有用，有的说割韭菜……以及各种公众号的文章，来来去去的特别多。

当时我就在想，中台只是现在起的一个名字，其实是中台落地，中台我们称之为一个可复用的能力。这种可复用能力的机制，它想落地的时候，其实每一步都是非常实实在在的，上一些组件或者上一些工具，以及上一些流程来做这个事情。

一、什么是中台以及中台理解误区

今天的分享是想说，其实每一步都是非常落地的，而且落地的每一个工具，当时落地它以及把它放到整个IT系统里面来，也是有实际的原因的，而且我们也会看到一个互联网公司整体的中台全景图，初看上去可能会比较复杂，但是其实也不是一开始上来就要把这个东西设计成这样，里面这些工具也不是为了玩得多么天花乱坠，所以才这个样子做的，而是说它其实是每一层的，每一个工具都是在不同的阶段需要起到相应作用才去做的。

今天会讲25个步骤，就是说这些工具是逐渐上的，当你遇到了这些问题，并且为了解决这些问题而去上这个工具，一般的分享都是说给大家一个终极架构图，告诉你应该像互联网公司一样弄成这样，但其实对于传统企业来讲，我们不太建议。你要理解背后的问题在哪，遇到这个问题所以应该上这个工具，这样一个思路。 

因为中台理解的比较混乱，所以要下一个比较精准的定义，即通过将后台应用在技术平台的支撑下，通过两种模式，一种模式是封装，一种模式是重构，传统企业比较建议用封装，能力充分的时候可以进行重构，从而形成面向业务场景的一个平台。不能光上一个技术平台，或者说买一个多么牛的平台，你就是中台了，不是这样的，你要将你的后台应用通过封装或重构的方式，变成面向业务场景，最重要的一点就是要做到支撑业务快速迭代的一个平台。 

我们说复用能力也好、叫不叫中台、是不是割韭菜都无所谓，但是关键要做到的一点，就是想起到业务快速迭代的作用。

这里面的要点是快速迭代，所以说我们在整个做能力复用平台的时候，其实都是围绕着这一点来做的。做到这一点，里面会有一些误区，比如一个企业已经有了系统的积淀，并且解决了业务层的温饱问题，想进一步解决业务创新的问题时使用的，无论叫不叫中台，就等于说企业原来已经发展的挺好，已经成为一个业内相对比较知名的企业，业务模式也已经成立，在业务模式成立的时候其实才会用中台，所以说如果一个创业公司自己的业务模式还没有形成，这时候其实不知道什么要复用，因为可能明年就拐弯了，后年再拐弯了，所以说中台对创业公司上意义可能不是特别大。

另一个误区是很多人说中台可以加速业务创新，很多文章里面也都是这么说的，但其实这个说法其实也不完全正确，中台根据上面的定义，它更多的是支撑创新。业务达到了温饱向小康迈进，或者想进一步上一个台阶的时候，想要创新的时候，业务方已经想到了N条路可以走，但是不知道应该走哪条路的时候，这时候用这种复用能力比较好。也有比如说原来路走得很嗨，我感觉我这个房子还没卖完，我卖房子仍然利润很高，所以我不想用一个传统的系统，我也不想做互联网公司，我就卖房子挺好的，这时候它其实确实也是不需要中台的。

另外就是业务层其实想不到出路，比如卖针卖线的，它想不出来我再去卖什么东西，这时候即使你上了个中台的组，它也没办法帮一个卖针卖线的企业想到一条真正的出路，所以说中台是一个支撑创新的一个机制，也不要对它期望过于高，当然中台也不是现有的系统集成，就是说我采购了10个、8个系统，把它集成起来，这就是一个中台了，这时候因为你无法做到快速迭代，因为这些系统你都改不了。 

此外中台也不是技术平台，因为光采购了一个大而全的技术平台以后，它也不能直接帮助你的业务。

业务创新模式有很多文章在讲，我不仔细说了，因为今天主要说落地。但是对于传统企业来讲有几个核心点：

第一个是以业务为核心，就是刚才所说的建设中台其实为了加快业务的快速创新，如果改善不了业务，那么领导层在中台组的构建或者投入方面，可能也会比较犹豫。 

另外一个是领导层一定要可控制可观测，传统企业已经有了一定的积累，活得已经挺好了，现在想要业务创新，但是又不想把原来的系统搞垮，所以说其实并不想走互联网公司创业阶段那种不断摸索、有什么上什么那样一条路。而是想把整个规划做好，整个的路径领导层都能看得到，每一步都可以控制，出了问题可以及时观测及时修复的一个机制，另外就是逐步的迭代，不是说一步到位，因为这时候步子迈得太大，也容易出问题，也起不到这种可观测控制风险的一个方式。 

所以对传统企业来讲，要做业务创新，比较倾向于这三点，一是业务中心，二是领导层可控制和观测，三是要逐步的去做这件事。

二、中台体系建设目标总图详述

这是一个中台体系建设总图，这个图画的比较大而全。重点分两部分，左边是组织架构的部分，右边是技术架构的部分。我们要建一个中台体系的话，仅仅是做技术是不行的，仅仅做组织也是不行的，两边其实要配合起来。

左边每一个框都是有颜色的，右边每个框里也是有颜色的，左边的组织相同颜色对应会负责右边技术架构的部分。对于组织来讲，每家公司都会有自己的CTO和CIO，偏技术的公司叫CTO，偏运营的公司叫CIO，原来的CIO下面直接挂业务开发组，运维组就没有了，但是在中台体系下面要拆分成几个组，首先在CIO和CTO里面下面要多一个组织叫架构委员会，为什么要多一个架构委员会？因为在中台建设上我们会发现或者复用能力方面，将来要做的技术决策相对比较多，比如说哪些部分应该要复用、哪些不要作为复用能力的部分？哪些归中台组、哪些不归中台祖，哪些该拆、哪些不该拆？类似这样的一些决策，所有决策如果都依赖于CIO一个人，这有点不大可能。

架构委员会更多有点像军机处这样的一个存在，就等于说它挂在CIO下面，然后里面会有架构的专家，有数据的专家，有各种各样的专家，它其实是有一个专职的一些架构师存在。另外它里面还有个虚框，虚框是各个业务开发组以及中台开发组的leader，或者是派一个代表或者派一个架构师去参加架构委员会。架构委员会，重点会做两件事情，第一个是要制定标准，我们做业务开发和我们做中台开发的时候，肯定是要有一定的标准，开发的工具要有标准、格式要有标准、文档要标准、接口要有标准、注册发现都要有标准。只有整个中台体系建设过程中，所有组都按这个标准来，才是相对比较有序的。

光有标准不够，我们经常会预料到我的标准就是一纸空文，颁发下去以后发现大家其实都不按这个来，其实也没有办法，这时候就会有另外一条线叫做技术和工具的支撑，这就是技术底座。这里包括微服务、容器、持续集成的流程管控、虚拟化、PaaS、运维平台都有，通过这些工具我们可以对组织和流程做一定的观测和落地，靠工具而不是靠人为， 以工具为支撑。

有了工具以后，大家都在这些工具的帮助下，按统一的规则去做事。右面的技术架构、下面的云的部分、虚拟化的部分、Kupernetes容器的部分，以及基于容器的PaaS，或者是基于虚拟机的PaaS，最终上Servive Mesh，这些是基础设施的部分。另外这里面还有分布式技术实务、配置中心，所有这些工具，以及统一的发布平台和统一的全链路监控平台，都属于技术底座，这些技术底座非常多，往往看得人眼花缭乱了，是不是一切都要做一个大平台上去？其实不是的，我们后面会讲，通过25个步骤逐渐的上去。逐渐的上去以后，整个过程就会比较可控。

中间这一部分其实是业务部分，这里是以网易电商作为例子。下面是中台的部分，比如说第三方商家、供应链、决策、用户、商品交易等等，这是中台部分，是可复用的部分。它中间强调的是整合和能力的沉淀，重点是解决可复用的问题。 

上面绿色的部分，是前台的一些业务应用部分，强调快速迭代。同样左边的组是开发组或分为两个组，一个叫中台开发组，它负责中台复用组件的部分；还有一个业务开发组，它负责业务开发的部分，这样整个开发过程中，无论是中台业务开发组还是中台开发组，都在架构委员会制定的个流程指引下，并且在这些工具支撑下形成统一的标准，逐渐进行开发。所以左边会有三个箭头，第一个箭头叫领导可观测，这时领导不光是指CIO了，因为CIO有军机处了，所以有架构委员会，架构委员会也是要观测，比如有人破坏了整个CICD的流程，没写足够的测试用例或者接口没按标准来，那么在接口平台，在API网关上，在注册中心上都能看的到，架构委员会每一组都有自己的代表，是可以看到的，看到以后就可以及时进行修正。第二个是QA可测试，第三个是开发可理解。三个层次都可以做到，这是整个体系。

三、中台架构逐步演进过程综述

接下来我们要看这个体系是怎么把它逐渐变成这个体系的，有很多文章是一下子把这个体系扔给传统企业，大家会比较晕，不知道怎么办？怎么逐渐做起来？整个设计的流程比较多，有业务架构的部分、技术架构的部分、数据架构的、研发流程的、组织架构的，都需要逐渐的、去迭代，最终形成上面的模式。 

中台体系逐步的演进，我们分为四个大步骤，25个小步骤。四个大步骤中，第一步骤是规划，第二步是试点，第三步是服务化，第四步是微服务化，每一步都有更加详细的步骤。

为什么要分这四个步骤呢？首先第一步规划，对于传统企业来讲，规划这一步非常重要，因为传统企业有一定的积累，不能说现在要做中台体系建设或者可复用能力建设，就把原来所有的东西都抛掉，这是做不到的。所以要做一定的规划。

第二步是试点，规划好了以后，不是说有8个、10个、20个系统都散出去，大家就开始拆或者是开始构建中台了，因为相应的工具链也没有匹配好，相应的流程也没有匹配好，相应的规范也没有匹配好，另外我们的军机处也就是架构委员会里面的架构师们也没有完全做好准备，这时候对于传统企业来说相对比较稳妥的方式，就是先拿出某一个业务来做试点。试点的业务也许相对简单，也许是痛点更痛的业务。在尝试过程中对于工具链更加熟悉，对于流程更加熟悉，虽然业内包括网络上可以搜到什么最佳实践等各种分享，但是每家公司肯定有自己独特的流程，肯定是要把一个行业内通用的流程落地到自己公司，这个事情仅仅乙方是没法帮甲方解决的。甲方自己的军机处，自己的架构委员会，其实要和乙方一起摸索出自己的架构师团队以及架构师团队制定的最佳实践的流程，以及流程怎么落到工具上，未来怎么观测等。试点结束了以后，这些就都形成了。

接下来第三步，进行服务化，先不要做微服务化，先不要拆得太细。为了快速迭代，先做一定的服务化。

而当某些业务系统有高并发需求时，比如突然做了一个类互联网业务，要大促了，或者要秒杀了，这时候这部分可以做一定的微服务化，这样四大步骤。

我们首先是从源头去寻找，为什么我们一定要开始逐渐去构建中台体系，不光是制造业，金融和其他传统企业，都会有这样的例子，这里是一个制造业的例子。他们会采购很多系统，如果使用企业消息服务总线的话，就会做一个集成，但是做集成并不能解决我们前面所说的快速迭代的问题，其实也有很多的甲方不断在问为什么互联网公司的迭代速度这么快，我们的速度就不行？在经历了很多次梳理了以后，发现自己好像也能复用，因为拿企业消息服务总线把各个系统集成起来，就能复用了，接口也有了，为什么当有一个新的东西以后，好像还是没办法快速地去做这件事情。 

后来经过一段时间的梳理会发现，影响单体软件迭代速度的问题，我把它归结为架构腐化的问题。

我们自己的业务系统在不断的重构，重构完了以后，我们觉得这个系统挺干净了，过一段时间发现又不行了，改又改不动了，所以就腐化了。腐化了以后如果有魄力的话，并且给你时间的话，又重构了，重构完了以后，过一阵又腐化了。 

就像上图展示的一样，你给领导画了一个架构图，说我们有模块ABCDE，然后他就以为，ABCDE是横平竖直分的界限非常清楚，但是过了一段时间腐化了以后，就变成了右边这个图，即实际的架构图。这时候就出现一个情况，即领导让你改的时候，你说不好意思我可能改不了，或者我很晚才能改，领导就很纳闷你给我画的架构都挺干净的，为什么你改不了？你无法支持我的快速迭代。

架构为什么会不断腐化呢？有人说集成的方式也有接口，但是为什么拆完了或者进行服务化以后，架构腐化就会减轻，不进行服务化架构腐化就会不可避免的迭代，其实也不是说拆完了以后架构腐化就不会进行，而是说其实有一些力量使得架构腐化问题是必然发生的，只是说在服务化并且可观测的情况下，我们能够比较快速的进行纠正。 

第一点，就是没有时间做，为什么没有时间做？我们作为开发经常会有这样一个现象，就是领导往往比较重视功能，你开发一个新的功能，如果有了bug，它也会惩罚你，但是他往往不重视架构。他为什么不重视架构？因为不可观测，看不到。就如上面所说的，其非常强调领导层可观测，因为看不到他就不会给你留时间。 

比如说做某个功能，你说我其实想留一段时间，因为我觉得我架构好像有点腐化了，我想稍微重构一下，然后再做新的功能，但他不会给你留时间，为什么？因为他看不到架构的复杂性。他觉得就是一个工程一些代码，为什么你要改这么久？他如果看到一个依赖关系图，他就会做这个事了。因为它不可观测，所以他不给你时间，所以往往就没有时间做，这是第一个。 

没有时间做就会导致第二点，没有动力做。代码的可理解性越差，我越懒得改，我越懒得改。另外即使改了我也没有什么绩效？反正领导也看不到。还有人说我可以组织code review，但是我们所有人都知道代码一旦可理解性差，让另外一个从来没看过你代码的人去code review，他肯定做不出来。这是没动力做，因为也没有人care这件事情。

第三点是没胆量做，就算有一个对于技术有情怀的人，他会发现这个代码复杂了，耦合性高了，越是核心的逻辑，大家越层层封装，越是层层封装的我越不改，因为核心逻辑一动就有可能整个挂了，这时锅就我背了，所以没胆量做。

这三点原因造成耦合的现象之一，就是你改代码你要上线，其实是需要我配合，这就是迭代速度慢的一个问题，比如说咱们经常在上线前要拉一个群，或者在一个大群里面说我要改这个功能会影响谁，然后冒出三个人来说会影响我，这三个人说完了以后又冒出6个人说，会影响他，6个人之后12个人，这下发现今天是没办法上线了，没办法，大家只好约一周或一个月的某个时间一起上线。这就是耦合带来的一个现象。

造成的另外一个现象是可复用性差，领导天天听下面的人做报告说我这边的架构是这个样子的，他那边架构是这样子的，领导明明听说某个组的某个地方有这个功能，却拿不出来？拿不过来另一边又要重新开发，或者拿过来比开发还麻烦。类似这样就是可重复性差，最后就形成了一个技术债务，所谓的技术债务就是一个功能，一年前领导让你开发的时候，你说我一下午就搞定了，然后一年后再问你的时候，你说要开发一个月，然后他表示很不理解，这就是架构腐化带来的一个问题。 

所以为什么要做一定的服务化，就是在一定程度上去遏制架构腐化问题，即使服务化以后架构腐化问题也是不可避免的，但是由于有这三个特性，第一个叫可理解性，就是在工程相对比较简洁，职责比较单一的时候，其实是比较容易修改和比较容易准备review的，这时候可理解性就会相对比较好一点。一旦可理解，大家就比较愿意改。 

第二个是可测试性，我把它服务化，边界拆完了以后，它比较难以融合到一块去。这时候大家应该会观察到这种现象，就是越混杂到一体的代码，测试覆盖率越低；越是边界设置比较好的代码，测试覆盖率越高，如果我们要求可测试性覆盖率达到一定程度，这时候腐化的问题就会比较早暴露出来，及时去修正它，而不是说等它腐化到一定程度，当领导发现了不能改的时候，才能再做这样的一个现象。 

第三个是可观测，架构委员会可以制定规范，并且实时去监测，当第一个接口或者第一个模块触犯了整个规则的时候，架构员会因为每个模块的负责人也在里面，它其实是可以比较早的去修正这个问题，而不是说到时候谁也不知道，到了后期改不动的时候，或者债务特别强的时候才去改这个问题，所以做服务化，使得职责单一，使得可测试，使得可观测，是能避免腐化不可修正的问题，能解决这个问题，如果这三个问题解决了以后，就可以做到快速迭代和可复用。比如说开发就比较敢改了，因为职责相对比较单一，同时review，每个人开一个工程，工程的样子也差不多，代码也会相对比较的简洁，review的人也能review出来，QA也容易测试，领导也能看到它的价值，也能看到价值，比如说你的业务系统，比如说5个服务之间互相调用，那么这时候你说一个代码调用的话要涉及5个，领导也能看到相对的复杂性，而不是复杂性完全耦合在一个里面，这样最终促进整个业务的创新。 

这是整个方法论。

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

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

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

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

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

第一步是维度提升，我们会发现有些企业原有的系统所做的方式想创新的话，其实原有系统里面，它的数据结构也好，它的方式也好，其实不能满足前台的需求，比如说传统的采购和供应链的协同，比如传统的分销和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个步骤，基本上都会到第三部分也就是服务化，大部分全链路压测都会做，我们熟知的互联网公司其实都会做。但是传统企业现在大部分处在先做规划，再做试点，以及做服务化的三个阶段，甚至有的先做规划，接着做了一定的试点，并且现在服务化在逐渐进行的过程中，正在走服务化的阶段。 

—— END ——

↓↓↓点击阅读原文，免费试用网易轻舟