1、声明式自愈系统声明式自愈系统高可用分布式系统的设计之道高可用分布式系统的设计之道高级技术专家目录目录 分布式系统面临的高可用问题 设计和验证高可用分布式系统的工具与方法 设计和验证高可用分布式系统的案例分享 高可用系统的最佳实践总结无状态分布式系统的高可用问题无状态分布式系统的高可用问题处理消息的服务节点可以随机选择不必处理数据复制和同步的问题系统容量和高可用能力可以同步提升服务节点可以随意迁移，不必固定 IP 和存储有状态分布式系统的高可用问题有状态分布式系统的高可用问题一致性一致性可用性可用性分区容错性分区容错性PaxosPaxosRaftRaft2PC2PCGossipGossip 处理

2、请求需要特定节点处理请求需要特定节点 必须要考虑数据备份和同步必须要考虑数据备份和同步的问题的问题 容量扩展和高可用需要不同容量扩展和高可用需要不同解决方案解决方案 服务节点不能随便迁移服务节点不能随便迁移CAP Is Not Simply 2 out of 3 没有分区时，可用性和一致没有分区时，可用性和一致性要兼得性要兼得 经常要考虑的是可用性和一经常要考虑的是可用性和一致性各有一部分致性各有一部分 根据不同设计应用需求有不根据不同设计应用需求有不同的组合同的组合 重要的是系统如何恢复到重要的是系统如何恢复到“最佳状态最佳状态”分区容错性可可用用性性一一致致性性系系统统服服务务等等级级分区

3、容错性可可用用性性一一致致性性系系统统自自愈愈程程度度Look Distributed System in another WaySafetySomething bad will never happene.g.received message is lostLivenessSomething good will eventually happene.g.is able to receive message目录目录 分布式系统面临的高可用问题 设计和验证高可用分布式系统的工具与方法 设计和验证高可用分布式系统的案例分享 高可用系统的最佳实践总结依据声明式自愈的理念设计系统依据声明式自愈的理念设

4、计系统有一个统一的状态持久化接口，所有有状态模块通过统一的接口对应统一的对象模型配置模块对象只需要包括Desired State每个领域的控制器模块的逻辑保证自己领域独立自愈的能力改变状态的操作必须是幂等的声明式操作，没有新声明时各模块按照之前的声明继续工作控制器模块对象包括Desired State 和 Realized State声明式自愈系统的控制器协调循环声明式自愈系统的控制器协调循环ObserveObserveAnalyzeAnalyzeActionActionu 观察当前的观察当前的Realized StateRealized Stateu当前有当前有2 2个正常运行的个正常运行的

5、PodPodu比较比较Desired StateDesired State跟跟Realized StateRealized State的差距的差距u期望期望3 3个个PodPodu实际状态实际状态2 2个个PodPodu控制器执行动作协调到控制器执行动作协调到Desired StateDesired Stateu创建创建1 1个新的个新的PodPod Controller观察特定领域的观察特定领域的系统状态系统状态 协调协调Desired State跟跟Realized State之间的差之间的差距，维持最终一致性距，维持最终一致性 定期处理集群中的事件定期处理集群中的事件 系统必须是幂等的系

6、统必须是幂等的控制器的设计理念控制器的设计理念控制逻辑应该只依赖于当前状态假设任何错误的可能，并做容错处理尽量避免复杂状态机，逻辑不要依赖无法监控的内部状态每个模块都可以在必要时优雅地降级服务每个模块都可以在出错后自动恢复假设任何命令都可能被任何调用对象拒绝，甚至返回错误结果声明式自愈系统声明式自愈系统的现有框架的现有框架Kubernetes声明式自愈系统设计理念的回顾声明式自愈系统设计理念的回顾统一接口和对象模型自愈能力幂等操作和状态机DS 和 RSDesired State可重用部分可重用部分已完全实现已完全实现要在领域内要在领域内自己实现自己实现如何设计好状态机和自愈协议？如何设计好状态

