本文转载自【刘超的通俗云计算】公众号，作者刘超，网易杭州研究院云计算架构师

上文：以业务为核心的云原生体系建设（上）

4、云原生体系演进阶段二：构建中台体系，加速业务创新

上一节，我们讲了阶段一的很多问题，其实这些问题归根结底是一个字——散。系统散，数据散，流程散，组织散，而当前的市场竞争条件下，业务创新要争分夺秒，如此“散”的架构没有办法拧成一股绳，应对业务的快速变化，就像集团军作战，各个部队分兵作战，就不能形成合力。

因而要将这些系统，数据，流程，组织重新组合，形成公司的“腰部力量”，强调能力的沉淀，强调融合与复用。只有有了“腰部力量”，才能灵活应对业务的快速变化，这就像打篮球，“腰部力量”是最重要的，无论是投三分球，还是在空中做花哨的投篮动作，看起来是在手腕，其实真正的能力在腰部。

这就是我们常说的中台。中台这个词很火，有的人觉得很好，有的人觉得太虚，但是名字无所谓，其实就是构建公司的可复用能力。

4.1、中台的定义

这里给中台下一个相对完整而准确的定义。

        

这个概念需要解读一下。中台是为了体现IT技术，IT系统，IT部门的业务价值而诞生的概念。这一点如果作为一个纯技术，很难感受到这一点，感觉中台就是忽悠，如果在一家技术为主导的公司也很难感受到这一点，觉得技术的价值马老板都清清楚楚，还需要“体现”吗？

但是在传统企业，可不像互联网公司这样重视技术，业务部门的老大在中国的市场经济搏杀了几十年，最后混出来靠的一个是中国过去几十年的快速发展及人口的红利，二是老板们对于市场，营销，供应链的把控。当然这种野蛮生长的过程，并没有对IT技术和IT系统有什么感觉，所以往往会重业务而轻技术，重硬件而轻软件。当然低成本人口红利的野蛮生长阶段已经过去，老板们也发现过去的这一套有点玩不转了，差异化客户体验驱动产品创新阶段已经到了，他们开始眼红互联网公司的兴起了，于是开始设立了CIO这个职责。只不过大部分公司的情况是，CIO作为高管，在业务老大那里话语权还不高，毕竟钱是业务部门赚的，真正IT预算都是业务老大要批的，所以在传统企业，能够体现业务价值非常重要，这是中台这个词的核心，也即定义中的“面向业务场景”以及“支撑业务快速迭代”所强调的，CIO要让CEO，业务部门理解IT部门和IT系统的价值。

4.2、中台的误区

之所以对于中台的定义这么复杂，另外一个问题就是，大家对于中台的理解经常出现错误，最终导致企业构建中台不正确，却怪中台太虚，不落地。

这里总结了中台五大误区。

4.2.1、误区一：中台构建的太早

中台是企业已有系统积淀，解决了业务温饱问题，要进一步解决业务创新问题时候用的。

如果你是一家创业公司，那解决温饱问题，确定业务模式最为重要，如果这个时候花大量的时间建设中台，一是你本来就没什么可沉淀的，二是沉淀了也可能因为创业方向变化而白沉淀，三是过于重视技术耽误了你取得业务成功的时间。

其实大家只要看看阿里什么时候搞的中台，就明白了。中台要有共性，淘宝，天猫，聚划算，1688都是电商业务。中台要先在一个业务取得成功，淘宝2003年创立，天猫创立较晚，两者时间差比较大，淘宝的系统才能演进为中台。

4.2.2、误区二：对中台期望太高

中台可能被吹的太牛，有时候被当成了万金油，似乎什么都能解决。例如中台能够使业务创新这件事情，就属于期待过高。

中台没有办法让业务创新，只能“支撑”业务创新，说白了就是中台其实就是可复用能力，这种能力是一种内功，是一种支撑能力，但是替代不了业务能力。

如果业务方自己想不出业务创新的方法，或者不愿意想业务创新的方法，只想吃老本，那中台帮不上任何忙。但是如果业务方能够想出50种(约数)创新的方法，但是不知道哪个对的时候，中台的可复用能力就帮上忙了，其中业务中台可以使得业务方在这50个方法里面快速的尝试，而数据中台使得业务方能够快速看到这些方法的尝试结果，这样就能快速找到业务突破的方向。

