企业IT架构转型之道——
阿里巴巴中台战略思想与架构实战
打造数字化运营能力
打造平台稳定性能力
构建业务中台基础
共享服务体系搭建
异步化与缓存原则
共享服务中心建设原则
数据拆分实现数据库能力线性拓展目录
1 构建业务中台基础
成功启示：
保持精简团队 ， Cell细胞开发团队： 一般2个-5个员工 ，最多不超过7个员工组成独立的开发团队
， 称之为Cell（细胞）
颠覆组织结构 ，决策交给团队： 团队自己决定做什么样的产品 ，然后最快时间推出产品的公测版
， 没有管理角色的介入
不惧失败 ， 为失败庆祝： 团队研发产品失败后 ，不会受到惩罚 ，甚至会举办庆祝仪式 ，从失败中
学 到了东西
厚平台 ，薄应用：公司所构建的“ 中台 ”能力 ，才是支撑小团队研发的核心
阿里中台战略：2015年领阿里高管拜访公司之后 ，启动了阿里巴巴的2018年中台战略。
Supercell的研发核心思维 Think Small小团队模式
Supercell（超级细胞） ， 芬兰某著名企业游戏巨头 。拥有《部落冲突》 、《卡通农场》 、《海岛奇兵》 和《皇室战争》 等全
球热门 游 戏 。2016年6月 ， 腾讯收购Supercell84 .3 %的股份 ， 作价86亿美元 ， 整个公司估值102亿美元 。 这不仅是腾讯历
史上 ， 也 是近 年全球手机游戏行业最大金额的并购 。根据腾讯的公告 ， 这家总部位于芬兰的公司 ， 目前员工总数仅有190人
。按照102 亿美元 的估值 ， 平均每个员工对应的估值折合约3 .5亿人民币 。
Supercell CEO IlkkaPaananen
我的职责就是让员工——所有资
深游戏开发者在一个“小团队 ” 或
叫 “ Cells（细胞） ” 内 工作 ，他
们有权做决定 ，尤其是 拥有是否
砍掉游戏项目的权利。
共
享
业
务
事
业
部
淘 天猫
宝
大
虽然组织架构上共享业务事业部和淘
宝 、天猫平级，但从对业务的理解和
业务贡献的体现来说 ， 对共享业务
事业部拥有着更多的话语 权，结果
就是共享业务事业部在两大 业务部
门的业务需求下艰难生存着。
阿里巴巴共享业务事业部的发展史
2008年时集团成立了天猫
4 、然后集团希望是这样的
共享业务事业部
2003年时成立了
3 、后来好像是这样的
天猫
成立天猫事业部
队同时支持着的业务 在2009年，共享业务事业部应运而生
天猫
5 、结局可能是这样的
2 、后来是这样的1、最初始这样的
天猫
共享业务事业部
阿里巴巴共享业务事业部在业务架构中的重要地位
目前阿里巴巴集团前端超过25个业务单元（如 、聚划算 、去啊等大家熟知的业务）均不是独立地构建在阿里云的云平台之上，在后端阿里云技术平台和前 端业务间
有了一个“共享业务事业部 ”，将阿里巴巴集团前端业务中公共 、通用的业务沉淀到了这个事业部，包含了用户中心 、商品中心 、交 、评价等十几个 中心 ，而共享业
务事业部正是“厚平台 ”的真实体现 ，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业 、稳定的业务服务。
业务共享单元
用户中心
监控报警
故障处理
系统升级
应用发布
安全防控
业务监控
运维保障部
关系型数据库服务
RDS/DRDS
分布式文件系统(盘古)
远程过程调用
（夸父）
开放缓存服
务OCS
任务调度（伏羲）
分布协同服务
（女娲）
阿里巴巴集团业务
Ali Express 1688 天猫 聚划算 阿里去啊 口碑 阿里妈妈 菜鸟物流
真正的转折来自2010年聚划算的出现， 由于它强大的流量吸引威力 ，竞相与其业务对接 。 集团要求三
大电商平台与聚划算平台进行业务对接，必须通过共享事业部！
支撑
支撑
神
农
集
群
监
控
大
禹
集
群
布
署
评价中心商品中心
搜索中心
交
数据服务中心店铺中心 营销中心
分布式应用服务平台EDAS
开源
用户
开放存储服
务OSS
弹性计算服
务ECS
资源管理（伏羲）安全管理
（钟馗）
开放数据处理服务
ODPS
阿
里
台
消息服务MQ
云
平
构建业务中台的基础 共享服务体系
共享服务架构的建设使得阿里巴巴摆脱了因为“烟囱式 ”系统建设方式所带来的种种发展桎梏，
最终成为阿里巴巴业务中台战略的核心组成。
服务需要不断的业务滋养
共享服务体系是培育业务创新的土壤
回归SOA 的本质-服务重
用
赋予业务快速创新和试错能力
改变组织阵型会带来组织效能的提升
为真正发挥大数据威力做好储备
共
享
服
务
会员中心 商品中心 交 支付中心
商品管理
前端
$
交
前端
$
支付管理
前端
$
交 支付数据会员数据 商品数据
基于共享服务体系建设的服务中心，原生就将相关业务领域的业务功能和数据做了很好的统一， 阿里超过2000多个应用，在核心业务层已
经 通过共享服务体系实现了统一和畅通，所以没有类似ESB的组件，避免了打通不同系统间实现业务交互带来的集成和协作成本。
价值1： 回归SOA的本质-服务重用
会员管理
前端
会员服务 交 支付服务商品服务
团购
订单
检查
其他
服务
交易 -
创建
数
据
层
订单创建流程 订单创建流程订单创建流程 订单创建流程
交易
日志
库存
检查
用户
检查
交易
创建
交易
创建
交易
创建
其他
服务
其他
服务
其他
服务
服
务
交
互
服
务
交
互
服
务
交
互
服
务
交
互
-
价值2： 服务需要不断的业务滋养
服务不需要“业务稳定 ”， 而需要不停的滋养， 只有在滋养中才能从最初仅提供单薄业务功能的服务逐渐成
长为企业最为宝贵的IT资产， 而服务所需的滋养正是来自新的业务不断进行服务的接入 。
服务
专业带来稳定
稳定
物流系统 O2O服务 支付平台 开放平台电商业务
线下线上数据
产品创新
实现对内对
外的开放
服务能力不断能提升
业务滋养
滋养开放 数据
共享业务事业部
交(TP)
自动 发
货
价值3： 共享服务体系是培育业务创新的土壤
各业务交架构师->交中的业务人员及架构师
从来自不同业务的“点 ”->扩展到线和面的维度全面掌控交务（领域业务专家）
点 点 点 点 点
数据完整性 全网规则安全校验 Notify
确认
收货
订单
拆分
修改
价格
创建
订单
订单
查询
关闭
订单
删除
订单
付款
价值4： 赋予业务快速创新和试错能力
打造好的业务中台， 降低企业创新试错成本，快某省市某省市场的反馈决定业务投入。
因为美军拥有强大的导弹指挥系统，
强大的中后台能力，
支持小团队快速判断，
引领进攻完成。
小前端团队具备的特征：
团队协同效率最高
对战机（商机） 的把握更加敏锐
调整方向更加快捷
一旦发现正确目标， 全力投入扩大战
果
美军以军为单位作战
美军以营为单位作战
美军以7人-11人极小班排作战
战场中的中台阵型
二战
越战
中东
,
,
,
价值5： 为真正发挥数据威力做好储
备
大数据项目的两个凸显问题 共享服务体系的解决之道
优秀数据科学家， 可遇不可求
靠企业自我培养， 共享服务体
系培育懂业务的专家
用户 、商品 、交业务和 数据
层融合
业务数据归整和沉淀
高质量的业务数据
缺少能基于数据有业务建模能力的专家
数据分布广 、格式不统一 、不标准
价值6： 改变组织阵型会带来组织效能的提升
• 针对每一个建设的服务中心 ，从组织架构的形态上调整 ， 不同角色人员（架构师
、 开发人员 、UED工程师等） 组建了一个新的组织 ，每个组织对某一服务中心提
供持 续的服务能力开发及运维。
• 业务架构师成为团队最核心的角色 ， 也是业务负责人 ，懂技术和业务 。成为服务
中 心业务发展的领路者 ， 也是保障服务中心核心业务保持业务通用性和公共性的
最重 要的捍卫者。
2 共享服务体系搭建
“
一个服务中心不单单是在企业的几个应用中发挥作用，它可能会给企业上百个不
同的应用提供专业服务， 一旦这个服务中心出了问题，将会对企业的运营产生难
以估量的损失和影响，这样就对这些服务中心的服务稳定性、服务能力的扩展性、
服务需求的快速响应能力提出了前所未有的更高要求。这就需要有一套成熟、完
善的技术体系来支撑整个共享服务体系，使得企业在业务发展的过程中，对这些
共享服务的支撑能力不会有任何后顾之忧。
”
分布式服务框架的选择
构建共享服务体系， 必然需要采用一套服务化框架来支撑整个服务体系的运转 。统模式转 变为服务化
架构的过程， “去中心化 ”服务架构成为今天绝大多数互联网平台所采用的服务框架 。
2007年的
500人技术团队， 兆字节的WAR包， 功能模块超过200个
数据库连接能力很难扩展
错误难以隔离
业务复杂度已超出人的认知负载
项目团队间协同成本高， 业务响应越来越慢
应用扩展成本高
传
统
架
构
的
弊
端
用户服务中心
交
类目中心
剥离
商品中心
店铺中心
务化改造（ SOA+业务模块逐步迁移）
2007年10月开始一系列基于SOA理念新一代服务化框架研发以及采用业务模块逐步迁移的方式进行应用框
架的改造工作。
历时14个月 业务模
块
千岛湖项目
五彩石项目
上百个WAR包独立部署的服务化架几百兆字节WAR包
飞行中的飞机换发动机
拆分
构
务化改造后的效果
降低不同模块开发团队间的协同成本
业务响应更迅捷
业务拆分后解放了对单数据库集群
连接数的能力依赖
数据层也做了拆分，每一个核心服务中
心都拥有各自独立的数据库（分布式数
据库技术）
避免了个别模块的错误
给整体带来的影响
各个服务中心之间完全独立部署
大大降低系统间的耦合度以及整体复杂度
各个开发团队可专注于各自的业务模块
做到针对性的业务能力扩容
减少不必要的资源浪费
SOA的主要特性：
面向服务的分布式计算
服务间松散耦合 口
支持服务的组装
口 服务注册和自动发现
口 以服务契约方式定义服务交互方式
中心化与去中心化服务框架对比
传统软件厂商提出的以ESB（企业服务总线） 实现SOA的方案是中心化服务框架；
互联网架构和技术下，流行去中心化的服务框架 。
有一部分人认为去中心化不是SOA架构。
中心化与去中心化是同一套体系
SOA并没有定义一定是基于ESB总线方式
去中心化分布式服务框架同样遵循SOA架构
的 特征定义
去中心化是中心化服务框架的升级版本， 两
套 系统解决企业根本诉求完全不同 。
ESB模式中心化解决企业实现异构系统之间
的 交互 。核心目的是让企业客户能基于这些
SOA 的产品实现系统间的互联互通 。
去中心化解决的问题是系统扩展性问题。
中心化与去中心化服务框架对比
服务调用方式的不同带来业务的响应和扩展成本
在 立即下单 ”或“ 结算 ”按钮进行下订单的请求， 后端调用了200多个服务 。
服务提供者
服务调用者
服务提供者
服务提供者
服务调用者
传统企业服务总线下的服务交互方式
(1)服务调用者->(2)ESB接受服务请求->(3)服务
提供者(服务处理)->(4)ESB服务提供返回结果-
>(5)服务调用者(服务返回)
经过服务总线路由过的服务交互，共出现4次网络会话创建和数据
传输 ，而去中心化服务架构中服务交互，一次服务的调用只有两
次网络会话创建和数据传输，在网络上的开销整整减少了一半。
企业服务总线（ ESB）
服务调用者
分布式服务架构中的服务交互方式
服务调用者 服务调用者
服务提供者 服务提供者
中心化与去中心化服务框架对比
雪崩效应束缚了中心化服务框架的扩展能力
去中心化服务框架则可以避免因为个别问题波及整个平
台的业务受到影响， 最多也只是部分服务出现问题， 就
算出现问题也更容问题和故障恢复 。
当10台中一台实例出现故障 ， 服务压力落到剩
余 9 台ESB服务器 ， 每台负载水位将超过88%
， 出 问题 的概率会大增 。如果9台中有一台不
堪重负 而罢工 , 瞬间被访问洪流冲垮 ， 雪崩效
应导致全 军覆没。企业服务总线
ESB服务器
。 。 。 。 。 。
企业服务总线
ESB服务器
企业服务总线
ESB服务器
企业服务总线
ESB服务器
企业服务总线
ESB服务器
企业服务总线
ESB服务器
企业服务总线
ESB服务器
服务器集群
（假设10台）
阿里巴巴分布式服务框架HSF （ High Speed Framework）
HSF旨在为淘系的应用提供一个分布式的服务框架， HSF从分布式应用层面以及统一的发布/调用方式层面为大
家提供支持， 从而可以很容发分布式的应用以及提供或使用公用功能模块， 而不用考虑分布式领域中的 各种
细节技术， 例如远程通讯 、性能损耗 、调用的透明化 、同步/异步调用方式的实现等等问题 。
阿里巴巴分布式服务框架HSF （ High Speed Framework）
按照服务注册发布 、服务订阅 、服务规则推送 、最终服务提供者和服务调用者间的服务交互的
顺序说明了 HSF 服务框架中每个组件在整个框架中所扮演的角色。
HSF 服务框架实现服务高可用性原理示意图
阿里巴巴分布式服务框架HSF （ High Speed Framework）
HSF 服务框架对服务能力线性扩展支持
作为 HSF 框架设计之初， 最为重要的一个特性就是服务能力的可扩展性 。也就是真正的做到某个
服务的业务 处理能力能随着服务器资源的增加得到线性的增长 。
当服务面对较大的服务调用压力或将要面临如天猫双11大促 、秒杀等活动前， 已有的服务提供者各服务
器水位（ CPU 、内存 、 IO等）处于比较高的情况或现有服务能力满足不了业务访问量的要求时，则
需要通过增加服务节点数量的方式提升该服务的 服务处理能力 。基于 HSF 框架的运行机制，新增加的
服务提供者实例一旦应用启动完成后，可在几秒内开始进行服务请求的 处理（主要完成服务注册发布
、更新后服务列表推送到服务调用者端） ，从而达到分担其他服务器实例压力的作用 ，实现服务 能力
整体水位恢复到正常的状态
微服务架构典型特征
• 分布式服务组成的系统
• 按照业务而不是技术来划分组织
• 做有生命的产品而不是项目
• 智能化服务端点与傻瓜式服务编排
• 自动化运维
• 系统容错
• 服务快速演化
微服务
从本质上来说 ，微服务是SOA的一种演变后的形态， 与SOA的方法和原则没有本质的差别。
特征 传统SOA 微服务
分布式服务组成的系统
中心化构建服务架构；采用系
统提供服务的方式
多个分布式的服务组成
按照业务而不是技术来划分组
织以及做有生命的产品而不是
项目
项目方式实施
产品方式让服务在业务发展过
程中快速演化
智能化服务端点与傻瓜式服务
编排
所有核心能力都运行在ESB上 更加强调能力向服务端的迁移
自动化运维和系统容错
运维管控和平台高可用性和稳
定性提出更高要求
微服务与传统SOA特征差异
共享服务中心
建设原则3
中心建设历程
服务和服务中心都是伴随业务发展变化的， 体系的发展从服务化到平台化。
全面服务化阶段 进入平台化阶段尝试服务化阶段
用户中心
商品中心
评价中心
营销中心
库存中心
交
店铺中心
用户中心
商品中心平台
交平台
营销中心平台
店铺中心
库存中心
库存中心
店铺中心
用户中心
商品中心
交
服务中心中的服务形态多样性
有些人理解的服务中心是狭义的接口服务， 这比较片面化， 接口是服务最主要的形式
。 如果服务中心的服务完全拘泥于接口这种形式 ，那又大大局限了服务中心的服务能力。
依赖于数据的服务
对大数据的分析能力
实时交数据能力一定是通
过接口服务对外暴露
依赖于接口的服务
上层应用提供编程接口
RPC或Web API
依赖于工具的服务
一类用于提供定制的配置服务
一类是运营管理类的工具
交
交
会员中心
会员数据
一个服务中心可以进一步划分吗？
服务中心是根据业务和数据的完整性与独立性来设立的， 并不需要一一对应 。往往需要多个子服务
模 块协作配合才能更好地实现服务中心对外服务效率的最大化。
单个服务模块 多个服务
模块
共
享
服
务
层
购物车服务会员服务 订单服务
数
据
设计 运
营
工程
基于分布式架构， 要综合评估业务层对服务中心在数据库 、业务以及运营方面的需求和技术上需要的投入。
完整的业务模型， 要有数据运营和
业 务整合的价值。
服务中心划分原则-考量方面
遵循面向对象的分析和设计方法
高内聚 、低耦合原
则
数据完整性原则
业务可运营性原则
渐进性的建设原则
服务中心划分原则
数据拆分实现
数据库能力线性扩展4
数据库瓶颈阻碍业务的持续发展
采用读写分离的方式， 拓展了数据库对数据读的处理能力， 主数据库的写入能力依然没法扩展。
单表数据量是有限的， 当达到一定数量后数据库性能会出现显著下降。
主数据库
写
数据复制
从数据库
… …
从数据库
从数据库
采用读写分离方式扩展数据库读写能力
读
数据库水平分区实现数据拆分
将同一个表中的不同数据才拆分到不同的数据库中。
以用户中心为例， 量接近6亿 ，存到一个数据库的单表是不可能的。
用户中心数据库
UserID %8=1
UserID %8=2
UserID %8=3
水平分区
>
用户数据按用户ID取模机型数据均衡拆分
! UserID %8=0
用户中心应用
… …
数据库分库分表的实践-Cobar分布式处理系统
2006年阿里巴巴B2B团队以开源方式研发了Cobar关系型数据的分布式处理系统 。
解决了Oracle数据库因为存储数据变得越来越大带来的扩展性问题。
不支持跨库情况下的连接 、分页 、排序 、子查询操作
SET语句执行会被忽略 ，处理事务和字符集设置除外
> 分库情况下， insert语句必须包含拆分字段列名
> 分库情况下， update语句不能更新拆分字段的值
不支持SEPOINT操作
> 使用JDBC时， 不支持 rewriteBatched Statements= true参数设置（默认 false）
使用JDBC时， 不支持useServerPrepSt mts=true参数设置（默认为 false）
使用JDBC时， BLOB 、BINARY 、VARBINARY字段不能使用set Blob（ ）或set BinaryStream()方法设置参
数
TDDL其实主要可以划分为3层架构，分别是Matrix
层 、Group层和Atom层。
> Matrix层用于实现分库分表逻辑， 底层持有多个
Group实例 。而Group层和Atom共同组成了动态数
据 源
> Group层实现了数据库的Master/Salve模式的写分离
逻辑， 底层持有多个Atom实例 。
> Atom层 ( TAtomDataSource)实现数据库
ip, port, password, connectionProperties等 信 息 的
动 态推送,以及持有原子的数据源分离的JBOSS数据
源）
数据库分库分表的实践-TDDL
2008年阿里巴巴基于的需要 ， 在Cobar的基础上重新研发了分布式数据层框架TDDL（ Taobao Distributed Data
Layer） ，针对分库分表场景 ， 提供了对各种业务场景的支持更加完善 ， 开发人员体验更好 ，
管 控能力大幅提升 。
I bat is Spring jdbc template
JDBC Driver
TDDL group ds
TDDL matrix ds（ TDataSource ）
TDDLatomds（ with jboss ds ）
MySQL Oracle
TDDL架构示意图
数据库分库分表的实践-TDDL
选 择 groupDS
执行SQL
根据权重选
AtomDS
具有重试策略地在
AtomDS执行SQL
规则计算 表名替换SQL解析
执行SQL ，返
回结果集
读写数控制 、线
程并发数控制
合并处理多个
结果集
TDDL针对一次SQL请求完整处理流程
查询或更新结果
SQL和参数
TDDL分库分表查询策略
TDDL优点：
1 、数据库主备和动态切换；
2 、带权重的读写分离；
3 、单线程读重试；
4 、集中式数据源信息管理和动态变更；
5 、剥离的稳定jboss数据源；
6 、支持mysql和oracle数据库 ；
7 、基于jdbc规范， 很容支持实现jdbc规范的数据源；
8 、无server,client-jar形式存在， 应用直连数据库；
9 、读写次数,并发度流程控制， 动态变更；
10 、可分析的日志打印, 日志流控， 动态变更 。
数据库分库分表的实践-TDDL
TAB 7
TAB_8
5 异步化与缓存原则
业务流程异步化
平台进行服务化后， 在平台页面上发起的业务请求势必需要将后端不同的服务进行组合调用来实现业务请求的
处理 。以单为例， 目前建流程需要调用200个服务 。如果按照顺序执行， 需要超过4s
按服务线性处理的示意图
缺点：从资源占用角度来说，顺序调用方式会造成系统处理一次前端请求所花的时间较长，对服务器整体的系统吞吐量带来巨大影响。
异步化后的处理的示意图
平均时间控制在300ms ，体验好， 吞吐量几何倍数提
升
订单日志消息中间件
库存预减流水
其它服务
支付生成
消息中间件库存预减
订单生成
其它100
多个服务
订单
生成
库存
检查
库存
预减
交易
日志
支付
生成
扣占款
给详单对应借款人账号转入钱
更新还款详单表
解决平台性能问题的核心是数据库
事务的异步化 。将大事务拆分成小
事务 ， 降低数据库的资源被长时间
事务锁占用而造成的数据库瓶颈 ，
就能大大提升平台的处理吞吐量和
事务操作的响应时间 。
基于消息服务提供
的异步机制，将整
个还款流程进行异
步化的处理。
整个平台对还款的
处理能力相比之前
提升了20倍以上。
发起还款请求
借款人账号占款
计算还款金额
数据库事务异步化
还款计划处理（循环）
用户还款流程
计算还款详单
TXC也是阿里基于两阶段提交理论实现的分布式事务框架 ， 支持分布式数据库事务 、 多库事务 、消息事务
、 服 务链路调用事务及各种其他事务 。和支付宝XTS框架相比 ， 主要区别有两个： 一是主事务和分支事务
都是 维护 在同一台TXC服务器上的； 二是事务回滚或补偿代码不需要开发人员编写 ， 平台支持自动生成 。
阿里巴巴AliWare TXC事务服务
GTS是一款分布式事务中间件 ， 由阿里巴巴中间件部门研发 ，可以为微服务架构中的分布式事务提供一站式解决方案 。GTS包括客
户 端（ GTS Client） 、资源管理器（ GTS RM） 和事务协调器（ GTS Server） 三个部分。GTS Client主要用来界定事务边界 ，完成事
务的 发起与结束 。GTS RM完成事务分支的创建、提交 、回滚等操作 。GTS Server主要负责分布式事务的整体推进 ，事务生命管理。
大促秒杀活动催生缓存技术的高度使用
tair 是的一个分布式 key/value 存储引擎 ， tair 分为持久化和非持久化两种使用方式 ， 非持久化的tair 可以看成 是 一个分布
式缓存 。持久化的 tair 将数据存放于磁盘中， 为了解决磁盘损坏导致数据丢失， tair 可以配置数据的备份数目 ， tair
自动将一份数据的不同备份放到不同的主机上 , 当有主机发生异常 , 无法正常提供服务的时候， 其余的备份会继续提供服务 。
tair 作为一个分布式系统 , 是由一个
中 心控制节点和一系列的服务节点组
成 . 我们称中心控制节点为config
server. 服务节点是data server。
• config server 负责管理所有的
data server, 维 护 data server的 状
态信息 。
• data server 对外提供各种数据服
务 , 并以心跳的形式将自身状况汇
报 给 config server。
• config server是控制点 , 而且是单
点 , 目前采用一主一备的形式来保
证其可靠性 . 所有的 data server
地位都是等价的 。
比如库存为10个 ， 秒杀价格为1元的
手 机则是典型的小库存商品秒杀活动 。
因为商品会在极短的瞬间库存会降到0
, 所以只要处理好商品的库存的扣减
, 不要出现商品超卖的情况就能平稳
地度过这次秒杀活动 。
小库存商品秒杀典型架构
将订单交环节中对于原本 商品
数据库的库存信息操作替换 为
缓存服务器中运行 ， 充分展现
了缓存服务相比于传统数据库在
性能上的巨大优势 。从趋势来看
, 缓存技术将会在互联网应用场
景中将扮演越来越重要角色 。
大库存商品大促架构
6 打造数字化运营能力
业务服务带来的问题
复杂的服务调用关系以及每天海量的服务调用， 而且所有服务都是以点对点的方式进行交互， 导致出现问题时
很 难定位， 甚至出现问题没人承认 。服务开发人员和业务架构师对于分布式服务调用跟踪方面的需求 。
化后错综复杂的服务调用关系图 服务调用流程示意
图
鹰眼平台的架构-核心实现思路
如果把服务架构比喻为遍布全国的高速公路网络， 每一次的页面请求可以认为是一辆汽车在这个 高速公路网
络中穿行把高速上每一个收费站比喻为处理请求的服务 。那么我们希望查看一辆汽车在高速上的行 走轨迹，
如何实现？最简单的方法就是在这辆车每次经过收费站的时候记录下车辆通过的时间和相关信息， 并 将这些
信息统一发送到服务器端保存起来。
鹰眼平台的核心实现思路就是通过一套分布式日志平
台实现对服务调用链路的跟踪。
[2013-05-01 12:23:34]鲁A123BC，平度2,516，济南， $0
[2013-05-01 12:23:40]鲁A987DE ，平度2,516 ，淄博 ，$10
[2013-05-01 12:43:15]鲁A123BC ，潍坊1,520，济南， $18
[2013-05-01 13:38:29]鲁A123BC ，青州西1,G20 ，济南，$10
[2013-05-01 13:38:30]鲁A567AB，青州西2,G20，廊坊， $10
[2013-05-01 14:39:27]鲁A123BC，淄博3,G20 ，济南，$15
[2013-05-01 16:42:58]鲁A123BC，济南3,G20 ，济南，$25
-[2013-05-01 12:23:34] 平度2，旅途开始
-[2013-05-01 13:38:29]青州西1,耗时75分钟,路费10元 -
[2013-05-01 14:39:27] 淄博3,耗时61分钟，路费15元 -
[2013-05-01 16:42:58] 济南3,耗时123分钟，路费$10元
某辆车经过不同高速收费口日志记录信息汽车通过高速收费口日志记录信息
鹰眼平台是阿里巴巴中间
件 团 队 自 主 研 发
的 Jstorm 流式计算引擎
, 对应用集群接收到的
日志 进行内容的解析拆
分 ，按 照不同业务场景
的需求将 拆分后的数据
保存到不同 的存储系统。
鹰眼平台的架构
serverRecv
serverSend
serverRecv
clientRecv
clientSend
clientRecv
clientSend
数据访问
数据访问
serverSend
埋点和输出日志
将实现服务调用 、各种资源的访问所需要生成服务链路日志， 以及TraceID传递等功能的代码（称为埋点） 植
入 到服务框架层和各资源的访问驱动层， 也就是在中间件层面上统一实现了鹰眼的上下文创建以及日志埋点功
能。
图示
创建
上下文
清理
上下文
响应
clientRecv
start
T
clientSend
endTrace
clientSend
clientRecv
后端应用2 数据库后端应用1前端应用
服务响应
服务响应
服务调用
服务调用
请求
典型业务场景-调用链跟踪
典型业务场景-链路分析
典型业务场景-业务全息排查
运维和开发人员通过业务轨迹的方式， 在查看某一业务请求服务调用跟踪的同时， 也能看到服务中所产生的
业 务事件以及相关业务主键 。通过全息排查平台， 将鹰眼平台从对跨系统调用跟踪升级为跨业务领域追踪，
走出 了从运维平台向运营平台转型的重要一步。
7 打造平台稳定性能力
限流和降级
限流的作用相当于电路上的保险丝 ， 当过载的时候掐掉一些流量 ， 让系统有能力集中资源以较快的速度处理平
台 处理能力范围内的业务请求 。 比如在大促场景中 ， 仅让1000万用户中的100万用户进入后端的处理流程中 ，
将
其 余900万用户通过队列排队或直接阻挡在平台处理单元之外的方式 ， 保障平台能在处理能力范围内对100万
的户用请求进行处理。
前端请求
服务2集群 服务3
数据库集群
服务1集群
集群
数据库集群 数据库集群
应用集群 应用集群应用集群
Nginx集群
接入层是最佳限流点
最合适的限流拦截点
限流平台Sentinel(哨兵)架构
限流平台Sentinel的出现 ， 为整个服务化体系的稳定运行行使着警戒任务 ， 是对资源调用的控制平台， 主要涵盖了授权 、
限 流 、降级 、调用统计监控四大功能模块 。
规则中心
Diamond
Sentinel客户端
我的应用监控系统
Db
应用D
Tair
应用C
应用A
应用B
运行态监控
规则推送
操作权限
规则配置
控制逻辑
日志
数据接口
限
流
降
级
授权
限流
控制台
流量调度平台
流量调度实现原理
核心是通过妙级获取服务器系统运行指标以及业务指标， 通过流量调度平台设置的决策算法以及规则， 当发现满足规则条件的指
标 状态发生时， 对线上环境的服务器进行下线扥该操作， 以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影
响 。
机器
tomca
t
syste
m
机器
tomca
t
syste
m
无线统一接入
前端应用
机
机
器
器
后端应用
Hsf
上线
VipServer
ConfigServer
妙
级
服
务
状
态
探
测
收
集Restful API
Restful API
互斥因子
决
策
算
法
恢
复
模
块
机器指标监控
obproxy监控
人工决策接口
应用状态监控
服务状态视图
业务状态监控
权重计算
决策数据接口
规
则
中
心
执
行
模
块
http
PC &
降权
下线
机器
降权
下线
机器
下线
机器
机器
通知
告警
hsf
hsf
权限报表 日志
request
传统的互联网应用系统的性能测试
• 测试场景简单
• 线下环境（测试环境） 中测试出的结果与线上环境（生产环境）并
没有对比关系
• 测试场景是否能准确的体现出真实场景很大程度上取决于测试人员
的经验和水平
面向分布式应用架构下应用系统容量压测和评估的自动化平台
• 实用性 ：准确容量预测，系统性能回归测试提供完整的测试场景 、
测 试方法 、同时建立系统的性能基线，供后续的系统改造复用。
• 准确性：模拟生产系统实时变化的复杂流量场景，压测流量模拟具备
了业务的真实性 、全面性 、业务变化的连续性。
• 高效性：所有的建模 、压测 、分析 、预测基于同一平台， 同一种监
控 方式， 同一种分析方法，一切都是自动化，效率比常规方法倍增。
容量压测及评估规划
阿里自动化平台通过对生产环境上的流量模型引流到压测服务器上， 获取到服务实例单机最大处理能力， 结合
不 同型号服务器处理能力以及生产环境的水位监控信息， 对服务集群所需部署的服务器数量进行容量评估及预
测 。
业务一致性平台
面对业务与数据不一致的问题， 业务稳定性保障迫在眉睫 。在这样的背景下， 实时业务审计平台（ Business Check
Platform, BCP） 应用而生， 这个平台采用规范与标准化业务规则的方式， 统一解决平台服务化后越来越凸显的业务一致性问题 。
规则工厂
通过类型分大类
如：订单 、逆向
…
通过数据状态分小类
如：创建 、付款
…
BCP平台业务处理流程示意图
规则
运行
规则中心
运行过滤规则
检测采样率
执行规则
数据来源
DB变更消息
消息服务消息
日志消息
规则
获取
事件
构造
结果
存储 报警
数据
触发
数据处理
记入数据库
并产生日志
共享服务中心
对内和对外的协作共享8
共享服务中心服务化实施阶段
服务化实施划分为APIAS service 、Product AS Service 、Solution as Service三个阶段。
Self-Service
1 .API as
Service
2. Product as
Service
3. Solution as
Service
API export
HSF其它基础
服务
Serve
r
Side
其它
业务
会
员
交
易
商
品
Clien
t
Side
bined-
TDDL Diamond
API 元数据
API
MetaQ
Notify
Service
Service
↓
参与角色 对应的应用列表 协作方式
共享服务平台 SPAS
• 建设服务Portal等基础设施
• 建设应用服务的应用账号系统，建立起应用 、服务 、服务提供者和消费
者概念
• 实现服务治理的基础能力
• 协某省市场参与方一起制某省市场的规范并用产品的方式实现
• 帮助业务方接入到服务化平台
服务提供者
商品 、交易 、UMP 、店铺 、物流 、库存 、推荐 、 猫 、聚
划算等
• 与SPAS一起制定服务化的基础规范并落地
• 把应用和服务接入到服务化平台，利用SPAS的基础工具把服务结构化 、
规范化，方便消费者的接入
• 利用服务化工具建设自己的应用领域的特色的 、个性化的 、高质量的服
某省市场
• 利用SPAS的服务治理工具管理自己的服务；安全控制 、运维管理 、服务
质量报告 、成本核算 、对消费者支持
• 提供场景化的解决方案的服务
HSF 、MetaQ 、Notify 、Diamond 、ConfigServer 、
TDDL 、EagleEye 、搜索等基础分布式中间件
• 作为分布式服务的基础通道接入服务化SDK以实现对上层服务化的支持
• 共建服务治理控制台
服务消费者
商品 、交易 、UMP 、店铺 、物流 、库存 、推荐 、 猫 、聚
划算等（消费者通常也是服务提供者）
• 使用SPAS发现需要的服务，并接入
• 使用SPAS的辅助开发工具提高服务接入的效率
• 利用SPAS的SLA支持工具与服务提供方达成服务的细粒度协议支持
• 获取服务的质量报告和调用分析
• 获取服务提供方的在线支持
共享服务平台(SPAS)与业务方协作
阿里巴巴共享服务平台是一个协作平台， 是以服务为对象建立的一某省市场 ，某省市场中有三个角色： 服务 共
享平台 、服务提供者 、服务消费者。
业务中台对前端核心业务的紧密沟通机制
各服务中心的核心架构师和运营人员会定期参与前端业务方的业务会议（比如）或重要项目的研讨会（比如双11大促） 让
业务中台对于前端重要应用的业务发展动向有一个准确 、及时地了解，从而为业务中台如何更好第支撑这些业务做好准备
和服务能力的提升。
岗位轮转推动真正换位思考
比如将业务中台某服务中心的负责人与天猫对口业务的负责人进行岗位对调， 让双
方在实际的工作中更真切地感知到处于不同岗位时对业务的理解和出发点 。
建立分歧升级机制
出现中台与前端应用的争执时， 一般按照业务负责的层级
关系依次升级
业务中台与前端应用协作
业务中台与前端应用
协作机制
避免单纯追求服务的稳定运行而减少
业务的创新和尝试
鼓励团队进行业务创新
考核比重占25% （针对不同的团队和
不同时间会有一定的浮动）
服务中心能否对前端的业务和合作方
提供更好的支持和服务， 获取对业务
中台服务的满意度认可
考核比重占15%
服务造成的事故等级及次数
比如半年内出现两次P1故障，
则此项考核项不达标
考核比重占40%
考量服务能力的专业度以及对
外的服务运营能力
考核比重占20%
服务接入量是
衡量服务价值
的重要考核
业务中台绩效考核
客户满意度促
动服务的提升
服务稳定是重
中之重
业务创新推动
业务发展
