和平统一 微服务场景下的数据一致性解决方案 殷湘 华为PaaS微服务架构师 开源能力中心 大纲 •离 数据一致性的起因 •合 数据一致性的解决方案 •断 方案选择建议 离 数据一致性的起因 单体应用 • 单体应用由于所有模块(A/B/C)使用同一个数据库 • 数据一致性通过数据库事务保证 A B C commit rollback 微服务场景 MySQL MongoDB MongoDB Cassandra 数据一致性无法完全通过数据库保证 离 独立进程 独立部署 独立技术 独立团队 合 数据一致性的解决方案 T1 T2 T3 C2 C1 • 1987年Hector & Kenneth 发表论文 Sagas • Saga = Long Live Transaction (LLT) • LLT = T1 + T2 + T3 + ... + Tn • 每个本地事务Tx 有对应的补偿 transact transact transact B C A Saga compensate compensate 和平统一 减少业务代码集成／运维难度 剥离业务与数据一致性复杂度 和平：低侵入 让运维监控更加简单 可视化事务、调用链 统一：集中式 无状态、可集群、可分片 Event Sourcing架构 高可用 系统架构 – 基于图形 requests

如果准备过程中出现问题，可以回滚 • 提交阶段不不允许出错 • 资源层⾯面提供保障业务侵⼊入性低 • 协议成本⾼高，并且存在全局锁的问题 ACID 与 BASE • ACID • 原⼦子性 （Atomicity） • ⼀一致性 （Consistency） • 隔离性 ( Isolation) • 持久性 (Durability) • BASE • 基本可⽤用（Basically 基本可⽤用（Basically Available） • 柔性状态 （Soft state） • 最终⼀一致性 （Eventually Consistent） （刚性事务） （柔性事务） https://queue.acm.org/detail.cfm?id=1394128 TCC • Try: 尝试执⾏行行业务 • 完成所有业务检查，预留留必须的业务资源 • Confirm：确认执⾏行行业务 释放Try阶段预留留的业务资源 业务服务 try confirm cancel 通过领域建模来解决 • 微服务内：聚合通过数据库事务保证强⼀一致 • 内刚 • 微服务间：最终⼀一致 • 外柔 微服务事务⼀一致性建议 • 1987年年Hector & Kenneth 发表论⽂文 Sagas • Saga = Long Live Transaction (LLT) • LLT = T1 + T2 + T3

如果准备过程中出现问题，可以回滚 • 提交阶段不不允许出错 • 资源层⾯面提供保障业务侵⼊入性低 • 协议成本⾼高，并且存在全局锁的问题 ACID 与 BASE • ACID • 原⼦子性 （Atomicity） • ⼀一致性 （Consistency） • 隔离性 ( Isolation) • 持久性 (Durability) • BASE • 基本可⽤用（Basically 基本可⽤用（Basically Available） • 柔性状态 （Soft state） • 最终⼀一致性 （Eventually Consistent） （刚性事务） （柔性事务） https://queue.acm.org/detail.cfm?id=1394128 TCC • Try: 尝试执⾏行行业务 • 完成所有业务检查，预留留必须的业务资源 • Confirm：确认执⾏行行业务 释放Try阶段预留留的业务资源 业务服务 try confirm cancel 通过领域建模来解决 • 微服务内：聚合通过数据库事务保证强⼀一致 • 内刚 • 微服务间：最终⼀一致 • 外柔 微服务事务⼀一致性建议 • 1987年年Hector & Kenneth 发表论⽂文 Sagas • Saga = Long Live Transaction (LLT) • LLT = T1 + T2 + T3

http://servicecomb.incubator.apache.org/ Gitter: https://gitter.im/ServiceCombUsers/Lobby 适合异步的业务采用全栈异步架构，提升性能和可靠性 异步场景1：降低长流程/复杂业务流程时延：消费端需要调用多个微服务，进行业务逻辑编排，多个微服务之间没有执行先后顺序 和参数依赖，可以通过异步微服务调用并行执行 异步场景2：性能提升：使用更少 时延达到超时阈值，系统很容易被压挂 异步场景4：级联调用：需要级联调用多个微服务，希望提升可靠性，不会因为某个微服务处理慢而导致其它微服务调用被阻塞 传统I/O和业务线程分离技术： 纯Reactive异步： 性能对比测试：采用Reactive异步模式之 后，TPS提升 43% 左右、时延降低 28% 左右，CPU占用降低 56% 左右 实践-故障隔离 Website: http://servicecomb.incubator 利用ServiceComb的隔离仓技术，实现业务不同接口的故障隔离 充值服务 APP付费下载服务 APP评论服务 业务线程池 手机客户端 WAP客户端 图书门户 单点故障 故障扩散 故障扩散 无线程池隔离仓： 充值服务 开户服务 客户资料查询服务 其它非关键服务 隔离仓-1 隔离仓-3 手机客户端 WAP客户端 图书门户 单点故障 正常 正常 隔离仓-2 配置隔离仓：

