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

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

负载均衡变更需要更新配置发布后 才能生效，节点扩缩容，屏蔽操作 需要人工参与，流量接入接出时间 长 目标 流量接入接出时长低于30秒 负载均衡配置下发无状态改造 虎牙负载均衡部署的机器数百，配置下发的可靠性保障，一致性保障要求特别严格， 如果出现配置下发不及时，或下发配置失败，极大可能出现故障，同时负载均衡服 务弹性能力的要求较高，在业务高峰如果不能快速扩容，容易出现全网故障 传统配置下发方式 负载均衡配置固话在配置文件中， 平均解析时间 之前200ms+ 现在1ms以下 缓存命中率 之前92% 现在99.8%+ 解析失败率 之前0.1% 现在0% 应用探活场景下的落地 1、web专区的nginx有健康检查的功能， 但是只是基于tcp， 根据 一段时间请求否正常， 对节点进行临时屏蔽 2、web专区和业务都会有自己的拨测， 一般只会用于告警， 缺乏 都能根据业务反馈， 动态切换节点的能力 3、支付等业务， 使用注册+DNS-f+健康检查模式。 DNS-F客户 端使用监听模式push/pull拉取更新信息 客户端定时轮询服务端获取其他服务ip信息并对 比，相比之下服务端压力较大、延迟较大 伸缩性 使用Raft选举算法性能、可用性、容错性均比较 好，新加入节点无需与所有节点互相广播同步信 息 由于使用广播同步信息，集群超过1000台机器 后对eureka集群压力很大 健康检查模式/方式 支持服务端/客户端/关闭检查模式，检查方式有

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

⽆无需多种语⾔言的微服务框架开发 • 对业务代码0侵⼊入 • 不适合改造的单体应⽤用 • 开发出开的应⽤用既是云原⽣生的⼜又具有独⽴立性 没有银弹 • 新的故障点 • ⼀一定程度的性能降低 • 侵⼊入式框架有更强的定制和扩展能⼒力 • 部署复杂性 • 简介 • 实现⼀一个Service Mesh • 使⽤用Service Mesh快速构建微服务 • ⽣生态与扩展 • Service 动态治理 • 对接华为公有云微服务引擎的Service center 与 Config center 监控 • 处理链中提供分布式调⽤用追踪 • Admin API 提供了路由查询，健 康检查，Metric等信息 • 使⽤用Collector Registry模型，并 使⽤用Channel主动上报Metric数据 • Promethues，Grafana，Zipkin 对接 Updates • ServiceStage部署 最⼩小化配置项 • HTTP_PROXY • SERVICE_NAME • PROVIDER_ADDR • CSE_REGISTRY_ADDR 部署复杂性提升，如何消弭？ • Infrastructure as Code—开发者⾃自⾏行选型 • 命令⾏行注⼊入⼯工具—Mesher开发团队定制 • 编排服务⾃自动注⼊入—最完整的产品体验 应⽤用与Mesher集成最佳实践

q=servicecomb ServiceStage overall ServiceStage 微服务解决方案 容器云平台（CCE） Serverless云平台（CCI） 微服务咨询 现状分析 适用性评估 试点实施 效果评估 经验固化 目标设定 培 训 （ 理 论 、 案 例 、 实 战 演 练 ） 应用管理平台（CAS） 生命周期管理 部署/卸载 启动/停止 升级/回滚 灰度发布 信、……） 工具（CPE） 设计和开发 构建 测试 发布上线 监控运维 部署 流 水 线 （ 持 续 集 成 、 持 续 交 付 ） 扩展插件： Eclipse等 扩展插件： 静态检查等 扩展插件： 三方部署系 统 扩展插件： 客户测试系 统 扩展插件： 客户自有仓 库 扩展插件： 客户自有监 控 开发者生态 开源社区 案例 开发者 API 产品 生态 通用微服务工具市场 apache.org github.com/apache?q=servicecomb 助力文思海辉PHP语言系统实现 全微服务化架构 基于RFID技术的楼宇设施管理 遇到的问题 性能瓶颈稳定 性差 复杂度高不易 扩展 • 单体应用，功能耦合 • 新增功能影响现有业务，升级业务中断 • 业务增长对性能要求高，增加机器不能解决问 题 • 一个业务问题影响整个系统，风险高 基于微服务引

75 �����Mercury���� ü 监控大盘快速展现系统问题 ü 秒级实时告警第一时间报告 criIicaB iHHJeH ü 分钟级y实时告警周期性检测指标规 则 ü a告警事d快速定h根源问题 ü 灵活方n的多级告警策略定义 ü 2igeEDW央告警平台无缝集成 指标统计 调用链跟踪 ü 域Q主机Q服务A2I级别指标展示 ����� ��! ��! ���� �! ���� ��! ���review ���review ���! WAP! • 横向：针对单个核心U务系统进行检查 • 纵向：针对U务线v联系统进行t链路检查 • 重点：架构、流程、缓存、消息队列、数据库、性能、高可用、隔离、限流、降级、熔断等 ��QPS&�� ����! ����! �����! ����! �����QPS

Demo 殷湘 姜宁 • 为了用户能更容易理解微服务架构原则，了解ServiceComb 的功能以及如何用其快速开发微服务； • 所以提供大家耳熟能详的例子，降低学习曲线的同时，增加 趣味性，加深用户的理解 。 Manager (网关) Doorman (认证服务) Worker (运算服务) Bulletin board (服务注册中心) Human resource (服务治理) Beekeeper提 供的计算服务，节省项目组开支 Human Resource从运维层面保证服务的可靠性，主要功能有 • 弹性伸缩：保证用户请求量超过Worker处理能力的某个阈值后，招聘更多Worker加入项目； 当请求量回落后，裁剪Worker以节省项目组开支 • 健康检查：保证Worker告病时，能有替补接手任务 • 滚动升级：保证项目需要新技能时，能替换、培训Worker ，不中断接收项目请求

规范化系统接口，让实现与文档的同 步成为必须 • 通过工具简化整个过程 API First 增速微服务开发 --- 工具支持 OpenAPI (Swagger) 定义 编辑器：在线编辑，语法提示， 错误检查 文档生成器：生成HTML与符合 华为规范文档 Mock生成器：生成Mock工具， 用于测试微服务 现有代码提取 OpenAPI工具 与RPC的IDL互 转工具 protobuf3 SpringMVC JAXRS 性能保证 Process Event-Loop Process R R W W 线 程 池 •异步 • 标准、开放、协议健壮性 • 开发框架的性能在于细节，而不仅仅 是协议。 更细致的服务路由管控 ETCD 集群 服务中 心实例 服务中 心实例 服务中 心实例 • 统一的路由策略管控 • 缓存以提升性能 SpringMVC JAX-RS RPC编程 REST通讯 XX通讯插件 RPC通讯 TCC XX事务 强事务 多语言 多编程框架 多通信协议 多事务一致性 Java 微服务 Go 微服务 XX语言 微服务 Spring微 服务 遗留 应用 微服务云服务： https://servicestage.huaweicloud