“中台不就是微服务吗？有啥区别？”

在跟同行交流的时候，常常有人这样问：中台不就是微服务吗？都是以服务化的方式对外提供能力，老瓶装新酒嘛，炒作概念而已。

这种说法实际上混淆了中台与微服务的定义，要说清楚这个问题，就要先了解，什么是中台？什么是微服务？中台和微服务之间有什么样的关系？

01 中台是什么？

中台的定义

来自阿里官方的定义，“企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”

阿里的中台大约有十几个共享业务单元，包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的，共享业务单元则由阿里云平台支持。

共享业务单元的划分原则其实不是可以简单掌握的，要综合考量设计、运营和工程因素，尽可能遵循“高内聚、低耦合”、“数据完整”、“业务可运营”和“渐进”的原则。

阿里在划分中台时非常重视其业务价值和基于业务的设计，而且有业务架构岗位，每个共享单元都有业务架构师。但总体来讲，其业务架构仍然是领域性的。

代表企业

企业中台最早是由阿里在2015年提出的，即逍遥子张勇倡导的“大中台，小前台”战略、“数据+业务双中台”等等。

中台方法论

阿里中台方法论，包括：

第一，如何建设中台？即，领域建模、服务拆分粒度、关键业务的抽取原则、组织文化适配等等。

第二，如何管控中台？就是中台的运营平台，它主要由协议标准、能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局，把控细节。

第三，如何进化中台？跟任何一种技术架构的演进一样，中台也需要不断迭代、进化，中台思想深度融合到企业日常经营当中，形成强大的后台炮火群，更好的支持前端业务快速反应。

中台架构技术

我们以阿里技术中台为例，在阿里集团内部，所有业务中台、前台，共享一个技术平台底座，将阿里多年技术沉淀的价值最大化，提供运行更稳定、架构更灵活的技术支撑。

（图片来源：阿里技术参考图册）

阿里技术中台，就是将使用云或其他基础设施的能力，以及应用各种技术中间件的能力，进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台数据中台的快速建设。

阿里的技术中台，包括：

流式计算

JStorm是一个分布式实时计算引擎，调度器分配一个worker 来跑任务，进行任务全生命周期的托管。
分布式存储

Tair（Key/Value结构数据存储系统）
Histore（分布式海量数据场景下OLAP分析型数据库产品）
Hbase
TFS（分布式文件存储）。
分布式数据库

TDDL（分布式数据库中间）
精卫（取名自“精卫填海”，基于MySQL数据库的数据复制组件）
愚公（数据自动迁移引擎，异构数据源迁移）
SchedulerX（分布式任务调度）。
消息

Notify
MeteQ
分布式服务

HSF（High Speed Framework，分布式服务框架，当时阿里内部选择了HSF，放弃了dubbo）。
负载均衡

Tengine（是基于 Nginx 开发的轻量级开源 Web 服务器,作为阿里巴巴七层流量入口的核心系统）。
应用容器

Pandora（是淘宝网中间件团队打造的，基于HSF隔离技术构建的全新一代隔离容器）。
软负载&配置中心

ConfigServer（主要提供非持久配置的发布和订阅）
Diamond（是一个持久配置管理中间件，可以实现分布式场景下，中心化的持久配置管理，同时也支持基于发布订阅模型配置动态变更推送）
VipServer（天枢，通过集中式的配置向客户提供路由信息，以非网关的形式实现负载均衡功能）
Zookeeper。
分布式链路跟踪&基础数据

Eagleye（鹰眼，通过收集和分析在不同的网络调用中间件上的日志埋点，可以得到同一次请求上的各个系统的调用链关系，有助于梳理应用的请求入口与服务的调用来源、依赖关系）
TLOG（是一个分布式的，可靠的，对大量数据进行收集、分析、展现的的系统）。
02

微服务是什么？

微服务的定义

微服务架构将单体应用，按照业务领域拆分为多个高内聚低耦合的小型服务，每个小服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，如HTTP RESTful API，或者RPC，独立自动部署，可以采用不同的语言及存储。

微服务体现去中心化、天然分布式，是中台战略落地到IT系统的具体实现方式的技术架构，用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。

微服务解决的问题

传统的单体应用有很大的局限性，应用程序随着业务需求的迭代、功能的追加扩展，最终成为一个庞然大物。单体应用的局限性大体包括以下几方面：

复杂性高：业务规模和团队规模发展的一定阶段，模块耦合严重，代码难以理解，质量变差。

交付效率低：构建和部署耗时长，难以定位问题，开发效率低，全量部署耗时长、影响范围广、风险大，发布频次低。

伸缩性差：单体只能按整体横向扩展，无法分模块垂直扩展。

可靠性差：一个bug有可能引起整个应用的崩溃。

阻碍技术创新：受技术栈限制，团队成员使用同一框架和语言。

微服务技术架构的特点

易于开发与维护：微服务相对小，易于理解；

独立部署：一个微服务的修改不需要协调其它服务；

伸缩性强：每个服务都可按硬件资源的需求进行独立扩容；

与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力；

技术异构性：使用最适合该服务的技术，降低尝试新技术的成本；

企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡。

03

中台和微服务有什么关系？

回顾概念：

中台架构，简单地说，就是企业级能力的复用，一个种方法论，企业治理思想。

微服务，是可独立开发、维护、部署的小型业务单元，是一种技术架构方式。

可见，中台并不是微服务，中台是一种企业治理思想和方法论，微服务是技术架构方式。

中台化的落地，需要使用微服务架构

中台强调核心基础能力的建设，基础能力以原子服务的形式来建设，并通过将原子服务产品化，支撑业务端各种场景的快速迭代和创新；原子服务和微服务所倡导的服务自闭环思想不谋而合，使得微服务成为实现原子服务的合适架构。

支撑业务场景的应用也是通过服务来实现，其生命周期随业务变化需要非常灵活的调整，这也和微服务强调的快速迭代高度一致，所以业务应用服务也适合通过微服务来实现。

中台化系统建设不是一蹴而就的，需要长期动态的演进，加上其技术体系已经在互联网领域被证明且相当成熟，其在企业落地、执行的土壤已经具备。

04

本文要点小结

中台架构，简单地说，就是企业级能力的复用，一个种方法论，企业治理思想。

微服务，是可独立开发、维护、部署的小型业务单元，是一种技术架构方式。

中台并不是微服务，中台是一种企业治理思想和方法论，微服务是技术架构方式。

中台化的落地，需要使用微服务架构，通过微服务架构搭建中台架构所需要的原子服务，其核心是服务设计的原则和思想。