和平统一 微服务场景下的数据一致性解决方案 殷湘 华为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

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

对工具的依赖 较低 较高 运维复杂度 低 高 Huawei Confidential 4 微服务架构的第一大问题——如何拆分微服务？ •影响因素 >团队大小 >交付周期 >业务方向 >故障范围 >现有数据规模 >吞吐量 >一致性 >…… Huawei Confidential 5 拆分不好，可能带来的问题 •拆分不好，可能带来的问题 >服务数量爆炸，运维复杂 >服务数量太少，不够灵活 >一个user Confidential 7 微服务拆分工具-表自动分库 SQL 语句 SQL 语句 SQL 语句 … 语法分析 语法分析 语法分析 表关联分析 图切割+启 发式规则 Step1：提取系统所有SQL Step2：逐条根据SQL创建语法树 Step3：在每棵语法树上分析表的关联关系并汇集 成表关联关系加权图 Step6：采用图切割算法并配合启发式规则将表分 割到不同库中 原则：低耦合，高内聚 Confidential 8 微服务拆分工具 单体应用 单体数据库 微服务数据库 A库 B库 服务A 服务B 步骤1：通过SQL的关联程 度、使用次数等，识别出 相关性最高的表划分成一 个微服务 微服务数据库 A库 B库 服务A 服务B 步骤2：通过表结构调整， 将不同的数据库进行解耦， 防止一个微服务跨库访问 （反范式、服务重构等） 微服务数据库 A库 B库 服务A 服务B 步骤3：大表水平拆分，实

微服务架构模式 ServiceComb实践 案例 Agenda servicecomb.apache.org github.com/apache?q=servicecomb 面向开发者的数据中心演进 数据中心服务器虚拟化： Google，亚马逊等公司 以资源为中心： • AWS EC2，S3，Route53 • OpenStack • CloudStack • 混合云 以应用为中心： Serverless云平台（CCI） 微服务咨询 现状分析 适用性评估 试点实施 效果评估 经验固化 目标设定 培 训 （ 理 论 、 案 例 、 实 战 演 练 ） 应用管理平台（CAS） 生命周期管理 部署/卸载 启动/停止 升级/回滚 灰度发布 弹性伸缩 微服务运维 应用告警 日志分析 全链路拓扑 SQL分析 调用链 立体监控 方法追踪 事务洞察 微服务治理 微服务治理 负载均衡 限流/降级 熔断/容错 错误注入 黑白名单 微服务管理 注册中心 配置中心 治理中心 全局事务 契约管理 监控大屏 智能分析 环境管理 开发环境 测试环境 预验证环境 灰度环境 生产环境 商业生态(aPaaS/SaaS) 行业 （政府、教育、医疗、零售、……） 伙伴 （软通、中软、幸宜、博思、医 信、……） 工具（CPE） 设计和开发