4.2.3、误区三：觉得中台太简单

以为中台就是现有系统的接口组合，以为通过ESB将服务编排一下就解决了。将ERP,CRM等后台系统通过ESB暴露出去不是中台。

第一个原因是，CRM里面有客户，而手机APP里面的用户中心也是客户，但是两者有明显的区别，CRM里面是后台管理语言，是给公司内部的人看的，也是按照公司内部的人管理最方便的方式组合信息的，他不是前台业务语言，从后台的CRM到APP上的用户中心中间还有一定距离。

这里常见的例子是，有的银行的App比较难用，而支付宝和微信支付就对用户友好，有的航班的App比较难用，而航旅纵横就对用户友好，如果仔细观察，你能发现其中的区别吗，很多银行的App将柜员系统中的概念和操作方式直接搬到了App上，很多航班将柜台系统中的概念和操作方式也是直接搬到了App上。

第二个原因就是上面说过的，单体应用群通过ESB暴露出去，虽可以实现信息拉通，但是无法达到中台快速迭代的目标。

4.2.4、误区四：觉得中台太复杂

很多传统企业一听中台，就觉得一下子要上N各系统，将原来的服务拆分的七零八落的，然后看看自己手里就这几十号人，应该搞不定，于是望而却步，任务中台太复杂，这是互联网公司的事情，传统企业不应该参与。

其实这是误解，中台的构建有两种方式，封装式和重构式，传统企业往往害怕的是重构式，然而其实中台的建设有渐进的过程，可以保留原来的系统，通过逐渐的封装，构建自己的中台。

4.2.5、误区五：觉得中台太技术

有的企业比较有钱，觉得中台的构建就是个技术问题，只要花钱买一个一线互联网公司的大平台就搞定了中台，这也是一个很大的误区，因为你没有自己的架构师团队和中台团队，没有自己的流程和规范，没有自己沉淀可复用能力的方法论，还是没办法应对业务的快速迭代。这就像你在健身房看到一个健身教练用一个很牛的器械练了六块腹肌，你就把器械买来，自己不练，那也没有腰部力量呀。

4.3、中台建设的两种方式

4.3.1、封装式

传统企业由于采购大量传统服务，可采用封装式构建中台。

前台APP或者门户一旦需求改变，后台采购系统或核心稳态系统不可能随之改变，所以中间封装中台服务层

传统服务多使用SOAP协议暴露接口，可通过ESB或者API网关转换为RESTFul接口对上暴露

服务层采用最新微服务架构进行开发，适应前台快速迭代

4.3.2、重构式

互联网公司历史包袱轻，大型银行，运营商等由于技术力量充足，可对于部分系统进行全方位的重构为微服务架构，并以此为底座构建中台，可全面实现自主可控，和快速迭代。

4.4、中台如何解决第一阶段的问题

接下来，我们来看中台如何解决第一阶段的问题，我们还是从企业架构的五个方面逐个分析。

4.4.1、业务架构：架构服务化，侧重变化多和复用性，领域拆分与解耦       

 

上一节，我们讲了影响快速迭代的问题是架构腐化问题，那如何解决这个问题呢？就是通过服务化的方式，将不同的业务领域拆分到不同的工程里面去。

这样第一会增加可理解性，工程更加的简洁，每个工程只做一个领域的事情，职责单一，这样就会既容易修改，也容易Review。其实按照人性角度来讲，易Review更加重要，因为拆分后的服务虽然聚焦于某个领域，也会腐化，易Review能够早日发现腐化，早日修复。

第二会增加可测试性，越是耦合在一起的庞大代码，测试覆盖率越低，越容易出现问题，而拆分后的服务测试更加容易展开，覆盖率变高。测试覆盖率是验证架构有没有腐化的指标，也是领导或者架构委员会能够看到的，也有利于及时制止和修复腐化。

第三，也即最重要的就是可观测性，服务化之后，一般要有服务统一的注册发现和接口管理平台，通过这个平台，服务之间的调用关系以及接口的设计和文档，领导和架构委员会都能看到。

