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

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

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

01 中台是什么?

中台的定义

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


p1.jpg



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


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


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

代表企业

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


中台方法论





阿里中台方法论,包括:

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

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

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

中台架构技术

p2.jpg


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



p4.jpg


(图片来源:阿里技术参考图册)

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

阿里的技术中台,包括:

流式计算

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

本文要点小结


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

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

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

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

扫一扫,在手机阅读、分享本文

0
分享 2019-11-13

0 个评论

要回复文章请先登录注册