和平统一 微服务场景下的数据一致性解决方案 殷湘 华为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 有对应的补偿 Saga transact transact transact B C A Saga compensate compensate 和平统一 减少业务代码集成／运维难度 剥离业务与数据一致性复杂度 和平：低侵入 让运维监控更加简单 可视化事务、调用链 统一：集中式 无状态、可集群、可分片 Event Sourcing架构 高可用 系统架构 – 基于图形 requests

heart of software �9 微服务架构与领域驱动设计？ �10 • 能有效⽀支撑演进式架构 微服务架构与领域驱动设计 �11 随着时间的推移，采⽤用领域驱动设计⽐比采⽤用 以数据中⼼心设计的软件复杂度要低得多。 《Pattern of EEA》 • 能有效降低复杂软件的维护成本 微服务架构与领域驱动设计 �12 微服务架构与领域驱动设计 • 能有效指导服务的设计与划分 ⼀一个对象通过ID被唯⼀一标识 Value Object - 值对象 • 通过值确定对象的等价性 Domain Services - 业务逻辑 Aggregate - 聚合(根) • ⼀一组实体对象和值对象的集合 • 外部对聚合的访问通过聚合根 Factories - 对象⼯工⼚厂 Repository - 存储机制 Tactical-战术建模 领域驱动设计的架构 �16 Domain Model • 领域模型的业务逻辑 Application Services • 同应⽤用相关的接⼝口适配 User Interface • ⽤用户接⼝口相关的部分 Infrastructure • 数据相关部分：WebService/DB/File • ⽀支撑相关部分: 环境相关配置 Onion架构 微服务架构与DDD 01 领域驱动设计的核⼼心 02 基于事件⻛风暴暴的DDD实践 03

Conference 2017.4 https://www.continuousdelivery.com/ • 缩短交付周期 • 降低发布⻛风险 • 质量量内嵌 组织协同 环境管理理 数据管理理 松耦合架构 反馈验证 持续集成/部署 内建质量量 微服务架构是松耦合架构机制的⼀一种实现 为什什么基于DevOps？ ● Communication ● Automation “去”中⼼心化 • ⾃自动化“⼀一切” 去“中⼼心化” - ⽤用合适的技术解决问题 数据库作为集成点 去“中⼼心化” - 业务持有数据 ⽤用户会话 Redis 会话服务 上下⽂文 购物⻋车 购物⻋车 产品数据 Mongo 产品服务 上下⽂文 上下⽂文 Redis 去“中⼼心化” - 业务持有数据 去“中⼼心化” - 智能服务⽽而⾮非智能总线 去“中⼼心化” - 智能服务⽽而⾮非智能总线 务 开 发 框 架 ⼯工 程 实 践 与 规 范 持 续 交 付 流 ⽔水 线 端 到 端 的 ⼯工 具 链 注册发现 监控 调⽤用链 路路由 授权认证 ⽇日志聚合 容错 集中配置 基础设施 业务层 - 聚合服务 - 基础服务 接⼊入层 • 流量量限制 • 调⽤用统计 • 安全认证 • 提供统⼀一接⼝口，封装内部变化 • 协议转换 API⽹网关 微服务⽣生态系统

对工具的依赖 较低 较高 运维复杂度 低 高 Huawei Confidential 4 微服务架构的第一大问题——如何拆分微服务？ •影响因素 >团队大小 >交付周期 >业务方向 >故障范围 >现有数据规模 >吞吐量 >一致性 >…… Huawei Confidential 5 拆分不好，可能带来的问题 •拆分不好，可能带来的问题 >服务数量爆炸，运维复杂 >服务数量太少，不够灵活 >一个user >接口频繁变更 >大量关联查询 >系统架构复杂度提升 Huawei Confidential 6 通过微服务拆分工具解放开发者 支撑活动 方法论 • ThoughtWorks五步十一阶 • DDD聚合 • 事件源Event Sourcing • 命令查询责任分离CQRS 现有做法 业务改造 投入大 + 应用上云 + IaaS 应用微服务改造 + PaaS 业务创新 如AI 拆表 拆界面及业务逻辑 Confidential 8 微服务拆分工具 单体应用 单体数据库 微服务数据库 A库 B库 服务A 服务B 步骤1：通过SQL的关联程 度、使用次数等，识别出 相关性最高的表划分成一 个微服务 微服务数据库 A库 B库 服务A 服务B 步骤2：通过表结构调整， 将不同的数据库进行解耦， 防止一个微服务跨库访问 （反范式、服务重构等） 微服务数据库 A库 B库 服务A 服务B 步骤3：大表水平拆分，实