7、机和自愈协议？Writing Correct Software Is Hard!Math and Thinking Can Help Us!TLA+是用来给（软件或硬件）系统建模的语言TLA+强调排除特定编程语言（软件或硬件）的影响验证系统设计TLA+由 Paxos 协议的发明人 Leslie Lamport 发明使用使用 TLA+定义和验证系统设计定义和验证系统设计Why TLA+For quite a while,Ive been disturbed by the emphasis on language in computer science.One result of that emp

8、hasis is programmers who are C+experts but cant write programs that do what theyre supposed to.I believe that the best way to get better programs is to teach programmers how to think better.Thinking is not the ability to manipulate language;its the ability to manipulate concepts.Leslie LamportLeslie

9、 LamportLanguage vs.ConceptWhorfian syndrome沃尔夫综合沃尔夫综合征征Computer scientists collectively suffer from what I call the Whorfian syndrome1the confusion of language with reality.Since these devices are described in different languages,they must all be different.In fact,they are all naturally described a

10、s state machines.Leslie LamportLeslie LamportLanguage vs.RealityFunctions vs.State MachinesYet computer scientists are so focused on the languages used to describe computation that they are largely unaware that those languages are all describing state machines.Leslie LamportLeslie LamportTLA+试图用状态机而

11、不是计算过程描述系统试图用状态机而不是计算过程描述系统更加关注系统的非正常输入更加关注系统的稳定性可用性等特性而不是系统输出分布式系统环境下没有单一的输入输出TLA+是一种适合定义状态机的语言是一种适合定义状态机的语言定义一个状态机需要：1.定义所有可能的初始状态2.定义在特定状态下可能有哪些状态转换一个程序可以用状态机描述一个程序可以用状态机描述定义一个状态机需要：1.定义变量2.定义所有可能的初始状态3.定义在特定状态下可能有哪些状态转换计算 100/x 的程序：x=100/x;TLA+的应用场景的应用场景验证系统设计的正确性验证系统设计的正确性TLA+工具会遍历所有可能的状态验证系统的正

12、确性分布式系统中有哪些异常情况需要模拟？分布式系统中有哪些异常情况需要模拟？运行时可能出现的异常运行时可能出现的异常ApplicationsApplicationsRuntimesRuntimesMiddlewareMiddlewareOSOSVirtualizationVirtualizationStorageStorageNetworkingNetworkingDataData启动异常启动异常进程被杀进程被杀服务器假死服务器假死断电断电启动异常启动异常超卖超卖进程死锁进程死锁负载均衡失效负载均衡失效业务线程池满业务线程池满监控错误监控错误流控不合理流控不合理心跳异常心跳异常缓存热点缓存热点

13、缓存限流缓存限流数据库热点数据库热点数据库宕机数据库宕机数据库延迟数据库延迟CPU CPU 抢占抢占内存抢占内存抢占内存错乱内存错乱上下文切换上下文切换磁盘满磁盘满磁盘坏磁盘坏网络抖动网络抖动网卡慢网卡慢断网断网DNS DNS 故障故障系统单点系统单点异步阻塞异步阻塞依赖超时依赖超时内存溢出内存溢出不可读写不可读写目录目录 分布式系统面临的高可用问题 设计和验证高可用分布式系统的工具与方法 设计和验证高可用分布式系统的案例分享 高可用系统的最佳实践总结一个分布式消息系统的概念模型一个分布式消息系统的概念模型ProducerProducer X X Topic AQueue A0Queue A1

14、Server Group 0Server Group 0Topic BQueue A2Queue A0Server Group 1Server Group 1ProducerProducer Y YConsumerConsumer A1 A1消费组消费组A AConsumerConsumer A2 A2ConsumerConsumer B1 B1消费组消费组B BConsumerConsumer B2 B2Topic A分布式消息系统的部署模型分布式消息系统的部署模型ProducerProducer Discovery Service ClusterDiscovery Service Clus

15、terConsumerConsumerConsumerConsumerConsumerConsumerProducerProducer ProducerProducer Server Group 0Server Group 0Server Group 1Server Group 1分布式消息系统在分布式消息系统在 Kubernetes 下的部署运维下的部署运维ServerServerMasterMasterPod-0-0Pod-0-0ServerServerSlaveSlavePod-0-1Pod-0-1ServerServerSlaveSlavePod-0-2Pod-0-2Server Gr