调用关系变乱是架构腐化的重要指标，服务之间的调用应该分层单向调用，严禁循环调用的，如果多个服务之间的调用一团乱麻，那就说明腐化了，应该及时制止和修复。另外接口不符合规范，也是架构腐化的重要指标，接口如果开始出现模糊，或者传入大量的参数，甚至传入Hashmap将参数通过key-value的方式传递，那就说明里面的架构已经腐化了，应及时制止和修复。

这样就是实现了架构始终保持在轻债务的阶段，这样开发敢改，同事容易Review，QA容易测试，领导和架构委员会也看得到的效果。

而且服务化拆分后，会将很多内部的功能，暴露成接口对外提供服务，并且接口经过Review和设计，而且文档和调用方式都在注册中心上，非常方便其他服务调用，从而实现可复用性。

从而最终实现了快速迭代。

你可能会问，你说了半天服务化，和前面的中台啥关系呢？中台这个词其实是给业务方听的，具体到技术手段，就是服务化。作为技术部门，需求都是从业务方来的，业务方其实不关心我们拆了多少服务，就是希望能够快速完成需求，而服务化就是为了完成这个目标的，只不过你说服务化，甚至拆分啊，架构啊，业务领导听不懂，所以就说为了更快响应他们的需求，给他们建设了中台。

那服务化应该从哪里开始呢？

这里很多技术人员都会犯的错误是，从数据库出发，看数据库结构如何设计的，按照数据库最容易拆分的方式进行拆分。这样是不对的，没有站在业务的角度去考虑问题。应该借鉴领域驱动设计的思路，从业务流程的梳理和业务领域的划分出发，来划分不同的服务，虽然最后映射到数据库可能会拆分的比较难受，但是方向是对的，只有这样才能适应未来业务的快速变化，起到中台应该起到的作用。我个人认为，方向比手段要重要，方向对，当前痛一点没什么，但是当前不痛，方向错了，还是解决不了问题。

当然领域驱动设计在落地的过程中可能存在各种问题，比如前期规划时间过长，前期设计阶段考虑不到细节的场景，落地的时候会经常碰到和前期设计不一致的地方，需要返工等现象。其实互联网公司也大多没有安装领域驱动设计的完整流程来做，但是这里面的流程梳理和领域划分，还是很必要的。

领域划分好了，接下来就要开始拆分出服务，进行服务化了。从哪里入手呢？比较落地的方法是随着新需求的不断到来，渐进的进行拆分，而变化多，复用性是两大考虑要素。

这么说有点虚，我们举个现实的例子。例如按照领域的划分，对于电商业务来讲，一个单体的Online服务，应该拆分成下面这些服务。

       

但是绝不是发起一项运动，闭门三个月，一下子都拆分出来，一方面没有相应的工具链，流程，员工的能力的适配，将使得服务化失控，这也是我们经常观察到，很多企业服务化之后，一下子失控，从而不断的加班，业务SLA降低，需求接的更慢了等现象，然后就放弃了服务化，回归单体应用，然后骂中台，微服务是垃圾。

领域驱动设计的结果仅仅是一个规划，使得后台的技术人员在和业务的领域专家讨论业务流程和场景的时候，对于业务有更深入的理解，并且通过DDD的输出有一个完整的地图。但是接下来后台技术部门不应该闷头开始就按这个拆了。因为领域知识从业务部门到技术部门的传递一定有信息的丢失，这也是DDD落地被诟病的地方，就是业务方规划的时候是这样说的，落地来需求的时候，却是另外一种说法，导致根据DDD落地好的领域，接需求接的更加困难了。

所以赵本山说，不看广告，看疗效。对于服务拆分，DDD是一个完整的地图，但是具体怎么走，要不要调整，需要随着新需求的不断到来，渐进的进行拆分，DDD领域设计的时候，业务方会说不清，但是真的需求来的时候，却是实实在在的，甚至接口和原型都能做出来跟业务看。

需求到来的时候，技术部门是能感受到上一节讲过的架构耦合导致的两个现象：

• 耦合现象一：你改代码，你要上线，要我配合

• 耦合现象二：明明有某个功能，却拿不出来

