阿里巴巴中台战略思想和架构

贰 错误难于隔离
叁
应用扩展成本
高
应用复杂度已 肆 超出人的认知
负载
伍
数据库的连接
能力很难扩展
早期淘宝All-In-One框架存在 的问题
早期淘宝All-In-One 框架存在的问题
项目团队间协同成本高， 业务响应越来越慢
应用复杂度已超出人的 认知负载
错误难于隔离
数据库的连接能力很难 扩展
应用扩展成本高
服务中心的业务架构师（业务发展的领路者、核 心业务的通用性与公用性的捍卫者）
03 分布式服务框架
分布式服务框架
早期淘宝All-In-One框 架存在的问题
淘宝平台服务化改 造
中心化与去中心化 的服务框架对比
阿里巴巴分布式服 务框架HSF
微服务
分布式服务框架
项目团队间协同
壹
成本高，业务响
应越来越慢
全链路压测平台
主要对零点峰 值流量进行评 估，以及对网 站承压能力进
行测试
全链路压测平 台同时处理正 常流量和测试
流量
基础数据抽取
链路和模型构 造
链路验证
业务改造
全链路压测平台
数据平 台
流量平 台
影子表
中间件 改造
安全机 制
全链路压测平台
基础数据抽取
以线上数据为数据源，进行采样、过滤、脱敏 数据量与线上数据保持同一个数量级 在数据库的sequence_id进行区间隔离
打造平台稳定性能力
业务开关
配置中心
容量压测及评估规划
充分的性能测试
测试环境模拟测试的系统最大负载能力缺陷：1）测试环境简单：2）线下环境中的测试结果与线上环境 没有对比关系
系统容量压测和评估的自动化平台 生成环境上的流量模型引流到压测服务器上，获得服务实例单机最大处理能力
容量压测是将生产的真实流量引流到压测目标服务器上 通过分布式服务框架对服务路由权重的支持，逐步增加压测服务器的生成流量 压测服务器的运行检测，达到阈值水位后自动停止压测 容量规划平台：服务的单机QPS+服务器机型处理能力差异分析 推测 需要部署的服务器资源
2
应用级限流框架 Sentinel:授权、 限流、降级、监控
流量预测算法
流量调度平台
背景 个别服务器出现问题(单点故障)给整
个调用链路带来更大的影响 需要根据机器的实时服务能力来分配 机器实时流量
实现原理 收集服务器的运行指标和业务指标
流量调度平台根据设置的决策算法和 规则对线上服务器进行下线等操作 系统指标：CPU、LOAD等 业务指标：HTTP响应时间、QPS、 TOMCAT线程池等
小的前端团队优势
团队协同效率最高 对商机的把握更加敏锐 调整方向更加快捷 一旦发现正确目标，全力投入扩大战果
为真正发挥大数据威力做好准备
大数据项目落地存在的问题 数据分布广、格式不统一、不标准
缺少能基于数据有业务建模能力的 专家
共享服务体系的解决方法 各个业务领域中心对业务数据进行
了很好的规整和沉淀 共享服务体系能帮忙企业培养技术+ 业务的大数据人才
阿里巴巴中台战略思想和架构实现
演讲人
2020-09-08
01 中台战略背景
中台战略背景
壹
“烟囱式” 架构弊端
贰
业务支持一 直是企业信 息中心的组 织职能
叁
架构改造目 标
中台战略背景
“烟囱式”架构弊端
壹
重复的功能建设和维
护带来的重复投资
打通“烟囱式”系统间
wk.baidu.com
交互的集成和协作成本
贰
高昂
叁
不利于业务的沉淀和
05
Diamond 服务器（配
置中心）
HSF框架的主要组件
阿里巴巴分布式服务框架HSF
01
服务节点对 配置服务器 列表的获取
02
服务的注 册发布
03
服务的订 阅
04
服务规则 的推送
05
服务交互
HSF主要组件交互
HSF框架的实现
采用Netty+Hessian数据序列化 协议实现服务交互
容错机制
自动重试（我们未开启，需要服 务端保证幂等） 服务故障机器摘除
服务中心一定是不断发 展的
服务中心中的服务形态 多样性
依赖于接口的服务 依赖于工具的服务 依赖于数据的服务
一个服务中心可以进一 步划分吗？
服务中心的划分原则
服务中心的设计和评估维度 设计层面：业务和系统建模遵循面向对
象的基本原则 运营层面：业务中心是一个完整的业务模 型，要有业务运营和数据整合的价值 工程层面：评估业务层对服务中心在数据 库、业务以及运营上的需求和技术上需要 的投入
淘宝平台服务化改造
避免了个别模块的错误给整 体带来的影响
大大降低系统间的耦合度以 及整体复杂度，各个开发团 队可专注于各自的业务模块
业务拆分后解决了对单 数据库集群连接数的能 力依赖
降低不同模块开发团队 间的协同成本，业务响
应更迅捷
做到针对性的业务 能力扩展，减少不 必要的资源浪费
分布式服务框架
微服务
微服务化的应用
壹
架构如何有效的
进行服务管控
贰
自动化运维和
平台稳定性
原有组织架构是否
叁
满足微服务架构持
续发展的需要
肆
分布式事务难
题
伍
微服务的服务
设计
构建微服务架构遇到的问题
04
共享服务中心构建原则
共享服务 中心构建 原则
淘宝共享服务中心概貌
用户中 心
交易中 心
商品中 心
商铺中 心
什么是服务中心
划分组织
05
自动化运 维
03
做有生命 的产品而 不是项目
06
微服务的典型特征
系统容错
微服务
微服务的典型特征
服务快速演化
微服务
01
分布式服 务组成的
系统
02
按照业务而 不是技术来
划分组织
03
做有生命 的产品而 不是项目
04
智能化服务 端点与傻瓜 式服务编排
05
自动化运 维和系统
容错
微服务与传统SOA的差异
01
服务调用方式的不同带来的业务影 响和扩展成本
02
雪崩效应束缚了中心化服务框架的 拓展能力
两套服务框架的对比
HSF框架的主 要组件
分布式服务框架
阿里巴巴分布式服务框架HSF
HSF主要组件 交互
HSF框架的实 现
阿里巴巴分布式服务框架HSF
01
服务提供 者
02
服务调用 者
03
地址服务 器
04
配置服务 器
持续发展
中台战略背景
壹
转变技术部门作为“业务支持” 的职能位置
叁
对业务流程如何进一步优化以 便更好的提升业务
贰
开发对业务的下一步发展有自 己的理解和看法
肆
对企业现有的业务提出创新的 想法
业务支持一直是企业信息中心 的组织职能
中台战略背景
架构改造目标
框架路线必须满足至少10年的集团业务发展要求
02
整体依赖情况怎 么样？
接口出现性能问 题，是哪个环节 造成的？
打造数字化运营能力
业务服务化带来的问题
负责的服务中，哪些服务出错率较高？哪些可能存在瓶颈？
打造数字 化运营能 力
分布式服务调用链跟踪平台
每次请求全局 唯一ID， traceId
01
生成运行异常 等情况监控告 警
03
用户某一次调 用链全流程日 志查询与异常 排查
业务流程异步化
消息中间件
异步化与缓存原则
A
小事务之间使用消 息中间件通知机制
大事务拆分成小 事务
B
数据库事务异步化
事务与柔性事务
01 事务ACID理论(原子性、一致性、隔离性和持久性)：强一致性模型
02 CAP理论(一致性、可用性、分区容错性)：分布式系统最多满足2项
03
BASE理论(基本可用、柔性状态、最终一致性)：分布式系统牺牲强一致性获得高可用 性
基本原则 高内聚、低耦合原则
数据完整性原则 业务可运营性原则 渐进性的建设原则
05 数据库线性拓展
数据库线性拓展
数据库瓶颈阻碍 业务的持续发展
数据库分库分表 的实践
数据库垂直拆 分
数据库线性拓展
数据库瓶颈阻碍业务的持续发展
数据库的读写 分离
分库分表
数据库瓶颈阻碍业务的持续发展
数据库垂直拆分
服务中心拥有各自独立的数据库（高频服务中心存在单机瓶颈）
题
03 优点 确保单个数据库中保存的数据量在单机中能提供良好读写性能
04 需要解决的问题 跨库表聚合、join、事务、数据统计、排序等问题 运维管控提出了更高的要求
数据库线性拓展
数据库分库分表的实践
分布式数据层框架
分布式数据层框架
Cobar
tddl
drds
06 异步化与缓存原则
异步化与缓存原则
中台基础-共享服务体系
中台基础-共享服务体系
面向服务架构SOA-服务重用
基于共享服务体系建设服务中心
中台基础-共享服务体系
服务需要不断的业务滋养
中台基础-共享服务体系
A
培养这些熟悉领域专 家的业务创新能力
培养服务中心特 定领域的专家
B
共享服务体系是培育业务创新 的土壤
赋予业务快速创新和试错能力
叁
提供者接口变化需要服
务调用者都修改的现象
ESB架构降低了系统间
的耦合，更方便、高效
肆
的实现新系统的集成
中心化与 去中心化 的服务框 架对比
去中心化分布式服务架构解决的问题
壹
避免中心点带来的平台
能力难扩展性问题
避免中心点的潜在雪崩
贰
问题
叁
服务提供者与服务调用者 之间无需任何服务路由中
介
中心化与去中心化的服务框架对比
全链路压测平台
链路和模型构造
同一条链路需要构造海量的参数集合，代表不同的用户行为 压测的业务模型：链路范围、链路的访问量级、链路的参数集合、基础数据的特性
全链路压测平台
链路验证
有上百条链路，每一条链路都需要确认全流程引擎跑通 自动化完成对压测链路的验证
全链路压测平台
业务改造
线性扩展
分布式服务框架
微服务
01
02
03
01
微服务的典型 特征
02
微服务与传统 SOA的差异
03
构建微服务架 构遇到的问题
微服务
01
微服务的典型 特征
02
微服务与传统 SOA的差异
03
构建微服务架 构遇到的问题
微服务
01
分布式服 务组成的
系统
04
智能化服务 端点与傻瓜 式服务编排
02
按照业务而 不是技术来
04 柔性事务解决分布式事务问题 引入日志和补偿机制 可靠消息传递 实现无锁
异步化与缓存原则
A
分布式缓存产品 Ta i r 、 R e d i s
C
本地缓存+缓存服 务器+数据库架构
秒杀独立隔离部 署
B
大促秒杀活动催生缓存技术的 高度可用
07 打造数字化运营能力
打造数字化运营能力
业务服务化带 来的问题
分布式服务调 用链跟踪平台
打造数字化运营能 力
业务服务化带来的问题
01
服务调用关系复 杂，问题很难定 位，出了问题甚 至没人承认
02
负责的服务被谁 调用？调用场景 和数据是合理调 用？
03
调用趋势怎么样？ 瞬间峰值多少？ 当前应用的服务 容量怎么样？
04
05
06
当前业务流程设 计中，我依赖了 哪些服务，哪些 应用？
01
面向服务 的分布式
计算
02
服务间松 散耦合
03
支持服务 的组装
04
服务注册 和自动发
现
05
以服务契约 方式定义服 务交互方式
SOA架构的主要特性
中心化与 去中心化 的服务框 架对比
中心化解决的根本诉求
壹
实现异构系统之间的
交互
“烟囱式”架构的各个系
统所采用的技术平台、框
贰
架、开发语言各异
ESB框架避免了因服务
05
02
服务调用实时 监控
04
业务指标监控 告警
08 打造平台稳定性能力
限流降级
限流依赖评估当前 服务实例的最大容
量
当前资源的使用情 况实时监控（指标
收集）
CPU：流量增加时， CPU使用率一般会
正相关上升 响应时间RT：服务 端RT变慢，也是限 流需要考虑的重要
因素
平台级限流拦截点 在前端接入层 Nginx
SOA架构的主要 特性
去中心化分布式服务 架构解决的问题
中心化解决的根 本诉求
两套服务框架的 对比
中心化与去中心化的服务框架 对比
中心化与去中心化的服务框架对比
A
C
中心化解决的根 本诉求
两套服务框架的 对比
SOA架构的主要 特性
去中心化分布式服 务架构解决的问题
B
D
中心化与去中心化的服务框架对比
数据库的读写分离
主库处理事务性的增删改操作，从库专 门负责查询操作
缺点
主库的写入能力无法拓展 单表数据库庞大带来的性能问题
主库中的数据变更同步到从库集群
优点
拓展了数据库对数据读的处理能力， 整体上大大的提高数据库读写能力
分库分表
01 将同一张表中不同数据采用水平分区的方式拆分到不同的数据库中
02 被拆分的表数据尽可能的平均分配到不同的数据库中，避免拆分不均匀，出现新的单表过大问
改变组织阵型会带来组织效能的提升
大多数企业信息部门存在的问题 停留在“业务支持”等偏事务性工
作 使个人能力得不到持续的提升 员工的积极性与创造力被逐渐消磨
共享服务体系组织优越性
员工对自己擅长和感兴趣的服务中心持续运营优 化
员工的业务理解和专业技能使业务中心的业务能 力逐步完善和提升
对员工的工作积极性和创新意识的提升创造一个 良好氛围
分布式服务 框架
淘宝平台服务化改造
降低不同模块开发团队间的协同成 本，业务响应更迅捷
避免了个别模块的错误给整体带来 的影响
做到针对性的业务能力扩展，减少 不必要的资源浪费
2014 2015 2016 2017 2018
大大降低系统间的耦合度以及整体复杂度， 各个开发团队可专注于各自的业务模块
业务拆分后解决了对单数据库集群 连接数的能力依赖