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

  • Jan Stenberg
  • 邵思华

2015 年 8 月 23 日

话题:SOA语言 & 开发架构

与近期与 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

SOA语言 & 开发架构