• 后续的开发计划 微服务架构 • 微服务架构将⼀一个应⽤用分成多个相互独⽴立的服务。 • 好处是各个服务能够持续独⽴立的开发和部署。 • 难题是服务的数据需要采⽤用什什么样的⽅方式来进⾏行行存储？ 多个微服务使⽤用同⼀一数据库 A B C commit rollback ⼀一个典型的微服务架构应⽤用 EdgeService Customer Service Order 真正执⾏行行业务，不不做业务检查 • Cancel：取消执⾏行行业务 • 释放Try阶段预留留的业务资源 业务服务 try confirm cancel 通过领域建模来解决 • 微服务内：聚合通过数据库事务保证强⼀一致 • 内刚 • 微服务间：最终⼀一致 • 外柔 微服务事务⼀一致性建议 • 1987年年Hector & Kenneth 发表论⽂文 Sagas • Saga = T T' time • 可交换补偿 T C = T C T 对服务的要求 • 幂等 T = T T … T car rental saga T T' time C 保留留所有事务数据！ car rental saga T T' time ACID 与 Saga • ACID • 原⼦子性 （Atomicity） • ⼀一致性 （Consistency） •

• 后续的开发计划 微服务架构 • 微服务架构将⼀一个应⽤用分成多个相互独⽴立的服务。 • 好处是各个服务能够持续独⽴立的开发和部署。 • 难题是服务的数据需要采⽤用什什么样的⽅方式来进⾏行行存储？ 多个微服务使⽤用同⼀一数据库 A B C commit rollback ⼀一个典型的微服务架构应⽤用 EdgeService Customer Service Order 真正执⾏行行业务，不不做业务检查 • Cancel：取消执⾏行行业务 • 释放Try阶段预留留的业务资源 业务服务 try confirm cancel 通过领域建模来解决 • 微服务内：聚合通过数据库事务保证强⼀一致 • 内刚 • 微服务间：最终⼀一致 • 外柔 微服务事务⼀一致性建议 • 1987年年Hector & Kenneth 发表论⽂文 Sagas • Saga = T T' time • 可交换补偿 T C = T C T 对服务的要求 • 幂等 T = T T … T car rental saga T T' time C 保留留所有事务数据！ car rental saga T T' time ACID 与 Saga • ACID • 原⼦子性 （Atomicity） • ⼀一致性 （Consistency） •

服务资源浪费。 回到问题 1.运维⾃自动化 1 基础设施⾃自动化 实施了新的部署流程，成功率 ⼤大⼤大提⾼高，部署时间缩短到 30分钟。 2 ⾼高效监控 服务提供状态汇报，利⽤用 Splunk聚合⽇日志，对服务运 ⾏行状态进⾏行监控，⼤大⼤大提⾼高运 维效率。 2.DevOps⼀一家亲 2012 2015 环境⼿手⼯工维护，频频出错 缺乏有效监控 3 服务过⼤大，堵塞交付 快速增⻓长的结果导致服务过⼤大 快速有效知晓服务运⾏行状态， 服务资源浪费。 回到问题 3.服务拆分 微服务的附加成本 3.服务⾃自演进 2 1 2 3 划分合适的业务边界 进⾏行合适模块化 可测试的 4 拒绝跨上下⽂文的 数据表连接 交付畅通 环境⼿手⼯工维护，频频出错 缺乏有效监控 服务过⼤大，堵塞交付 快速增⻓长的结果导致服务过⼤大 或者服务过⼩小。⽽而过⼤大的服务 导致整个提交流⽔水线堵塞，测 试⼈人员⽆无法拿到新的版本，交

