转：分布式系统设计的几条原则

      转自：http://outerthought.org/blog/410-ot.html

      本文是Google院士jeff dean在今年SOCC大会上的一次演讲的笔记，主要介绍了一些用于设计分布式系统的模式，原文地址，这次演讲的视频地址（需要安装Silverlight）。

分布式系统设计模式

1.系统失败是很平常的事情：每年有1-5%的硬盘会报废，服务器每年会平均宕机两次，报废几率在2-4%几率。

 

2.将一个大而复杂系统切分为多个服务：而且服务之间依赖尽可能的少，这样有助于测试，部署和小团队独立开发。例子：一个google的搜索会依赖100多个服务。ike：需要一套机制来确保服务的fault-tolerant，不能让一个服务的成败影响全局。

 

3.需要有Protocol Description Language：比如protocol buffers。ike：这样能降低通信方面的代码量。

 

4.有能力在开发之前，根据系统的设计来预测性能：在最下面有一些重要的数字。

 

5.在设计系统方面，不要想做的很全面，而是需要抓住重点。

 

6.为了增量做设计，但不为无限做设计：比如：要为5-50倍的增量做设计，但超过1000倍了，就需要重写和重新设计了。

 

7.使用备份请求来降低延迟：比如一个处理需要涉及1000台机器，通过备份请求这个机制来避免这个处理被一台慢机器延误。ike：这个机制非常适合MapReduce。

 

8.使用范围来分布数据，而不是Hash：因为这样在语义上比较简单，并且容易控制。ike：在大多数情况下语义比性能更重要，不要为了20%的情况hardcode。

 

9.灵活的系统，根据需求来伸缩：并且当需求上来的时候，关闭部分特性，比如：关闭拼写检查。

 

10.一个接口，多个实现。

 

11.加入足够的观察和调式钩子（hook）。

 

12.1000台服务器只需单一Master：通过Master节点来统一指挥全部的行动，但客户端和Master节点的交互很少，以免Master节点Crash，优点是，在语义上面非常清晰，但伸缩性不是非常强，一般最多只能支持上千个节点。

 

13.在一台机器上运行多个单位的服务：当一台机器宕机时，能缩短相应的恢复时间，并且支持细粒度的负载均衡，比如在BigTable中，一个Tablet服务器会运行多个Tablet。

图1. 重要的数字

 

未来的挑战

1.全球级（world-wide）系统的适应性方面：如何自动地分配和放置数据和计算来降低延迟和成本。

 

2.在弱一致性（weakly consistent）的存储上搭建应用：如何轻松使用抽象来解决多版本之间的冲突。

 

3.分布式系统的抽象：如何用同一个抽象来统一多个分布式系统。