点击“ 技术领导力 ”关注 ∆ 每天 早上8:30 推送
在跟同行交流的时候,常常有人这样问: 中台不就是微服务吗? 都是以服务化的方式对外提供能力,老瓶装新酒嘛,炒作概念而已。
这种说法实际上混淆了中台与微服务的定义,要说清楚这个问题,就要先了解,什么是中台? 什么是微服务? 中台和微服务之间有什么样的关系?
01
来自阿里官方的定义,“企业中台就是,将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由业务中台和数据中台构建起数据闭环运转的运营体系,供企业更高效的进行业务探索和创新,实现以数字化资产的形态构建企业核心差异化竞争力。”
阿里的中台大约有十几个共享业务单元,包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的,共享业务单元则由阿里云平台支持。
共享业务单元的划分原则其实不是可以简单掌握的,要综合考量设计、运营和工程因素,尽可能遵循“高内聚、低耦合”、“数据完整”、“业务可运营”和“渐进”的原则。
阿里在划分中台时非常重视其业务价值和基于业务的设计,而且有业务架构岗位,每个共享单元都有业务架构师。但总体来讲,其业务架构仍然是领域性的。
企业中台最早是由阿里在2015年提出的,即逍遥子张勇倡导的“大中台,小前台”战略、“数据+业务双中台”等等。
随后BAT、TMD纷纷效仿,提出了各家的中台战略。 技术领导力曾发表过十几篇中台相关研究文章,大家可以参考文章合集: 《 “阿里中台架构”15篇刷屏文章精选,快收藏! 》、《 中台架构50篇资料精选,阿里/腾讯/京东...中台建设实践汇集 》。
阿里中台方法论,包括:
第一,如何建设中台? 即,领域建模、服务拆分粒度、关键业务的抽取原则、组织文化适配等等。
第二,如何管控中台? 就是中台的运营平台,它主要由协议标准、能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局,把控细节。
第三,如何进化中台? 跟任何一种技术架构的演进一样,中台也需要不断迭代、进化,中台思想深度融合到企业日常经营当中,形成强大的后台炮火群,更好的支持前端业务快速反应。
我们以阿里技术中台为例,在阿里集团内部,所有业务中台、前台,共享一个技术平台底座,将阿里多年技术沉淀的价值最大化,提供运行更稳定、架构更灵活的技术支撑。
(图片来源:阿里技术参考图册)
阿里技术中台,就是将使用云或其他基础设施的能力,以及应用各种技术中间件的能力,进行整合和包装。过滤掉技术细节,提供简单一致、易于使用的应用技术基础设施的能力接口,助力前台和业务中台数据中台的快速建设。
阿里的技术中台,包括:
流式计算
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
中台架构,简单地说,就是企业级能力的复用,一个种方法论,企业治理思想。
微服务,是可独立开发、维护、部署的小型业务单元,是一种技术架构方式。
中台并不是微服务,中台是一种企业治理思想和方法论,微服务是技术架构方式。
中台化的落地,需要使用微服务架构,通过微服务架构搭建中台架构所需要的原子服务,其核心是服务设计的原则和思想。
参考文章:
1. 媳妇沉迷赌博输了套房,我一怒之下...
2. 中台架构50篇资料精选,阿里/腾讯/京东
3 . 从月薪3K的中专生,到身家千万的CTO!
4. “你的核心能力是什么?”“我能搞定业务方!”
5. “技术的价值是啥?”“哄业务方开心啊!”
6. 阿里“双11”亿级流量背后的API网关微服务
7. “来我公司写爬虫吗?会坐牢的那种!”
-End-
想看更多大厂技术干货分享?
关注“技术领导力”公众号
想加入社区,跟100位互联网大咖学习?
添加群助理Emma, 注明“加群”
技术领导力社群
好看就点 在看