第一个现象就是变化多，在业务的某个阶段，有的领域的确比其他的领域有更多的变化，如果耦合在一起，上线，稳定性都会相互影响。例如图中，供应链越来越多，活动方式越来越多，物流越来越多，如果都耦合在Online里面，每对接一家物流公司，都会影响下单，那太恐怖了。

第二个现象就是可复用，例如用户中心和认证中心，根本整个公司应该只有一套。

在《重构：改善代码的既有设计》有一个三次法则——事不过三，三则重构。       

 

这个原则也可以用作服务化上，也即当物流模块的负责人发现自己接到第三家物流公司的时候，应该就考虑要从Online中拆分出来了。另外就是，当有一个功能，领导或者业务方发现明明有，还需要再做一遍，这种现象出现第三次的时候，就应该拆分出来作为一个独立的服务了。

这种根据业务需求逐渐拆分的过程，会使得系统的修改一定是能够帮助到业务方的，同时系统处在一种可控的状态，随着工具链，流程、团队、员工能力的增强慢慢匹配到服务化的状态。

这个阶段服务化的结果如下图所示。

             

 

4.4.2、技术架构：基础设施云化，统一接口，抽象概念，租户自助

服务化的过程，工具链很重要，技术架构就是解决这个问题的。

             

经过业务层的的服务化，也对运维组造成了压力。

应用逐渐拆分，服务数量增多。随着服务的拆分，不同的业务开发组会接到不同的需求，并行开发功能增多，发布频繁，会造成测试环境，生产环境更加频繁的部署。而频繁的部署，就需要频繁创建和删除虚拟机。如果还是采用上面审批的模式，运维部就会成为瓶颈，要不就是影响开发进度，要不就是被各种部署累死。

这就需要进行运维模式的改变，也即基础设施层云化。

虚拟化到云化有什么不一样呢？云计算带来的改变，统一接口，抽象概念，租户自助。

首先是接口统一，例如基于OpenStack实现，大部分部署工具支持其接口，可基于开源工具实现发布的工具化和平台化。

其次是概念的抽象。

原来出现服务器机型碎片化，资源分配碎片化的现象。Flavor抽象资源配比（4G 8G 计算优化型，网络优化型，存储优化型），统一硬件配置，提升利用率，硬件上线效率提升。

VPC屏蔽物理网络复杂性，冲突问题和安全问题，使得租户可自行配置网络。原来的网络使用的都是物理网络，问题在于物理网络是所有部门共享的，没办法交给一个业务部门自由的配置和使用。因而要有VPC虚拟网络的概念，每个租户可以随意配置自己的子网，路由表，和外网的连接等，不同的租户的网段可以冲突，互不影响，租户可以根据自己的需要，随意的在界面上，用软件的方式做网络规划。

其三是租户自助。

也即人工创建，人工调度，人工配置的集中管理模式已经成为瓶颈，应该变为租户自助的管理，机器自动的调度，自动的配置。

自动调度代替人工调度，区域可用区抽象对机房机架交换机的感知。

云提供租户概念，有账号子账号体系，有quota，可以让租户在管理员许可的范围内自助操作，加快环境部署速度。

4.4.3、数据架构：统一指标体系，建设数据仓库，支撑管理决策

服务化之后，各个系统的业务数据格式统一了，制定了统一标准，并且上游系统设计的时候会考虑到下游的使用，下游系统设计的时候，会考虑到和上游兼容，统一的客户ID，订单ID等能够将整个业务流程串起来，有利于建设统一的指标体系。

有了这个基础，就可以建设统一的数据仓库了。数据仓库的构建不能像第一阶段一样再数据库里面，或者业务系统里面直接进行分析，需要通过数据接入，将数据抽取出来，经过一定的处理，放到数据仓库里面来。       

这就需要建设大数据的技术平台。

第一个步骤叫数据的收集。数据的收集有两个方式，第一个方式是拿，专业点的说法叫抓取或者爬取，例如Nutch就是这样爬取全网的数据的，建设数据中台，你需要融合外部数据，为经营做决策，就需要通过爬取的方式。另外一个方式就是推送，有很多终端可以帮我收集数据，比如硬件终端的推送，应用系统的埋点等，这些是融合内部数据。还有数据是从数据库里面抽取出来的，就要用到DataX等数据交换工具。

