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

什么是中台

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

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

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

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

中台技术架构

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

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

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

什么是微服务

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

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

微服务解决的问题

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

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

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

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

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

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

微服务技术架构的特点

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

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

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

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

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

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

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

回顾概念：

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

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

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

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

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

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

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

结论：
1、中台架构，简单地说，就是企业级能力的复用，一个种方法论，企业治理思想。
2、微服务，是可独立开发、维护、部署的小型业务单元，是一种技术架构方式。
3、中台并不是微服务，中台是一种企业治理思想和方法论，微服务是技术架构方式。
4、中台化的落地，需要使用微服务架构，通过微服务架构搭建中台架构所需要的原子服务，其核心是服务设计的原则和思想。