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

Conference 2017.4 https://www.continuousdelivery.com/ • 缩短交付周期 • 降低发布⻛风险 • 质量量内嵌 组织协同 环境管理理 数据管理理 松耦合架构 反馈验证 持续集成/部署 内建质量量 微服务架构是松耦合架构机制的⼀一种实现 为什什么基于DevOps？ ● Communication ● Automation “去”中⼼心化 • ⾃自动化“⼀一切” 去“中⼼心化” - ⽤用合适的技术解决问题 数据库作为集成点 去“中⼼心化” - 业务持有数据 ⽤用户会话 Redis 会话服务 上下⽂文 购物⻋车 购物⻋车 产品数据 Mongo 产品服务 上下⽂文 上下⽂文 Redis 去“中⼼心化” - 业务持有数据 去“中⼼心化” - 智能服务⽽而⾮非智能总线 去“中⼼心化” - 智能服务⽽而⾮非智能总线 ⾃自动化“⼀一切”- 交付流⽔水线 ⾃自动化“⼀一切”- 测试策略略与应⽤用 应⽤用部署⾃自动化（包/映像/容器器） 容器器部署 映像部署 包部署 ⾃自动化“⼀一切” - 基础设施与部署流程 议题 • 微服务架构的核⼼心 • 微服务架构设计原则 • 微服务架构⽣生态系统 • 分布式系统复杂性 • 服务的治理理与维护 • 测试策略略与契约测试 • 持续交付流⽔水线 • 基础设施(私有云/公有云)

heart of software �9 微服务架构与领域驱动设计？ �10 • 能有效⽀支撑演进式架构 微服务架构与领域驱动设计 �11 随着时间的推移，采⽤用领域驱动设计⽐比采⽤用 以数据中⼼心设计的软件复杂度要低得多。 《Pattern of EEA》 • 能有效降低复杂软件的维护成本 微服务架构与领域驱动设计 �12 微服务架构与领域驱动设计 • 能有效指导服务的设计与划分 • 领域模型的业务逻辑 Application Services • 同应⽤用相关的接⼝口适配 User Interface • ⽤用户接⼝口相关的部分 Infrastructure • 数据相关部分：WebService/DB/File • ⽀支撑相关部分: 环境相关配置 Onion架构 微服务架构与DDD 01 领域驱动设计的核⼼心 02 基于事件⻛风暴暴的DDD实践 03 参与⼈人员：业务⼈人员，领域专家，技术⼈人员，架构师，测试⼈人员等关键⻆角⾊色 开放空间：⾜足够的空间将业务事件流可视化，让⼈人们可以互相讨论 彩⾊色即时贴：使⽤用不不同颜⾊色标识 Alberto Brandolini 如何使⽤用Event Storming 业务流梳理理 寻找事件 寻找命令 寻找聚合 划分⼦子域&界限上下⽂文 理理解业务 发⽣生了了什什么？ 通过什什么产⽣生？ 谁引起的？

微服务架构模式 ServiceComb实践 案例 Agenda servicecomb.apache.org github.com/apache?q=servicecomb 面向开发者的数据中心演进 数据中心服务器虚拟化： Google，亚马逊等公司 以资源为中心： • AWS EC2，S3，Route53 • OpenStack • CloudStack • 混合云 以应用为中心： 商业生态(aPaaS/SaaS) 行业 （政府、教育、医疗、零售、……） 伙伴 （软通、中软、幸宜、博思、医 信、……） 工具（CPE） 设计和开发 构建 测试 发布上线 监控运维 部署 流 水 线 （ 持 续 集 成 、 持 续 交 付 ） 扩展插件： Eclipse等 扩展插件： 静态检查等 扩展插件： 三方部署系 统 扩展插件： 客户测试系 统 扩展插件： 客户自有仓 ARM CCI 虚机 CCE servicecomb.apache.org github.com/apache?q=servicecomb 围绕应用构建平台功能 • 操作的起点为应用 • 数据库，缓存服务，容器平台等围绕应用创建 应用 RDS DDM DMS DCS CCE ECS ELB 监控 软件中心 流水线 servicecomb.apache.org github