第二个步骤是数据的传输。一般会通过队列方式进行，因为数据量实在是太大了，数据必须经过处理才会有用，可是系统处理不过来，只好排好队，慢慢的处理。例如Kafka就是常用的队列，有时候传输的过程中要对数据做预处理，这就是常说的ETL，Extract-Load-Transform。

第三个步骤是数据的存储。存储的数据量比较大，需要使用大容量的存储，可以使用分布式文件系统 HDFS，对象存储OSS，以及Hbase, MongoDB等NoSql的数据库。

第四个步骤是数据的处理和分析。这里主要分离线处理，例如Map-Reduce, Hive, Spark，也有实时流处理，例如Flink, Spark Streaming, Storm等。

第五个步骤就是对于数据的检索和挖掘。检索多用ElasticSearch，可以做即席分析，例如Kylin, Impala, ClickHouse, Hawk，也会有一些算法可以进行数据挖掘，例如Spark ML里面的分类，聚类等。

数据平台的建设，还只是建设了一个技术平台，作为中台，还应该有业务属性，也即数据仓库，也即从业务领域的角度建立一些表，方便进行业务角度的分析。

咱们前面服务化的时候，梳理了业务领域的划分以及业务流程，这在数仓建设中也是很有用的。如图所示，里面有商品域，采购域，物流域，交易域，这些都是和服务相对应的。我们建设数仓的时候，里面的指标设计也是按照业务流程来的，这也是和服务相对应的。

当基于业务领域划分和业务流程梳理，总结出来的数据仓库及指标，是能够反映业务的运行过程的，在此之上，建设BI报表，和领导驾驶舱，可以将原来以周为单位的经营情况反馈过程，缩短到天甚至小时。

       

这里面有一个制造业的例子，就是经过数仓的建设和指标的梳理，已经可以很好的做业务运营监控了。

             

4.4.4、研发流程：发布模式平台化，构建持续集成流程，质量和绩效看板

我们再来看研发流程，云平台的建设提供了统一的接口，这使得发布模式可以更容易的对接资源，实现平台化，并基于平台构建持续集成流程。

因为如果云计算不管应用，一旦出现扩容，或者自动部署的需求，云平台创建出来的虚拟机还是空的，需要运维手动上去部署，根本忙不过来。因而云平台，也一定要管理应用。基于云计算OpenStack的虚拟机分层镜像发布和回滚机制，构建发布平台，可实现大规模批量部署和弹性伸缩。

基于虚拟机的PaaS托管中间件，简化租户创建，运维，调优中间件的难度。云平台的PaaS负责创建的中间件的稳定，保证SLA，当出现问题的时候，会自动修复，从而业务方不用管PaaS中间件的部署和SLA了。

发布平台提供基于虚拟机镜像+PaaS中间件，做完整的应用的部署和上线，称为编排。基于编排，就可以进行很好的持续集成，例如每天晚上，自动部署一套环境，进行回归测试，从而保证修改的正确性。

要求业务对于高可用性设计要在应用层完成，而不能完全依赖于基础设施层的能力了。每一个服务都有实现良好的无状态化处理，幂等服务接口设计。每个服务都要设计有效探活接口，以便健康检查感知到服务状态。通过制定良好的代码检查规范和静态扫描工具，最大化限制因为代码问题造成的系统不可用。

4.4.5、组织架构：成立中台组/架构师组，衔接研发和运维

上面的技术问题说完了，接下来说一说组织问题，根据康威定理，组织方面就需要有一定的调整。

上面说过，中台是为了能够集团军作战，能够协调各种力量为业务快速迭代服务，要建设腰部力量，除了上面所说的各种系统，人当然是最重要的，人不能调度起来，系统建设的再好也白搭。

所以不能再运维组和开发组隔离了，而要成立架构师组，或者就像前面图中的架构委员会，当然这个架构组一开始试点不用很大，试点阶段一定要有这个角色，来横向协调各种资源，并且挂在CIO下面，有一定的话语权。

这就是前面总图里面，我把架构委员会叫做军机处的原因，军机处当时就是为了打仗调动资源设置的机构，直接向皇帝负责，虽然下面的六部都不直接汇报给军机处，但是军机处作为皇帝的辅助大脑，可以监视整个架构的情况。另外一个比较好的比喻就是政委，在架构委员会里面有各个组的代表，所以指定流程的时候，各个组的意见也会参考，架构委员会制定的流程，各个组的代表有责任将流程贯彻下去，这就相当于军队里面政委的作用，我党的军队如此有战斗力，和政委的存在以及贯彻党的思想十分密切。

应该建立独立的前端组，统一前端框架，界面一致，所有人掌握统一的前端开发能力，积累前端代码，在有新的需求的时候，能够快速的进行开发。

建立中间件组，这部分人不用贴近业务开发，每天的任务就是研究如何使用这些中间件，如何调优，遇到问题如何Debug，形成知识积累。如果有统一的一帮人专注中间件，就可以根据自身的情况，选择有限几个中间件集中研究，限定业务组只使用这些中间件，可保证选型的一致性，如果中间件被这个组统一维护，也可以提供可靠的SLA给业务方。

将业务开发组分出一部分来，建立中台组，将可以复用的能力和代码，交由这几个组开发出服务来，给业务组使用，这样数据模型会统一，业务开发的时候，首先先看看有哪些现成的服务可以使用，不用全部从零开发，也会提高开发效率。

4.5、阶段二的问题

其实大部分的企业，到了这个阶段，已经可以解决大部分的问题了。能够做到架构服务化，基础设施云化的公司已经是传统行业在信息化领域的佼佼者了。中台开发组基本能够解决中台的能力复用问题，持续集成也基本跑起来了，使得业务开发组的迭代速度明显加快。集中的中间件组或者架构组，可以集中选型，维护，研究消息队列，缓存等中间件。在这个阶段，由于业务的稳定性要求，很多公司还是会采用Oracle商用数据库，也没有什么问题。

实现到了阶段二，在同行业内，已经有一定的竞争优势了。

那什么情况下才会觉得阶段二有问题呢？

我们发现，当传统行业不再满足于在本行业的领先地位，希望能够对接到互联网业务的时候，上面的模式才出现新的痛点。

对接互联网所面临的最大的问题，就是巨大的用户量所带来的请求量和数据量，会是原来的N倍，能不能撑得住，大家都心里没底。

例如有的客户推出互联网理财秒杀抢购，原来的架构无法承载近百倍的瞬间流量。

有的客户对接了互联网支付，甚至对接了国内最大的外卖平台，而原来的ESB总线，就算扩容到最大规模(13个节点)，也可能撑不住。

有的客户虽然已经用了Dubbo实现了服务化，但是没有熔断，限流，降级的服务治理策略，有可能一个请求慢，高峰期波及一大片，或者请求全部接进来，最后都撑不住而挂一片。

有的客户希望实现工业互连网平台，可是接入的数据量动辄PB级别，如果扛的住是一个很大的问题。

有的客户起初使用开源的缓存和消息队列，分布式数据库，但是读写频率到了一定的程度，就会出现各种奇奇怪怪的问题，不知道应该如何调优。

有的客户发现，一旦到了互联网大促级别，Oracle数据库是肯定扛不住的，需要从Oracle迁移到DDB分布式数据库，可是怎么个迁移法，如何平滑过渡，心里没底。

有的客户服务拆分之后，原来原子化的操作分成了两个服务调用，如何仍然保持原子化，要不全部成功，要不全部失败，需要分布式事务，虽然业内有大量的分布式方案，但是能够承载高并发支付的框架还没有。

当出现这些问题的时候，才应该考虑进入第三个阶段，微服务化。

下一节，我们来看阶段三如何解决这些问题。

未完待续

作者简介：刘超，网易杭州研究院云计算技术部首席架构师，出版《Lucene应用开发解密》，极客时间专栏《趣谈网络协议》《趣谈Linux操作系统》，毕业于上海交通大学，曾经就职于EMC，CCTV证券资讯频道，HP，华为等，目前在网易从事容器，Kubernetes和微服务的架构工作。长期致力于云计算开源技术的分享，布道和落地，将网易内部最佳实践服务客户与行业。个人公众号《刘超的通俗云计算》发表OpenStack, Kubernetes, 微服务类技术文章107篇，其中《终于有人把云计算，大数据，人工智能讲明白了》累积10万+。