微服务环境下的系统治理与容错 王新栋 • 《架构修炼之道》作者，《决战618：探秘京东技术取胜之道》联合作者； • 对分布式、微服务系统有多年实战经验，所设计和研发的系统经历了多次百亿流量的验证； • 热爱分享，维护技术公众号 [程序架道]，对高并发、高可用系统有持续不懈的追求； 个人微信号 技术公众号 • 微服务架构 • 容错 • 总结 • 治理 微服务架构 架构 架构 独立开发部署 架构、组织、流程 微服务架构定义“三步法” 微服务拆分方法 微服务拆分-指导原则 拆服务-单体重构的节奏 服务分解的四大障碍 1、网络延迟 2、同步通信降低了可用性 3、跨服务的数据一致性 4、上帝类 微服务的忠告 n 第一，要记住微服务不是解决所有问题的万能 “银弹”。 n 第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。 n 第三， Ops的原则和实践，在组织结构上实现跨 职能的自治团队，这必不可少。 还必须记住：实现微服务架构并不是你的目标。你的目标是加速大型复杂应用程序的开发。 --Chris Richardson 容错 故障和问题 线上故障“画像“ 系统稳定性指标 可监控设计 同步调用下-无线程池隔离 同步调用下-线程池隔离实现方法 快速失败-超时 快速失败-时间窗口 快速失败-超时重试次数 区分部署和上线

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

ServiceComb项目背景介绍 • ServiceComb的特点 • ServiceComb的发展路线图 • 如何加入ServiceComb社区 微服务架构面临的问题 • 分布式系统问题 • 服务注册发现 • 容错熔断机制 • 限流降级 • 运维相关问题 • 动态配置管理 • 系统监控 • 路由管理 微服务的雄关漫道 • 服务框架 • Service Mesh ServiceComb开源微服务解决方案 （POJO/Spring MVC/JAX-RS） Golang 编程 限流 负载均衡 分布式追踪 动态配置 服务注册 服务度量 通信协议 （Rest&RPC） 边缘服务 熔断/容错 Token认证 Saga事务一致性 服务契约 平滑上云 拥抱开源生态 处理链 微服务脚手架 服务安全 治理UI 自动部署 监控运维 Public Cloud …… SpringCloud SpringBoot Chassis • 高性能的微服务框架，提供服务注册发现以及动态配置管理，以及限流降级，容错熔 断等服务治理功能 • Service Center • 基于Etcd高性能，高可用服务注册中心 • Saga • 微服务事务最终一致性问题解决方案 • 提供一个集中式的事务协调器，协调微服务之间的事务调用，保证事务最终一致性 https://github.com/apache?q=incubator-servicecomb

ServiceComb项⽬目背景介绍 • ServiceComb的特点 • ServiceComb的发展路路线图 • 如何加⼊入ServiceComb社区 微服务架构⾯面临的问题 • 分布式系统问题 • 服务注册发现 • 容错熔断机制 • 限流降级 • 运维相关问题 • 动态配置管理理 • 系统监控 • 路路由管理理 微服务框架与解决⽅方案 • 服务框架 • Service Mesh ServiceComb开源微服务解决⽅方案 SpringMVC/JAX- RS） Golang 编程 限流 负载均衡 分布式追踪 动态配置 服务注册 服务度量量 通信协议 （Rest&RPC） 边缘服务 熔断/容错 Token认证 Saga事务⼀一致性 服务契约 平滑上云 拥抱开源⽣生态 处理理链 微服务脚⼿手架 服务安全 治理理UI ⾃自动部署 监控运维 Public Cloud …… SpringCloud ⾼高性能的微服务框架，提供服务注册发现以及动态配置管理理，以及限流降级，容错熔 断等服务治理理功能 • Service Center • 基于Etcd⾼高性能，⾼高可⽤用服务注册中⼼心 • Saga • 微服务事务最终⼀一致性问题解决⽅方案 • 提供⼀一个集中式的事务协调器器，协调微服务之间的事务调⽤用，保证事务最终⼀一致性 https://github.com/apache?q=incubator-servicecomb

提供标准接口（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出现网络分区故障时依

Chassis 高性能的微服务框架，提供服务注册发现以及动态配置管理，以及限流降级， 容错熔断等服务治理功能 • Service Center 基于Etcd高性能，高可用服务注册中心 • Pack (Saga) 微服务事务最终一致性问题解决方案，提供一个集中式的事务协调器，协调微 服务之间的事务调用，保证事务最终一致性 https://github.com/apache?q=servicecomb （POJO/Sprin gMVC/JAX- RS） Golang 编程 限流 负载均衡 分布式追踪 动态配置 服务注册 服务度量 通信协议 （Rest&RP C） 边缘服务 熔断/容错 Token认证 Saga事务一致性 服务契约 平滑上云 拥抱开源生态 处理链 微服务脚手架 服务安全 治理UI 自动部署 监控运维 Public Cloud …… SpringClou d SpringBoot

