11、微服务架构：异步、分布式与故障应对策略

微服务架构：异步、分布式与故障应对策略

1. 异步编程的应用与权衡

异步编程风格需要一些时间来适应。我们需要摒弃传统的函数调用返回结果的编程模式思维，转而采用更具事件驱动的方式。其优势在于能带来更高的灵活性，在异步交互中添加新的微服务变得更加容易。例如，购物车服务在用户结账时发布结账消息，负责记录购买信息、发送确认邮件和安排配送的微服务可独立监听该消息，无需特定的命令消息触发，购物车服务也无需了解其他服务的具体情况。这使得添加新功能（如增加忠诚度积分的微服务）变得轻松，无需对现有生产服务进行更改。

不过，异步方法也存在缺点。随着消息和微服务数量的增加，系统行为会变得隐晦，难以理解所有的系统交互，可能出现意外的行为模式。为降低这些风险，可采用严格的渐进式系统变更方法，并对系统行为进行有意义的度量。

2. 分布式计算的误区与挑战

微服务系统属于分布式系统，分布式计算存在诸多难以解决的问题。许多分布式计算框架试图让远程和本地操作看起来相同，但这种做法只是暂时缓解问题，却隐藏了系统的固有复杂性，使架构变得脆弱，易出现灾难性故障。

分布式计算存在以下常见误区：
- 网络是可靠的。
- 延迟为零。
- 带宽是无限的。
- 网络是安全的。
- 拓扑结构不会改变。
- 只有一个管理员。
- 传输成本为零。
- 网络是同质的。

微服务无法让我们避开这些误区，我们应正视这些警告，而非试图解决它们。以拜占庭将军问题为例，两位将军分别指挥 1000 名士兵对抗 1500 人的敌军，只有同时进攻才能获胜。将军通过信使传递消息，但信使可能被俘虏，即使使用不可破解的密