16、oup Server Group 0 0StatefulSet-0StatefulSet-0ServerServerMasterMasterPod-1-0Pod-1-0ServerServerSlaveSlavePod-0-1Pod-0-1ServerServerSlaveSlavePod-0-2Pod-0-2Server Group Server Group 1 1StatefulSet-1StatefulSet-1ServerServerMasterMasterPod-N-0Pod-N-0ServerServerSlaveSlavePod-N-1Pod-N-1ServerServerSla

17、veSlavePod-N-2Pod-N-2Server Group Server Group N NStatefulSet-2StatefulSet-2Storage Service ClusterStorage Service ClusterDiscoveryDiscoveryServiceServicePod-0Pod-0DiscoveryDiscoveryServiceServicePod-1Pod-1DiscoveryDiscoveryServiceServicePod-2Pod-2Discovery Service ClusterDiscovery Service Cluster使用

18、使用 TLA+验证系统自愈特性验证系统自愈特性目标状态目标状态DesiredDesired State State使用使用 TLA+验证系统自愈特性验证系统自愈特性实际状态实际状态Realized Realized StateState设计实现声明式自愈系统的工具与方法设计实现声明式自愈系统的工具与方法架构选型选择基础状态持久化框架参考系统：Kubernetes高可用系统设计设计并验证高可用分布式系统参考工具：TLA+Toolkit系统实现实现高可用系统的控制模块参考模式：Kubernetes Operator系统测试测试分布式高可用系统的自愈能力参考工具：Jepsen目录目录 分布式系统面临

19、的高可用问题 设计和验证高可用分布式系统的工具与方法 设计和验证高可用分布式系统的案例分享 高可用系统的最佳实践总结最佳实践分享最佳实践分享有关 TLA+的使用 分布式系统设计 80%的重点工作在与设计安全性原则 目前 TLA+工具已经有云服务上线，但只支持检查安全性 单机版的 TLA+工具支持系统活性的检查，但是性能比较差 活性检查的性能瓶颈在于系统状态图中强连通图算法的实现 TLA+中实现的卡壳（Stutter）等价能力，即对所有状态保持不变也是合法状态最佳实践分享最佳实践分享有关分布式系统统一 API 的设计 所有API应该是声明式的 高层API以操作意图为基础设计 低层 API 根据高

20、层 API 的控制需要设计 API 对象是彼此互补而且可组合的 尽量避免简单封装,不要有隐藏的内部 API API 操作复杂度与对象数量成正比 API 对象状态不依赖于连接状态 针对全局状态设计自愈容错机制最佳实践分享最佳实践分享有关系统设计和运营 分开设计理想状态和实际状态 Desired State Realized State 利用队列解耦系统 尽量不要依赖 DNS 做高可用 监控负载不均的情况 避免Self DoS最佳实践分享最佳实践分享有关微服务架构的典型模式 限流 Throttling 超时 Timeouts 熔断器 Circuit Breaker 壁舱 Bulkheads 快速失

21、败 Fail Fast 背压模式 Backpressure最佳实践分享最佳实践分享有关遵循快速回复的原则 快速报错 Fail Fast 复杂操作拆分成简单原子操作，在界面和 CLI 做组合 注意设置超时 尽量避免用全局事物 注意慢操作可能造成的客户端冲突问题最佳实践分享最佳实践分享有关缓存的使用 缓存的内容：服务发现应答，DNS 结果，元数据，数据，之前的请求 逻辑正确性不能依赖缓存，写操作服务端必须有校验而且幂等，没有缓存情况下系统仍可服务 错误回复缓存，过期时间不能太长，而且有清晰的修复建议 数据库更新与缓存失效的策略最佳实践分享最佳实践分享有关配置文件 集群使用统一的配置来源 定义正常的默认配置，满足读取不到配置的正常运行 支持可扩展的配置命令格式 尽量支持更改配置不需要重启服务 注意配置项之间的关联性