透明RPC CSE在消费者云业务的实践-可靠性 1、分布式服务化本身引入的潜在故障点： 2、微服务第三方依赖潜在故障点： CSE的可靠性设计：  集群容错，自劢路由  服务中心、配置中心无状态集群，宕机丌影响已有业务  支持服务级故障隔离  支持多链路和链路级故障隔离  支持服务熔断和降级，以及第三方故障隔离（集成Hystrix） CSE在消费者云业务的实践-服务调用高性能 CSE在消费者云业务的实践-服务调用高性能 CSE的高性能设计：  提供Rest和Highway RPC两种通信协议，满足 丌同业务场景  高性能的Rest：集成Vertx,底层基于Netty，性 能比传统Servlet NIO性能高X倍  Highway RPC：采用Netty + PB，既支持多语 言，又保证高性能  高性能幵发设计：线程绑定技术，网络I/O线程 绑定后端的服务调度线程，最大限度减少锁竞 绑定后端的服务调度线程，最大限度减少锁竞 争。采用连接池机制，重用已有的连接 CSE在消费者云业务的实践-分布式事务 1、服务化乊前本地事务： 2、服务化乊后引入分布式事务： 解决方案：CSE提供数据最终一致性方案-Saga CSE在消费者云业务的实践-服务治理能力 为什么需要服务治理：  随着业务的发展，服务越来越多，如何协调线上运行的各个 服务，保障服务的SLA，对服务架构和运维人员是一个很大

。 微服务的微 微服务的两个“谬论” n 服务之间是强隔离的。 n 微服务是大型系统的唯一选择。 解耦合 独立开发部署 架构、组织、流程 微服务架构定义“三步法” 微服务拆分方法 微服务拆分-指导原则 拆服务-单体重构的节奏 服务分解的四大障碍 1、网络延迟 2、同步通信降低了可用性 3、跨服务的数据一致性 4、上帝类 微服务的忠告 n 第一，要记住微服务不是解决所有问题的万能 还必须记住：实现微服务架构并不是你的目标。你的目标是加速大型复杂应用程序的开发。 --Chris Richardson 容错 故障和问题 线上故障“画像“ 系统稳定性指标 可监控设计 同步调用下-无线程池隔离 同步调用下-线程池隔离实现方法 快速失败-超时 快速失败-时间窗口 快速失败-超时重试次数 区分部署和上线 常规系统保障流程 没有不出问题的系统 什么是混沌工程 混沌工程 故障注入 故障测试的区别

Executor Queue Thread Pool Logic Logic 5 github.com/apache?q=servicecomb servicecomb.apache.org 可靠性 • 隔离仓 servicecomb: executors: Provider: [schemaId]: [operationId]: executorForSlowMethod • 丢弃策略 servicecomb:

营销平台 接口服务 消息 REST NAT网关 NAT gateway 4核8G 按需扩容 4核8G 按需扩容 Nginx 按需扩容 My SQL 高 可 用 安全组隔离 安全组隔离 安全组隔离 ELB C端流量 8 github.com/apache?q=servicecomb servicecomb.apache.org 以微服务方案为底座的服务化改造 主机厂CRM运营 （etcd增强） 治理中心 （Hystrix+Rib bon增强） 新业务 数据库 华为云CSE介绍 Apache ServiceComb 公有云对接能力 安全管理 分布式数据一致 性 REDIS 缓存 OBS存储 缓存 X-API_KEY HTTPS/HTTP 服务注册 数据库 API调用 （ACCESS_TO KEN) 9 github.com/apache

提供标准接口（RESTful） 2. 负载均衡，服务订阅（客户端LB，长连接） 3. 运行时依赖（Go） 4. 可靠性（BASE，最终一致性） 从服务注册中心到服务管理中心 1. 元数据 2. 依赖关系 3. 实例变化推送 4. 多租隔离 5. 高可用性保障 从服务注册中心到服务管理中心 元数据 1. 应用App，便于微服务可在多个应用间重用 2. 微服务名称，App内唯一 微服务标签，支持按标签检索 高可用性保障 互联网分布式系统设计的准则：BASE 1. Basically Available（基本可用） 2. Soft state（软状态） 3. Eventually consistent（最终一致性） CAP理论：Consistency(一致性), 在分布式系统的各点同时保持数据的一致。 Availability(可用性), 每个请求都能接受到一个响应，无论响应成功戒失败。 每个请求都能接受到一个响应，无论响应成功戒失败。 Partition tolerance(分区容错性)，当出现网络分区故障时系统的容错能力 从微服务到服务管理中心 1.实例缓存机制 从微服务到服务管理中心 2.心跳保活机制 从服务管理中心到etcd 1.异步缓存机制 从服务管理中心到etcd 2.异步心跳机制 自我保护机制 前面提到的缓存机制，保证了ServiceCenter在etcd出现网络分区故障时依

逻辑架构 核心设计解析(&)：SDBnnEP - 服务状态监控系统 定t：中心化节点健康监测；负责监控/更新节点状态 q势：相对于点对点心跳，基本不r增加b务应用负载，确保节点状态全局唯一性 核心设计解析(&)：SDBnnEP V 特点解析 ���� �� Akka Actor � ��10� ���� ����! ����� ����� �����! ����� Detector 胜p%千万订单量级b务 星耀 Ø 跨地区容灾和扩展能力 Ø 数千万订单量级b务强需 求 青铜 Ø 基础能力达标 铂金 Ø 性能一流 Ø 足n支撑数百万订单量级b务 Ø 易用性q秀 服务治理演进各c阶段 服务治理实践(%)：基础能力达标 - 青铜段t 监控报警 数据分析 • 性能指标 • 来源去向 • f机分析 • 数据报表 • 调用链路 HTTP�����DNS�Nginx���������������! • ���������OCTO-RPC�����������! • ���������������! 服务治理实践(3) +易用性 - 黄金段t ����� ��! • ���������SGAgent��������OCTO-Portal! • ������������! ����� ��! • ��������������������