中台不就是微服务吗?这种说法实际上混淆了中台与微服务的定义,要说清楚这个问题,就要先了解,什么是中台?什么是微服务?中台和微服务之间有什么样的关系?
来自阿里官方的定义:
企业中台就是,将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由 业务中台和数据中台构建起数据闭环运转的运营体系,供企业更高效的进行业务探索和创新,实现以数字化资产的形态构建企业核心差异化竞争力。
阿里的中台大约有十几个共享业务单元,包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的,共享业务单元则由阿里云平台支持。
共享业务单元的划分原则其实不是可以简单掌握的,要综合考量设计、运营和工程因素,尽可能遵循“高内聚、低耦合”、“数据完整”、“业务可运营”和“渐进”的原则。
阿里在划分中台时非常重视其业务价值和基于业务的设计,而且有业务架构岗位,每个共享单元都有业务架构师。但总体来讲,其业务架构仍然是领域性的。
中台技术架构
我们以阿里技术中台为例,在阿里集团内部,所有业务中台、前台,共享一个技术平台底座,将阿里多年技术沉淀的价值最大化,提供运行更稳定、架构更灵活的技术支撑。
阿里技术中台,就是将使用云或其他基础设施的能力,以及应用各种技术中间件的能力,进行整合和包装。过滤掉技术细节,提供简单一致、易于使用的应用技术基础设施的能力接口,助力前台和业务中台数据中台的快速建设。
图片来源:阿里技术参考图册
微服务架构将单体应用,按照业务领域拆分为多个高内聚低耦合的小型服务,每个小服务运行在独立进程,由不同的团队开发和维护,服务间采用轻量级通信机制,如HTTP RESTful API,或者RPC,独立自动部署,可以采用不同的语言及存储。
微服务体现去中心化、天然分布式,是中台战略落地到IT系统的具体实现方式的技术架构,用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。
传统的单体应用有很大的局限性,应用程序随着业务需求的迭代、功能的追加扩展,最终成为一个庞然大物。单体应用的局限性大体包括以下几方面:
复杂性高:业务规模和团队规模发展的一定阶段,模块耦合严重,代码难以理解,质量变差。
交付效率低:构建和部署耗时长,难以定位问题,开发效率低,全量部署耗时长、影响范围广、风险大,发布频次低。
可靠性差:一个bug有可能引起整个应用的崩溃。
阻碍技术创新:受技术栈限制,团队成员使用同一框架和语言。
易于开发与维护:微服务相对小,易于理解;
独立部署:一个微服务的修改不需要协调其它服务;
伸缩性强:每个服务都可按硬件资源的需求进行独立扩容;
与组织结构相匹配:微服务架构可以更好将架构和组织相匹配,每个团队独立负责某些服务,获得更高的生产力;
技术异构性:使用最适合该服务的技术,降低尝试新技术的成本;
企业环境下的特殊要求:去中心化和集中管控/治理的平衡,分布式数据库和企业闭环数据模型的平衡。
回顾概念:
中台架构,简单地说,就是企业级能力的复用,一个种方法论,企业治理思想。
微服务,是可独立开发、维护、部署的小型业务单元,是一种技术架构方式。
可见,中台并不是微服务,中台是一种企业治理思想和方法论,微服务是技术架构方式。
中台化的落地,需要使用微服务架构
中台强调核心基础能力的建设,基础能力以原子服务的形式来建设,并通过将原子服务产品化,支撑业务端各种场景的快速迭代和创新;原子服务和微服务所倡导的服务自闭环思想不谋而合,使得微服务成为实现原子服务的合适架构。
支撑业务场景的应用也是通过服务来实现,其生命周期随业务变化需要非常灵活的调整,这也和微服务强调的快速迭代高度一致,所以业务应用服务也适合通过微服务来实现。
中台化系统建设不是一蹴而就的,需要长期动态的演进,加上其技术体系已经在互联网领域被证明且相当成熟,其在企业落地、执行的土壤已经具备。
结论:
1、中台架构,简单地说,就是企业级能力的复用,一个种方法论,企业治理思想。
2、微服务,是可独立开发、维护、部署的小型业务单元,是一种技术架构方式。
3、中台并不是微服务,中台是一种企业治理思想和方法论,微服务是技术架构方式。
4、中台化的落地,需要使用微服务架构,通过微服务架构搭建中台架构所需要的原子服务,其核心是服务设计的原则和思想。