及标准化化运营 活动数据，消费者数据，媒体 数据，车联网数据等，全渠道 数据收集追踪，建立数据分析 模型，辅助业务的决策优化 大数据分析 及应用 线上数字化布局 线下数字化布局 车联网及线下店端消费者旅程与线上消费 者旅程相结合，设计多种跨渠道跨屏互动， 引导进店消费者通过扫码，配车，留资等 行为整合线上数据 利用人脸识别等多种技术及平台，通过可 配置用户聚类评级模型和数据处理算法， 实现消费者深度洞察，提高销售线索质量 及转化率，助力经销商销售 新媒体营销数字化布局 从微信营销及小程序开始布局其他新兴媒体渠道，如抖 音，汽车之家等，基于360°消费者画像的精准营销触达。 营销触达数据实时跟踪分析，形成数据闭环 消费者权益及服务数字化布局 建设“一个会员、分众运营、复合模式”的会员体 系以及差异化个性化的会员权益服务体系，打造 “不止于车”的车生活异业联盟生态圈 4 github 以智能化，可持续发展思路，打造车企C2B2C用户体验优化闭环。  可配置适应业务生长，帮助企业更快速、灵活地应对不断变化的市场需求，随时调整业务模式快速配置，以最低成本适应弹性的数据需求。 • 主机厂/经销商、线上/线下线索管 理集中化 • 线索/会员/车主服务集中化 • 数据集中化 集中化 • 用户体验能力标准化 • 外部接口标准化 • 营销能力标准化、营销形式个性化 标准化 • 线索清洗评分智能化、智能分流 •

核心交易平台 风控审核平台 计算资源 (CPU) 存储资源 (内存|磁盘) 网络资源 (ip|端口|带宽) 中间件层 微服务框架 服务元数据管理 服务发布 服务订阅 消息中间件 消息元数据管理 消息生产 消息消费 job调度系统 job元数据管理 job发布 job调度 配置中心 mq管理系统 调用链路 系统 监控告警 系统 发布系统 服务注册 中心 服务治理 机器准备周期长，紧急 情况无法应对 大促后机器闲置率高，资 源浪费巨大 混合云需求分析 机器资源按需 申请 01 接入层按url调 度流量 02 服务层set化的 路由策略 03 数据层读请求 上云，写请求 回自建idc 04 流量大户上云，顶住流量洪峰 机器器资源按需分配 接入层URL粒度流量调度 LB DNS app/browser Nginx-Proxy Nginx-Proxy 越来越大，怎么破？ 单元化&多活的范围 boss 客服系统 销售系统 风控审核 催收系统 政策管理 prod devops 监控系统 调用链路 日志系统 …… oa 人事系统 智能推荐 大数据 AI/BI …… 交易平台 电商 现金 信用卡 会员 桔子理财 风控平台 用户增长 发布系统 故障时，只影响内 部办公相关的公司 经营活动，不影响 用户下单交易 故障时，间接或部分影响用户

微服务架构模式 ServiceComb实践 案例 Agenda servicecomb.apache.org github.com/apache?q=servicecomb 面向开发者的数据中心演进 数据中心服务器虚拟化： Google，亚马逊等公司 以资源为中心： • AWS EC2，S3，Route53 • OpenStack • CloudStack • 混合云 以应用为中心： ARM CCI 虚机 CCE servicecomb.apache.org github.com/apache?q=servicecomb 围绕应用构建平台功能 • 操作的起点为应用 • 数据库，缓存服务，容器平台等围绕应用创建 应用 RDS DDM DMS DCS CCE ECS ELB 监控 软件中心 流水线 servicecomb.apache.org github github.com/apache?q=servicecomb 缺少了什么 • 流水线，平台等自动化手段的完备，使得开发人员开始思考业务功能的拆分，复用，使得网络拓扑更加复杂 • 从过去“数据中心网络拓扑几乎没变化”变为“应用发布，应对业务流量，随时随地的网络拓扑变化” • 平台功能解决了应用运行时之前的种种问题，但为了将应用的运行时统一治理，保障业务可靠运行，需要引入微服务框架 来解决分布式系统中的难题