应⽤用部署⾃自动化（包/映像/容器器） 容器器部署 映像部署 包部署 ⾃自动化“⼀一切” - 基础设施与部署流程 议题 • 微服务架构的核⼼心 • 微服务架构设计原则 • 微服务架构⽣生态系统 • 分布式系统复杂性 • 服务的治理理与维护 • 测试策略略与契约测试 • 持续交付流⽔水线 • 基础设施(私有云/公有云) • 持续集成/持续部署流⽔水线 • 团队的敏敏捷/⼯工程化实践 • 端到端的⼯工具链 CaaS/PaaS IaaS 微 服 务 开 发 框 架 ⼯工 程 实 践 与 规 范 持 续 交 付 流 ⽔水 线 端 到 端 的 ⼯工 具 链 注册发现 监控 调⽤用链 路路由 授权认证 ⽇日志聚合 容错 集中配置 基础设施 业务层 - 聚合服务 - 基础服务 接⼊入层 • 流量量限制 • 调⽤用统计 • 安全认证 • 提供统⼀一接⼝口，封装内部变化 • 协议转换 API⽹网关 CaaS/PaaS IaaS 微 服 务 开 发 框 架 ⼯工 程 实 践 与 规 范 持 续 交 付 流 ⽔水 线 端 到 端 的 ⼯工 具 链 注册发现 监控 调⽤用链 路路由 授权认证 ⽇日志聚合 容错 集中配置 基础设施 接⼊入层 业务层 - 聚合服务 - 基础服务 注册发现 为什什么要注册发现 • 服务重启/升级后的IP地址变化 • ⽔水平伸缩后服务的实例例数量量变化

更容易实验和采纳新的技术。 强大： • 使大型的复杂应用程序可以持续的交付和持续的部署。 • 更容易测试 • 更容易对已有大型系统进行修改和扩展 • 容易进行的性能优化 • 更高的可用性 • 更容易的进行性能伸缩性 适合同学们学习 Demo也可以作为生产系统的一部分 [社区网站] http://servicecomb.apache.org [Github ] https://github.com/apache SDK b) https://github.com/apache/servicecomb-mesher 多语言解决方案 c) 重试 d) 负载均衡 e) 限流 f) 降级（隔离、熔断、容错） • 网关 a) 路由 b) 黑白名单 c) 和认证鉴权集成 [社区网站] http://servicecomb.apache.org [Github ] https://github 举例：客户维护和订单是2个微服务，订单系统对性能有较高要求，所以可以考虑把购房资格信息从客户维护微服务同步到订单系统，改同步动作 对性能没有要求，对事务性有要求。 常见的服务间通信模式：同（异)步通信，API组合，基于MQ的异步通信 事务性： saga, 事务性消息发布（一次仅一次），分布式事务等 很易用的服务间saga事务方案Servicecomb ServicePack: https://github

更容易实验和采纳新的技术。 强大： • 使大型的复杂应用程序可以持续的交付和持续的部署。 • 更容易测试 • 更容易对已有大型系统进行修改和扩展 • 容易进行的性能优化 • 更高的可用性 • 更容易的进行性能伸缩性 适合同学们学习 Demo也可以作为生产系统的一部分 [社区网站] http://servicecomb.apache.org [Github ] https://github.com/apache SDK b) https://github.com/apache/servicecomb-mesher 多语言解决方案 c) 重试 d) 负载均衡 e) 限流 f) 降级（隔离、熔断、容错） g) 分布式跟踪 • 网关 a) 路由 b) 黑白名单 c) 和认证鉴权集成 [社区网站] http://servicecomb.apache.org [Github ] https://github 举例：商品维护和下订单是2个微服务，下订单系统对性能有较高要求，所以可以考虑把商品的价格从商品维护微服务同步到订单系统，该同步动作 对性能没有要求，对事务性有要求。 常见的服务间通信模式：同（异)步通信，API组合，基于MQ的异步通信 事务性： saga, 事务性消息发布（一次仅一次），分布式事务等 很易用的服务间saga事务方案Servicecomb-Pack: https://github.com

负载均衡变更需要更新配置发布后 才能生效，节点扩缩容，屏蔽操作 需要人工参与，流量接入接出时间 长 目标 流量接入接出时长低于30秒 负载均衡配置下发无状态改造 虎牙负载均衡部署的机器数百，配置下发的可靠性保障，一致性保障要求特别严格， 如果出现配置下发不及时，或下发配置失败，极大可能出现故障，同时负载均衡服 务弹性能力的要求较高，在业务高峰如果不能快速扩容，容易出现全网故障 传统配置下发方式 负载均衡配置固话在配置文件中， 使用注册+DNS-f+健康检查模式。 DNS-F客户 端使用监听模式push/pull拉取更新信息 客户端定时轮询服务端获取其他服务ip信息并对 比，相比之下服务端压力较大、延迟较大 伸缩性 使用Raft选举算法性能、可用性、容错性均比较 好，新加入节点无需与所有节点互相广播同步信 息 由于使用广播同步信息，集群超过1000台机器 后对eureka集群压力很大 健康检查模式/方式 支持服务端/客户端/关闭检查模式，检查方式有 OpenAPI 分布式高可用最小集群数量 Config2+Admin3+Portal*2+Mysql =8 Nacos*3+MySql=4 配置格式校验 支持 支持 通信协议 HTTP HTTP 数据一致性 数据库模拟消息队列，Apollo定时 读消息 HTTP异步通知 单机读（tps） 9000 15000 单机写（tps） 1100 1800 技术选型 • Dubbo生态产品， Nacos源于阿里内部服务的开源实现；