前言

最大的浪费不是重复建设，而是不断重复建设。

--阿里巴巴集团中间件技术部研究员蒋小伟（小邪）

个人觉得蒋小伟老师说的非常有道理，所以这里引用该评价。

中台的决策

中台概念

• 技术中台，比如微服务开发框架、Devops 平台、PaaS 平台，容器云之类的

• 业务中台，比如用户中心，订单中心、商品中心、库存中心、交易中心等

• 组织中台，比如企业内部资源调度中心和内部创新孵化组织等

• 数据中台，比如数据模型中心，数据开发中心，数据存储中心，数据服务中心等

那么这里的所有概念都源于阿里的大中台，小前台的思想战略，然后引起了跟风热潮。那么回过头来看这里的概念中台更像是抽象出的一个个组件。如果是面向软件的视角来看，这些应该是组件化服务，也是蒋小伟老师提到的避免重复建设的工具。下面的共享业务事业部来源于《企业 IT 架构转型之道》阿里的中台战略架构图。

中台好处

针对公司组织架构，便会根据系统服务以及组织所涉及的业务来进行了定位，技术中台，业务中台，组织中台，数据中台。当然有的公司会根据不同的业务产品进行事业群划分比如腾讯，分为不同 BG，比如企业发展事业群 CDG 包含大家熟知的广告营销之类，IEG 互娱大家熟知的王者荣耀，吃鸡等，TEG 相当于技术基础架构部提供主要的基础服务设施，WXG 微信由于比较优秀所以单独的一个事业群，包含微信下的所有内容，CSIG 主要发力于腾讯云与智慧产业赋能相关，PCG 平台内容包含大家熟知的 QQ，应用宝，微视等。

现在的技术正在逐步上云，大家也在齐心协力构建中台体系，统一技术设施。早期便是不同的业务 BG 维护不同的技术设施，快速响应需求和技术支持比较笨拙，内部数据封闭，协作问题难，导致被头条反超。

中台问题

上面举了一个腾讯的例子来阐述了中台的好处，那么中台的坏处又是什么呢？

由于大量的中台概念，服务化概念，云概念等词汇的频繁出现，导致大家的需求都在追求去中心化，就放佛很多年前，大家一拥而上使用 SOA 概念的 ESB 实现方式一样。明白的咽着苦水，不明白的跟着大公司走。

• 业务架构师的能力问题

每个业务架构师对于中台的理解程度，以及自身的认知设计能力的不同，以及背后驱动的因素不同，涉及出的中台是否偏离原目标，没有人来评价。

• 业务服务的需求与服务改造的动力不足

很多公司依然是以业务驱动技术，由于涉及到公司投入的成本和收益，中台能力的推动，后期诸多因素难以继续。

• 中台能力搭建，服务数量和业务覆盖范围扩大

没有很好的基础设施建设和团队投入，导致中台搭建上下游依赖，基础建设依赖难以推动协作服务。

• 服务拆分微服务，服务依赖与耦合错综复杂，人员离职交接文档不完善

没有好的技术文化建设，交接 wiki 等输出，后期重复建设，盲目接受需求，中台形而不实。

• 服务的数据管控，服务的 SLA 保障，服务的治理

随着系统服务的增多，需要有服务全链路跟踪，方便快速定位问题，以及梳理服务之间的依赖关系，定位服务的性能瓶颈等。

小结一句话：中台需要自上而下的变革，以及后期不断的需求维护，以及基础建设维护持续更新。如果盲目中台化战略实施，很容易后期后劲不足，中台战略失败，浪费人力，财力，物力。投入和收益不成正比。

但是从长期长远来看，如果公司希望后期快速应对变化，拥抱变化，则中台战略势在必行。

否则会经常面临如下的服务问题：

• 项目团队间协同成本高，业务响应越来越慢

• 应用复杂度超过人的认知负载

• 错误难以隔离

• 数据库连接能力很难扩展（比如太多的应用机器，需要数据库连接，有限的链接池的瓶颈）

• 应用扩展成本高

中台的建设

领域边界服务化

• 划清业务边界，制定领域模型

比如该业务是订单中心，该业务是商品中心，该业务是用户中心，根据不同的领域划分不同领域模型。

• 回归 SOA 的本质，服务重用原则

领域边界服务化一定是面向 SOA 的，底线的原则是减少不断重复建设，那么我们需要提炼公共服务，尽最大化提高服务重用性。

• 拥抱变化

领域服务是跟随业务需求不断变化，而不断完善的，互相影响，如果需求已经不满足，迭代效率差，那么可能是该领域服务退役的时候。

领域服务治理化

• 约定服务最小原则，也就是微服务化的粒度

1、观察自己的投入和产出

比如服务化改造，自己需要投入的成本人力和时间周期，以及改动的范围，定义服务化改造标准衡量值。

2、根据自己的业务划分，一切离不开业务

比如自己负责的统一对外开放能力，则定位开放平台。比如自己负责的用户权限管理，身份白名单等，则定位为用户平台。

• 约定提供的服务能力

比如技术中台：底层 Paas 的能力，解决大型架构在分布式，可靠性，可用性，容错，监控，以及运维层面上的通用需求。

比如业务中台：提供云化的核心业务支撑能力，决定是否能真正支持上层业务达到敏捷，稳定，高效。

针对自己的服务能力进行定位和约定。

• 服务平台化

搭建服务平台，比如用户中心要演变为用户平台，交易中心演变为交易平台等，提供平台化能力的支撑。

1、确定自己的服务化对象

2、建立共享服务的基础设施

服务的描述元数据

领域服务产品化

• 服务的稳定化

服务的上下游依赖调用，对于服务的稳定性要求会越来越高，提升服务的稳定性，监控告警平台，分布式日志平台，全链路跟踪平台，故障定位分析平台，限流降级平台。通过各种平台来保障自己的产品服务具有稳定性，高可靠性。

• 服务的可视化

服务的 UI 界面管理，服务的可视化管理，帮助研发或者运营能够更好的，更直观的看出问题，以及看到资源使用情况，以及流量分配调度，实时数据流，实时交易等。比如阿里或者京东的双 11 或者 618 的大促监控盘。

• 服务的共享化

服务的共享能力决定了服务的未来长远走向。

服务共享原则：

1、要找到一个合适的服务化对象

涵盖业务流程，数据服务能力，便于实现对对象的服务化组件封装。

2、建设对象服务化的基础设施

服务治理工具与平台，服务化对象封装成服务组件，完成治理。

3、服务化实施阶段

用服务化基础设施把服务化编程服务组件，让业务方共同参与进来推动业务服务化，享受服务化带来的应用服务治理的红利。

4、增强服务和基础设施实现服务的精细治理

通过产品和工具的支持，为用户提供更好理解，更易用，更优质的服务，最终达到按需服务的层次。

领域服务商业化

• 服务的运营化

数字化运营能力，提供产业互联网的可运营能力。

• 服务的场景化

对于产品服务的业务场景，进行针对性的展示和梳理。

• 服务的解决方案化

对于服务的不同业务场景有着不同的场景解决方案能力，对于未有的业务场景，也能提供快速的响应解决方案。

小结

一切源于业务需求，一切终止于业务需求，以需求为始。