REL 4: 您如何在分布式系统中设计交互以预防发生故障？
分布式系统依赖于通信网络实现组件（例如服务器或服务）的互联。尽管这些网络中存在数据丢失或延迟，但是您的工作负载必须可靠运行。分布式系统组件的运行方式不得对其他组件或工作负载产生负面影响。这些最佳实践能够预防故障，并改善平均故障间隔时间 (MTBF)。
资源
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems,
Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge
(MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems
最佳实践:
-
确定需要哪种类型的分布式系统: 硬性实时分布式系统需要同步并快速地做出响应，而软性实时系统有更宽松的以分钟计的时间窗口，或更多响应。离线系统会对响应进行批处理或异步处理。硬性实时分布式系统具有最严格的可靠性要求。
-
实施松散耦合的依赖关系: 队列系统、流系统、工作流和负载均衡器等依赖关系是松散耦合的。松散耦合有助于隔离来自其他依赖于它的组件的行为，从而提升弹性和敏捷性
-
使所有响应幂等: 幂等服务承诺每个请求只完成一次，因此发起多个相同请求与进行单个请求的效果相同。幂等服务使客户端可以轻松进行重试，而不必担心错误地处理多次。要执行此操作，客户端可以发出具有幂等性令牌的 API 请求，每当重复请求时都会使用同一令牌。幂等服务 API 使用令牌返回响应，该响应与首次完成请求时返回的响应相同。
-
持续工作: 系统会在负载中存在剧烈快速更改时失败。例如，监控着数千个服务器的运行状况检查系统每次都应发送相同大小的有效负载（当前状态的完整快照）。无论是否有服务器或有多少服务器发生故障，运行状况检查系统都会持续工作，而不会有剧烈、快速的变动。
改进计划
确定需要哪种类型的分布式系统
The Amazon Builders' Library: Challenges with distributed systems
- 硬性实时分布式系统需要快速的同步响应。
- 软性实时系统则有更宽松的以分钟计的时间窗口，或更好响应
- 离线系统会对响应进行批处理或异步处理。
- 硬性实时分布式系统具有最严格的可靠性要求。
实施松散耦合的依赖关系
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
- 您可借助 Amazon EventBridge 构建松散耦合的分布式事件驱动架构
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205) - 如果对一个组件的更改会强迫其他依赖于它的组件也发生更改，则它们之间的关系为紧密耦合。松散耦合会打破这种依赖关系，使存在依赖关系的组件只需了解经过版本控制而且已发布的接口。
- 让组件在可能的情况下进行异步交互。若确定对请求进行注册已足够，则此模型适用于无需立即响应的任何交互。
AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)
使所有响应幂等
- 客户端可以发出具有幂等性令牌的 API 请求，每当重复请求时都会使用同一令牌。幂等服务 API 使用令牌返回响应，该响应与首次完成请求时返回的响应相同。
Amazon EC2: Ensuring Idempotency
持续工作
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)
- 设计工作负载，从而不论成功或失败的次数，有效负载大小均能保持稳定。
- 例如，如果运行状况检查系统正在监控 100000 个服务器，它的标称负载低于通常而言较低的服务器故障率。但如果发生重大事件导致一半的服务器运行不正常，则运行状况检查系统会因为尝试更新通知系统以及向其客户端传送状态而变得不堪重负。因此，运行状况检查系统每次应发送当前状态的完整快照。100000 个服务器的运行状况，若每个以一个比特代表，则仅需要 12.5-KB 有效负载。无论是否有服务器或有多少服务器发生故障，运行状况检查系统都会持续工作，而剧烈、快速的变动也不会威胁到系统的稳定性。这就是实际为 Amazon Route 53 运行状况检查量身定制的控制层面。