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

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


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


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

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

今天的分享是想说，其实每一步都是非常落地的，而且落地的每一个工具，当时落地它以及把它放到整个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个，领导也能看到相对的复杂性，而不是复杂性完全耦合在一个里面，这样最终促进整个业务的创新。

这是整个方法论。

更多内容请看下期：直播回顾 | 不谈虚的，给传统企业一份代码级的中台落地实践（2）