分布式系统的开发经验与心得

与近期与 InfoQ 的一次对话中， Vaughn Vernon 分享了一些他在开发分布式系统方面的心得。他特别指出，在分布式系统中，有可能会出现局部故障之类的问题。对于这种类型的问题以及一些其它挑战来说，最佳的应对方式是做好一切准备，而不是无助地祈祷它不要出现。Vaughn 还推荐了 Jeff Hodges 所撰写的一篇博客文章，这篇文章为分布式系统给出了一些落到实处的设计方式，并提出了一些实用的建议，非常适合于在分布式系统方面经验尚浅的开发者。

Vaughn Vernon 是《实现领域驱动设计》以及最新的《通过Actor Model 实现响应式消息处理模式》这两本书的作者。在他看来，Hodges 的文章中有两个推荐是最有价值的，一是尝试为局部可用性进行设计，二是当依赖的系统变得不可用时，通过使用capped 指数退避（exponential back off）算法恢复完整的操作。这种方式是当故障发生时，你所能做的最好的期望，这会让你想到Vernon 的评价。

Hodges 发现，新手往往会将延迟视为分布式计算中最困难的一部分。但在他看来，分布式系统的区别性因素在于出现故障的可能性增大了，尤其是局部故障的出现率。因此，他建议设计者去寻找一些能够实现局部可用性的设计方式。他以一个设计良好的搜索系统作为示例，如果发生搜索操作超时的情况，那么系统应当返回在超时之前所获得的搜索结果，这种方式可以有效地提高系统的弹性。

在 Hodges 看来，要创建健壮的分布式系统，一个最基本的构建块就是背压（backpressure）机制。被请求的系统会向发起请求的系统发出故障信号，以避免出现过载的情况。实现这种机制有一些常见的方式，例如丢弃消息，或是在处理一个有可能失败的请求之前就返回错误信息。

Hodges 强烈反对在服务器之间进行协调的做法，他倾向于让服务器保持独立性，将互相之间的通信次数降至最低。因为一旦出现需要两台服务器对某个操作表示允许的情况，整个服务的实现就变得更加困难了。

Hodges 还认为，如果能够找到一些高层次的业务逻辑，并将其提炼为服务，则能够带来许多益处。一个经过提炼的服务能够提供更好的封装性，并且能够让代码变更的部署更快、更简便。在他看来，对于部署至多个客户的情况，在服务这一层进行协调的成本，比之让所有客户端使用一个共享的类库，在部署时必须对所有客户进行协调的成本来说要低上许多。

Hodges 在文中也描述了一些在他的职业生涯中所学到的一些经验教训，例如利用特性标记交付基础设施，以及为系统选择 id 空间时所需考虑的各种因素。

查看英文原文： Lessons Learned Working with Distributed Systems