客户端负载均 衡 外置LB： Nginx、 Ribbon SLB 注册中心 配置服务：  Zookeeper  etcd 缓存方案：  Redis 数据库方案：  DB + MQ 服务治理 服务治理： 超时、流控、 降级等 运维KPI：  ELK  Zabbix 调用链：  zipkin 选择ServiceComb的原因： 实践- API First Website: 业务按需配置ServiceComb的类库依赖，基于standalone轻量级部署 开发态：按照业务实际需要配置ServiceComb的 maven 依赖，只加载需要的类库： 如果需要使用ServiceComb的流控再配置 如果需要使用私有RPC协议时才需要配置依赖 JVM Vert.X ServiceComb SDK Service API 业务微服务实例 Standalone模式，后台应用 不依赖Web容器 需求的研发和交付周期缩短，业务更敏捷应对变化 可独立交付和升级的服务越来越多，业务之间逐步解耦，可独立演进 服务之间的接口契约可视化、可度量和管控，架构看护和优化更有章可循 服务无状态，微服务数据自治，天生的弹性伸缩架构，高效支撑业务快速发展 提供微服务维度的监控大盘和细粒度的治理措施，运维更得心应手 个人级、微服务团队级、项目级三级微服务流水线体系，基础设施自动化 … Thank You

Meetup #6 广州站 微服务改造事项 DNS-F在数据 库场景的落地 名字服务在负 载均衡场景的 落地 DNS-F在微服 务场景的落地 应用层探活 数据库故障 恢复时间长 服务故障牵 引慢，流量 接入生效时 间长 DNS生效慢 内部服务无 就近接入能 力 服务性能下 降流量不摘 除 实 例 切 换 能 力 秒 级 流 量 牵 引 能 力 D N S 就 近 接 入 能 能 力 异 常 摘 除 能 力 dmx dns-f app nacos M S write read DNS-F在数据库场景的落地 背景 在数据库服务切换时效率低，依赖 业务方修改配置，时效不确定，通 常需要10分钟以上； 目标 数据库切换秒级生效； 技术特点-DNS-F M S S S M1.mysql S1.mysql S2.mysql S3.mysql if M1 OpenAPI 分布式高可用最小集群数量 Config2+Admin3+Portal*2+Mysql =8 Nacos*3+MySql=4 配置格式校验 支持 支持 通信协议 HTTP HTTP 数据一致性 数据库模拟消息队列，Apollo定时 读消息 HTTP异步通知 单机读（tps） 9000 15000 单机写（tps） 1100 1800 技术选型 • Dubbo生态产品， Nacos源于阿里内部服务的开源实现；

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

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

API⺴关Edge Service p实践案例 为什么微服务框架需要Reactive？ • 微服务架构调用次数更多 • 更高的性能，规模效应 • 更好的用户体验 业界趋势 n Java 9中把反应式流规范以 java.util.concurrent.Flow 类的方式添加到了标准库中 n Spring 5对反应式编程模型提供了内置支持，并增加了新的 WebFlux 模块来支持反应 式 Web 应用的开发 的通信模型演进—Reactor 黄金法则：不要阻塞Event Loop 什么才叫阻塞？ n Thead.sleep() n 等待一个锁 n 等待一个互斥信号或监视器（例如同步的代码块） n 执行一个长时间数据库操作并等待其结果 n 执行一个复杂的计算，占用了可感知的时长 n 在循环语句中长时间逗留 10000TPS=0.1ms处理一个请求 如果利⽤多核？ ServiceComb 采⽤Vert.x的背景 橙色箭头走完后，对本线程的占用即完 成了，不会阻塞等待应答，该线程可以 处理其他任务 p 当收到远端应答后，由网络数据驱动开 始走红色箭头的应答流程 p 只要有任务，线程就不会停止，会一直 执行任务，可以充分利用cpu资源，也 不会产生多余的线程切换，去无谓地消 耗cpu。 压测数据 系统: Ubuntu 18.04.1 CPU: 4vCPU Intel(R) Xeon(R) CPU E5-

SSL传输、API鉴权和认证等  对于一些敏感信息，例如用户账号、金额等，在记录日志等落盘 和采集时需要做脱敏处理、资源占用要合理  敏感运维操作，需要记录安全日志，例如服务上线和下线、服务 的流控阈值修改等 微服务框架技术选型-服务治理能力  服务框架丌能只单单解决分布式RPC调用、服务注册&发现和路 由问题，更重要的是业务微服务上线乊后，需要提供实用和丰富 的在线治理能力 CSE在消费者云业务的实践-API First API 接口 契约 消费者1 消费者2 消费者...N 提 供 者 1、接口定义 2、测试用例 3、码流 4、错误码...  最佳实践  无论Rest API，戒者RPC Highway API，统一使用Swagger YAML定义API  服务端和客户端都基于API定义，通过CSE提供的工具生成丌同语言的类库， 绑定后端的服务调度线程，最大限度减少锁竞 争。采用连接池机制，重用已有的连接 CSE在消费者云业务的实践-分布式事务 1、服务化乊前本地事务： 2、服务化乊后引入分布式事务： 解决方案：CSE提供数据最终一致性方案-Saga CSE在消费者云业务的实践-服务治理能力 为什么需要服务治理：  随着业务的发展，服务越来越多，如何协调线上运行的各个 服务，保障服务的SLA，对服务架构和运维人员是一个很大