BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Jan Stenberg 关注 29 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2015年8月24日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT