柳杰：企业架构中台化实现

分享篇

如何降低企业互联网化改造的技术门槛？如何提高企业的业务快速响应能力及业务创新能力？在本期大华南IT高管共赢圈的微课分享中，互联网架构资深专家柳杰先生结合多年知名互联网公司的从业经历，以及对企业中台化改造的丰富实践经验，与大华南平台CIO分享了实现企业架构中台化的秘诀。

企业应用的变迁过程

企业应用的变迁过程主要分为几个阶段，2000年，主要是单一应用，是企业为了增加效益而开发的应用。2000到2004年这个阶段，虽然，企业做了很多的C/S的应用，运维相当的复杂。企业也在寻找新的技术方向，当WEB容器、B/S结构出现之后，企业应用如雨后春笋般的，快速出现很多B/S结构的系统，大部分都是以部门或项目为单位开发一些垂直应用，这些垂直应用对企业的生产发挥了重要作用，提升了效率，加强了管理。2006年到2008年这个阶段，随着业务的发展，企业需要进行业务融合，将数据打通，这时候就出现SOA服务，主要解决企业应用、业务协调和数据共享的问题。这一阶段，很多企业实施了ESB，面向服务重用、流程重构，以达到业务的灵活性。但在实施过程中，由于只站在业务的部门、项目的角度去思考问题，没有将业务分析的高度提高到整个公司或者集团的角度。比如两个业务系统之间做一些服务的交互或业务的交互，这实际上就变成了数据的一个交换通道，大多数最后都做成的是数据交换平台，没有到达业务的共享和协同。因此实施SOA存在很多问题，收效甚微。互联网发展到2013年至2014年这个阶段，云化服务开始出现。随着微服务架构的出现，导致很多企业的应用也发生了变化，在工业互联网或产业互联网领域，以及企业应用面向消费者等方面发挥了作用。这个时候，企业中并没有出现真正的微服务中台化的架构，但在互联网行业已经存在，一些巨型的互联网公司实现了企业应用的云化。

整个发展过程中的各阶段，基本都是以企业的业务发展和IT技术匹配发展。业务推动技术，新技术助力业务发展。

2015年，一些互联网公司提出中台化的概念，实际上在2012年到2013年间，很多互联网公司已经在实施，当时叫单元化。这个单元能够提供相应的领域服务能力，即IT系统与资源能够叠加，对外提供业务服务能力，能根据资源的量进行横向扩展。这个阶段，很多互联网企业在开展促销活动的过程中，经常会出现一种现象，就是同一个功能，如购物车，有的企业所设计的购物车却可以支持上亿人同时在线，支撑很大的访问量，有的企业开发相同功能的购物车，可能几百人上去就搞瘫了。这实际上就是技术的支撑实现了业务服务能力的提升。在2015年、2016年之后，出现了新零售、工业4.0、产业互联网、工业制造等新概念，这些概念也在冲击着传统制造型企业，企业开始思考企业内部的协同生产，产业互联网、消费互联网资源的打通，柔性制造，用户个性化定制等问题，企业的信息化不再是面向内部的信息化，而是要面向用户、面向渠道，将系统和能力对外开放，实现整个生态共享。这个时候，传统的ERP或者传统业务应用业务能力是不够的，需要有一种新的技术模式，新的设计手段去改变企业应用的服务能力。

微服务化的架构设计

如上图：微服务架构实际是红色虚线内的内容。

微服务的架构看上去比传统的架构复杂，提高对业务的快速响应能力和服务能力扩展，可以解决企业的很多问题。微服务是数据独立、服务独立和部署独立的，能够作为一个业务组件部署到系统中，独立去演进，这是微服务的一大特点。微服务提供的服务是领域内的服务。企业的服务，如SOA化的时候，是从公司或者集团层面的服务，而微服务是从业务领域本身的角度出发，二者是不同层面的事情。微服务要解决的是服务能力和业务灵活性的问题，业务的快速变更对整个业务应用的容错性问题。从整个设计或部署的架构上来看，传统应用就是简单的WAR包和数据库，微服务体系就要部署N个微服务领域实例，业务服务实例，能力开放平台，应用场景的war包，然后组装起来成为一个应用。在传统的应用中，WAR包只能部署在一台或者几台机器上跟数据库绑死，即使有资源也无法进行能力扩展，而微服务可以实现横向扩展，在每个层级、各个环节都可以进行扩展。将IT资源和微服务、业务服务和业务应用进行叠加，实现服务能力横向扩展。

看上去微服务要比？？

   

 

什么是企业中台

 

微服务与企业中台是两个概念。从微服务的概念来讲，比如，B2B或B2C的电商系统都有会员中心、商品中心、价格中心、订单中心等微服务，但这两个系统的数据是隔离的。从企业中台的概念来讲，如会员中心，不管是B2B还是B2C，都只是一个应用交易场景的问题，企业中台可以同时支撑B2B、B2C两种场景。

企业中台实际上是一组微服务，在微服务上叠加一些业务服务，如业务流程和微服务的组合服务等等。企业中台是基于企业业务层面是SOA化的服务。微服务是一个领域模型中的服务，企业中台是更宽泛的业务场景的服务，如购物车的服务涉及商品、商户、门店等各个微服务中心。中台的业务服务是一种组合服务，可以进行服务的重组或编排，对外提供整体的业务服务和服务能力。因此，企业中台下面有一组微服务，解决的是服务能力的问题，IT系统与IT资源可以进行叠加，通过底层服务能力的提供，业务能力也会随之增强。企业中台可以保证业务本身的灵活性，服务能力可以随着资源的横向扩展而扩展，解决业务响应慢、性能瓶颈等问题。

如上图所示， 其中微服务：

企业中台：

 

中台服务构建方法论

 

中台服务构建方法论，首先，业务与技术是隔离的。业务提供的是业务功能和业务流程，属于业务功能范畴；技术提供帮助业务解决服务能力问题，属于技术范畴。业务的组件化，从业务领域来讲，组件化实际上是领域的拆分问题，比如：把电商业务拆解为：会员中心、商品中心、店铺中心、价格中心、订单中心等等还有更多中心。把业务拆分成组件。组件服务化，就是组件对外呈现的形式是一个一个的服务或者一个一个的API，最终业务组件化、组件服务化、服务能力化，即服务在微服务体系下，服务能力与IT资源进行叠加时是可以得到保障的。把业务组件化，组件服务化，服务能力化，从领域的角度去拆分业务域。

将领域拆分后是否就是实现微服务？这主要考虑微服务在提供服务能力时是否与资源进行叠加。如果不能，则还是与传统应用一样，在开发模式下，实现了把领域拆分，业务服务开发出来。

技术主要解决两个问题，一是对服务本身的管控和治理，如服务框架；二是解决服务能力和资源叠加的问题。如果将这些技术和业务捆绑在一起都放在微服务中心，这实际上是将技术与业务捆绑在一起，这会导致业务扩展性很难落地。比如传统开发，一个业务应用对应多个数据库，开发的时候在应用中配置多个数据源，应用根据某个或者几个关键字端判断选择哪个数据源。如果增加一个数据源，系统要做比较大的改动，最后不一定成功。

业务与技术分离，业务解决的是业务的功能和流程问题；技术解决的是对功能、流程的能力支撑问题。如果将二者捆绑在一起，很多问题都不能有效解决，尤其在开发时，很难从设计层面去解决。因此在中台构建的时候，业务组件关注的业务功能和流程，按照技术体系要求开发业务功能。业务功能运行在技术体系上，技术体系提供服务能力，即业务应用的横向扩展能力。

 

互联网应用的中台和端

很多企业经常提及的前后端分离，比如H5应用、APP、Web应用、第三方接入，其实都是通过中台将业务开放出去。在我讲的中台有六层服务，其中：

数据落地层、企业微服务层、流程/流程重构层是企业业务开发人员需要设计和开发的数据模型设计，微服务、业务功能和业务流程相关的部分。数据库服务层、服务交互层、RESTful interface是技术支撑部分。如上图所示，从底层往上，第一层是服务能力提供，第二层是业务能力提供，第三层是基于业务API上的应用或应用场景的开发。数据与服务分离，就是数据用什么数据库、数据在哪里落地，由数据库的服务层即分布式数据库去解决数据本身的路由问题。微服务的实例扩展时，数据库的实例也可以进行相应的扩展。通过分布式数据库解决数据与服务的分离。通过微服务框架使用业务流程与微服务分离，所谓企业业务的变化，更多变化的是业务流程重组或重构，微服务体系在领域内，其支撑对象是很少发生变化的，基本比较稳定。当业务系统需要重构或重写时，其实重写的是流程，数据库、数据模型是没有发生变化的。

中台与端的分离，实际上就是前后端的分离，这当中很多的服务是可以共享的，通过中台给出同样的服务，在前端可以构建相应的应用场景。在企业或者互联网的应用中，容易变化的是交互层的东西，比如构建一个用户交互流程，增强用户体验等等。中台层面的变化，比如流程层面，虽然也有变化，但不如交互层变化快。另外，微服务的领域模型变化也比较少，变化的内容仅仅影响该领域，不会影响所有领域，再者，通过标签化的设计，可以使得微服务端基本稳定，不用 变化。

总结而言，中台最终提供的是业务服务，微服务是支撑上层的业务服务，通过业务服务支撑上层的企业应用。底层的服务能力是微服务提供的，通过资源的叠加，增加服务能力。微服务能力能够保证就有业务能力的保障，应用端的支撑能力是随着业务能力的增长而增长。应用能力最终通过微服务能力体现。

中台如何支撑业务场景

中台如何支撑业务场景，如下图所示，B2B、O2O都是部署在中台，如用户服务、搜索、价格、商品等等，二者的支撑场景都差不多，只是展现模式不一样。如商品展现，O2O以店铺为单位展示商品，B2B、B2C是通过引擎将商品搜索出来后，再通过商品列表去进行展示。这其实是一个场景的问题，底层的支撑端都是一样的。因此，后台一体化，前台可以差异化，前台差异化其实就是场景问题。比如构建一个场景，底层的业务或服务不需要再考虑，只需要把端设计好，通过API把数据提供出来，然后在端上把整个的操作流程实现就可以了。

 

中台应用的好处

中台应用的好处主要体现在四个方面，一是降低开发风险，提高开发效率。不需要重新整体设计就可以完成整个应用端的开发，应用端的开发是基于中台的API进行开发，这样就可以提高开发效率，增加系统的稳定性，应用端只是构建操作流程。二是提升系统扩展性，增强服务伸缩性。三是降低维护风险，减少维护成本。微服务本身部署的复杂度、系统和测试的复杂度等等，比传统的要复杂，在互联网行业都有一套很好的工具去解决这些问题，人为的出错几率要小很多。四是简化运维难度，提升管理效率。在互联网行业有一套技术支撑体系去支撑应用的快速部署、运维和管理。运维在互联网行业也有一套监控的运维体系，在进行容量规划或扩容、服务改造等等，都做了相应的数据化运维，降低了整个运维难度和成本，很多都是通过工具化去解决，可以提前告警。互联网的应用可以监控到每一个API的情况。

技术与业务分离，技术解决运维、发布、服务治理管控、服务开放和服务能力等问题，业务只是进行开发。企业业务开发人员只专注业务功能和业务流程的开发。

 

如何构建稳定的企业中台架构

构建稳定的企业中台架构，实际上就是要解决统一企业架构、服务能力、服务和资源叠加、集中运维平台等问题，包括从开发到运维的全生命周期的服务技术支撑。将企业从技术架构，应用架构中解放出来，关注业务本身。在微服务体系，不需要统一技术体系是可以的，可以是Java，.net，PHP等技术，但在架构层面，比如服务的管控框架、治理框架，分布式数据等等，在架构层面需要有一套系统规范。微服务在设计的时候要保证服务能力就可以了。

如上图所示：应用是各类场景问题，如上图：B2B，O2O只是交易场景的问题，底层的支持是一样的，比如：会员中心，店铺中心，商品中心，价格中心，交易中心等等，支撑能力相同或者有些变化，但在应用场景上变化很大。

尤其在未来，企业在发展的过程中，应用场景会逐步增加。在中台的体系支撑之下，构建应用场景比传统的方式快很多，同时应用的稳定性要高很多。逐渐体现出中台的价值。

 

如何构建稳定的中台架构

 

中台实际上是一个业务服务的问题，但是技术需要给他赋能，在开发的过程中，需要有一定的规范和最佳实践来支撑，在设计方面，我们要解决：

1、 统一的技术架构体系也业务架构体系（微服务体系）

2、 服务能力要保证，如果服务能力不能保证，和传统模式开发一个应用在本质上没有什么区别

3、 服务和资源的叠加，是解决服务能力的根本保证，否则，会出现服务的性能瓶颈。

4、 需要一套运维体系。服务的数量很大，没有一套自动运维体系是很难保证的。

整体互联网业务架构

基于PasS平台开发出来的应用，其逻辑上的架构是怎样的？如上图所示：IaaS层：物理机、私有云、公有云等都是属于IaaS部分，不做任何挑选，多种IaaS环境均可无缝支持。在PasS层，目前大型的互联网公司基本是使用JAVA体系，JAVA体系本身在JAVA虚拟机上，服务和应用的迁移，对操作系统没有要求。

业务服务体系，就是中台，基于A-PasS和I-PaaS中台，上层的B2B、O2O、B2C都是属于应用场景。因此，按照这种框架进行开发，关键问题是识别领域里的服务，技术上是可以通过PaaS平台做一个完整的支撑，包服务框架、统一运维的监控、自动化调度、资源调度、资源的告警和实时查看等等。

大数据平台单独划分，在传统企业中，数据平台作为企业的数据资产或数据资源，在日常的企业运营中，尤其是系统的交互层面是很少有的，大部分以报表的方式是为企业提供决策。在互联网公司，日常的运营中都是基于大数据平台来进行的，采集各类运行性能数据，对数据做分析，然后告知运维。企业在使用数据时，大部分都是采用结果数据，过程数据、行为数据目前在企业中应用较少。因此，对数据的采集、数据的收集渠道、数据源等可以做到更加多样化。

 

每个环节的组件支撑

在JAVA的整个开发体系中，主要解决：面向研发和面向运维。比如面向研发的时候，整个开发体系在支撑时要解决开发环境、技术框架、应用架构等问题。研发完成后，进行集成和自动部署，在自动部署上生产之后，面向运维时，比如服务治理、资源调度、服务安全管控等等，每一项服务甚至每一种方法都受监控。方法是最小级别的调用和监控对象。

性能参数采集分析，就是应用和服务需要升级、改造或扩容时，都是通过数据去支持。在传统企业，应用或服务的升级改造通常都是通过经验判断；在互联网行业，大多都是通过数据去支撑判断。

开发过程，从计划、开发、编译、测试、发布、实施、运维，每个环节都有很多工具支撑。比如需求管理、开发阶段。需求需要需求管理工具支持。开发阶段可能需要：分布式数据库、服务框架、开放平台、分布式消息平台、分布式缓存、统一ID生成器、SSO等等工具支撑，这些都是工具手段，在设计的时候可以根据场景去选型做取舍。比如在分布式的场景下，统一的ID生成器是否需要，依赖于我们的数据是否分片。为什么要统一ID？因为在分布式的体系中，无法知道ID在哪个数据片生成，需要统一的ID服务支撑，因为数据是分片的，在各个数据片中存储；应用与应用之间的集成大部分通过SSO完成；服务之间需要解耦，可能需要使用分布式消息平台；提高服务的吞吐量可能需要分布式缓存；服务治理和管控在企业做微服务改造是必须的，不存在可能用或不可能用；开放平台，一般来讲是需要使用的。

 

分布式组件支撑详解

基于PasS平台，如自动化运维、分布式数据库、消息缓存等，从整个信息流的过程来看，企业只需要关注应用的开发、服务的开发、数据模型的设计开发；其他如自动化的部署、数据分散等等。热点数据放在缓存或搜索引擎中，这些都可以通过技术手段快速解决，只要对接API，将业务策略和业务机制制定好，就可以快速将数据进行分散。在整个业务流的体系中，更多关注的是业务开发，技术由技术平台去实现支撑和管控即可。

 

敏捷实现是关键

敏捷开发与传统开发的对比，在微服务体系，按照传统的开发模式是很难进行开发的。在传统模式下，假设项目的完成周期一般是3至6个月，但在实际开发过程中，可能会由于需求的变化而导致项目周期长达1年甚至1年以上，项目开发一半时，可能会出现30%的需求都发生改变，导致甲方、乙方或业务方和技术方一直在相互指责，一直没有好的方法去解决，核心问题需求确实是一直在变化的。在敏捷开发模式下，只要将端到端的流程找出来，业务流程开发完成，在后续整个业务迭代的过程中，再逐步去完善。在进行第一个迭代时就考虑下一个需求。在业务变化越来越频繁、企业系统越来越开放的情况下，开发模式必须要进行转变，传统的流程已经无法适应互联网模式的快速迭代。

 问答篇

CIO：如何理解微服务、中台和SOA的关系？

柳杰：微服务、中台和SOA实际上是三个层面上的问题。微服务是解决一个领域里的服务问题；SOA是解决公司层面业务服务的问题，二者不在一个层级上。微服务更多关注的是服务能力、业务的灵活性以及变更；SOA是解决服务治理、服务管控、服务的重用、企业业务资产问题。虽然微服务和SOA都有服务的治理和管控，在技术上有一定的相识度，但二者的服务粒度不在一个层级、服务的对象不一样，微服务支撑SOA服务，SOA服务支撑应用。中台就是包含微服务和SOA，上层是SOA服务，下层是微服务，构建起来就是一个中台体系。

CIO：技术与业务分离，那么技术设计是按照什么思路来抽象化复杂业务的？

柳杰：业务很多时候是关注业务本身，业务流程的开发。在传统企业中，业务开发的技术人员和技术工具开发的技术人员都是一波人，在应用设计的时候，把两种混在一起，把两种技术人员混在一起。很难跳出这个圈子考虑问题。如刚才讲的购物车例子，无论谁开发购物车从业务功能上看都差不多，为什么大型互联网公司设计的购物车可支持一亿人同时在线，这实际上就是抓住技术支撑的特点，技术为业务服务赋能，在业务设计时让服务与资源能够多叠加。这是很关键的问题，如果这一问题没有解决，仍要坚持将技术与业务捆绑在一起开发，那么越开发，这个问题就会越来越复杂。

CIO：目前你们所改造的业务平台，原来的平台主要表现有哪些问题？

柳杰：主要有两个方面的问题，一是系统的服务能力不够。比如订单量达到上万的时候，这个平台经常会卡顿，或者用户一拥上来就卡顿。二是业务与IT之间或产品之间经常产生矛盾。比如业务提出的要求，IT很难支持，系统会出现不稳定状态。

帮助企业改造一个将原有系统替换掉的企业中台，在完成B2B的交互后，企业可以基于这个中台，自己构建B2C或O2O的场景。系统能力问题、业务灵活问题、二开难度大等都是原来平台主要存在的问题。

CIO：阿里、京东中台有无实质性区别？

柳杰：这两个平台在很早的时候就在构建中台，当时没有中台这个概念，叫单元化改造或业务能力的升级支持，本质上是IT系统与资源的叠加。实际上在资源进行扩展的时候，整个IT系统的能力也在提升。

CIO：实施阿里业务中台和数据中台有无注意事项？

柳杰：这是个核心问题。是否建立中台，主要看两个问题，一是解决业务的灵活性问题；二是解决业务的能力性问题。能力从传统上来说就是增加垂直扩展，如增加CPU、增加内存的升级等等。互联网公司是进行水平的横向扩展，就是IT能与资源叠加。

实际上，中台是属于业务范畴的东西，将技术赋能业务的时候，业务能力是可以得到保障的。在实施中台的时候，一定要将微服务与SOA的服务分开对待。微服务只是领域里的一个服务，服务力度仅限于业务领域，一定要识别领域。SOA化的业务服务范畴更大一点，这种服务可以是微服务的组合服务。

关于微服务与微服务之间的调用，微服务是在一个领域之内，领域之内的服务之间的调用，这种现象是存在的，但不多见，也不提倡。因此，在实施中台时要充分考虑服务能力和业务能力灵活性这两个问题，将这两个问题解决后，后面实施业务中台，这是业务领域拆分点，把业务领域、领域服务拆分出来，再把客流大的业务服务识别出来就可以了。

 

嘉宾简介

柳杰，互联网架构资深专家，先后就职于京东、阿里等知名互联网公司，经历了整个互联网电子商务平台的成长过程，作为互联网资深架构师，参与了互联网架构转型的过程，深刻理解互联网和互联网交易平台的架构设计。对企业中台化的改造有理论研究和实践经验，帮助多家企业成功实施企业中台化改造，成功实现技术体系落地、业务灵活性设计和业务服务能力快速扩展，实现业务场景快速开发和低成本试错，降低企业互联网化改造的技术门槛和提高企业的业务快速响应能力和业务创新能力。

 

---