性能一流 Ø 足n支撑数百万订单量级b务 Ø 易用性q秀 服务治理演进各c阶段 服务治理实践(%)：基础能力达标 - 青铜段t 监控报警 数据分析 • 性能指标 • 来源去向 • f机分析 • 数据报表 • 调用链路 • 节点监控 • 性能监控 • b务监控 • 异常监控 • 服务注册 • 服务概要 • 提y者 提y者 • 消费者 注册中心 • 配置管理 • 服务分组 • 节点管理 • 服务鉴权 服务运营 :1?:-PMPRBJ 一站式服务治理平台 数据分析：多维度数据统计 服务治理实践(&) + 提升标准化-白银段t ����� �! • �������������������! • ��������������(�Node.js)! • ��������������� • ��Oncall��(����+������)! 服务治理实践(3) +易用性 V 细粒度埋点监控 Client� Server� :1?:服务框架最大性能 • (核(4，%K数据包3DhM测试 • 原则：框架自身不造成应用瓶颈 服务治理实践(() +性能提升 - 铂金段t 系统化性能q化实践 V 一站式性能q化平台SDBJNEJ 流程化、自动化 零门槛、u成本

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

使能多微服 务技术栈开 发的微服务 应用之间协 同工作和共 同治理 使能满足第三 方认证被广泛 采纳的趋势下 认证鉴权的性 能和安全的要 求 帮助企业用 户达成业务 模型和数据 集成标准统 一 通过易于理 解的数据和 入口，管理 复杂的分布 式系统配置 多语言运行环境 服务中心异构通信 微服务鉴权 分布式系统配置中心 微服务契约工具 19 年Apache ServiceComb新品发布 电子印章 报表 电子凭证 工作流 标准存储 数据交换 …… 财政微应用 预算 编制 指标 管理 …… 财务微应用 会计 核算 项目 库 …… 统一基础 数据规范 统一财政 业务数据 标准存储 统一应用 支撑平台 总账结构 统一纵向 层级交换 机制 统一信息 安全体系 软件开发服务 ServiceStage 大数据服务 系统集成服务 IaaS（计算、存储、网络、安全） IaaS（计算、存储、网络、安全） 中间件服务 标准与规范 应用全微服务化，接口标准由财政厅统一管控， ISV只需聚焦微服务交付，降低依赖性 统一业务模型和数据集成标准，系统无缝对接， 财政数据统一呈现，业务全盘管控 基于先进研发理念，标准化研发环境和工具， 开发效率高，财政需求上线快 解除ISV绑定 降低业务监管难度 新需求上线快 案例：助力S省财政厅数字化转型 综控端 无人机管理系统 （单体架构）

spectator-reg-servo，设置较小的order，保 证比下面2类MetricsInitializer先执行 – Meters Initializer: 实现TPS、时延、线程 池、jvm资源等等数据的统计 – Publisher: 输出统计结果，内置了日志输出， 以及通过RESTful接口输出 • Metrics-prometheus提供与prometheus对接的能力 spectator RESTful/prometheus输出内容为原始数据 日志输出内容是根据原始数据分析计算后的结果 • eventLoopContext-created 如果持续增加，说明有计划外的线程切换，需要定位 • threadPool 以线程池为单位进行统计，输出最小线程数、最大线程数、 当前线程数、当前排队任务数，以及平均每秒提交任务数、完成 任务数等等数据 • consumer 以transp

快速有效知晓服务运⾏行状态， 服务资源浪费。 回到问题 3.服务拆分 微服务的附加成本 3.服务⾃自演进 2 1 2 3 划分合适的业务边界 进⾏行合适模块化 可测试的 4 拒绝跨上下⽂文的 数据表连接 交付畅通 环境⼿手⼯工维护，频频出错 缺乏有效监控 服务过⼤大，堵塞交付 快速增⻓长的结果导致服务过⼤大 或者服务过⼩小。⽽而过⼤大的服务 导致整个提交流⽔水线堵塞，测 试⼈人员⽆无法拿到新的版本，交 Guild DevOps Guild 交付特性团队 交付特性团队 “没有衡量就没有改善！ 你衡量什么就得到什么！” —Peter F．Drucker 产品规划 需求澄清 分析设计 开发实现 测试交付 上线发布 运营 持续交付 持续改进 建⽴立闭环反馈系统 � � � � � � � � � � � � DevOps 这样就⾜足够了吗？ 快速响应 ⼀一个具有快速复原能⼒力，

5 github.com/apache?q=servicecomb servicecomb.apache.org 方案\指标 2PC 传统事务 可靠事件 TCC 柔性事务 SAGA 补偿事务 数据一致性 强一致 最终一致 最终一致 最终一致 总体性能 低 高 取决于实现 取决于实现 业务侵入性 较低侵入 高侵入 高侵入 高侵入 适用广泛性 一般 一般 高 低 产品成熟度 高 高 一般 （参与者） Service B DTM-Server 配置中心 运维中心 Database A DTM-Client （参与者） Database A 业务数据库A 业务数据库B 事务数据库 用户侧 系统侧 管理面 数据面 TCC实现 TCC实现 8 github.com/apache?q=servicecomb servicecomb.apache.org 一个完整的步骤 CPU≥4核；  RAM≥8GB；  系统盘：40GB；  数据盘：500GB； GaussDB 2  CPU≥8核；  RAM≥16GB；  系统盘：40GB；  数据盘(SSD)：1TB； 5000TPS Server 3  CPU≥8核；  RAM≥16GB；  系统盘：40GB；  数据盘：500GB； GaussDB 2  CPU≥8核； 