分布式系统设计理念

首先，分布式系统的首要目的是提升系统的整体性能和吞吐量。如果最终设计出来的分布式系统占用了10台机器才勉强达到单机系统的两倍性能，那么这个分布式系统还有存在的价值吗？另外，即使采用了分布式架构，也仍然需要尽力提升单机上的程序性能，使得整体性能达到最高。所以，我们仍然需要掌握高性能单机程序的设计和编程技巧，例如多线程编程、多进程高性能IPC通信、高性能的网络框架等。

其次，任何分布式系统都存在让人无法回避的风险和严重问题，即系统发生故障的概率大大增加：小到一个服务器的硬盘发生故障或宕机、一根网线被老鼠啃坏了，大到交换机甚至几十台服务器一起歇火。在分布式系统下故障概率之所以增加，除了主要由于网络通信天生的不可靠性及物理上的分布部署，还由于X86服务器的品质越来越差，远不如UNIX小机器，这大概是工业化导致“工匠精神”的匮乏在IT上的一个缩影吧。

综上分析，我们看到分布式系统社二级的两大关键目标是“性能”与“容错性”，而这两个目标的实现恰恰都是很棘手的问题，而且相互羁绊！举个例子，比如我们设计一个分布式存储系统，处于对性能的考虑，写文件时先写一个副本到某个机器上并立即返回，然后异步发起多副本的复制过程，这种设计性能最好，但存在“容错性”的风险，即文件写完后，目标机器立即发生故障，导致文件丢失！如果同时写多个副本，每个副本成功以后再返回，则又导致“性能”下降，因为这个过程取决于最慢的那台机器的性能。

由于“性能”的指标是绝对的，而“容错性”的指标是绝对的，而且实际上对于不同的数据与业务，我们要求的容错性其实可以存在很大的差异：允许意外丢失一些日志类的数据；允许一些信息类的数据暂时不一致而最终达到一致；而对交易类的数据则要求有很高的可靠性。于是你会发现，很多分布式系统的设计都提供了多种容错性策略，以适应不同的业务场景，我们在学习和设计分布式系统的过程中也需要注意这一特性。

分布式系统设计中的两大思路：中心化和去中心化。

中心化

中心化的设计思想很简单，分布式集群中的节点机器按照角色分工，大体上分为两种角色：”领导“和”干活儿的“，”领导“通常负责分发任务并监督”干活的“，发现谁太闲，就想方设法地给其安排新任务，确保没有一个”干活的“能够偷懒；如果”领导“发现某个”干活的“因为劳累过度而病倒了，则是不会考虑先尝试”医治“他的，而是一脚踢出去，然后把他的任务分给其他人。而Google最近开源的基于容器技术的微服务架构Kubernetes就恰好采用了这一设计思路。

在分布式中心化的设计思想中，除了上诉的设计思路之外，还有一种设计思路与编程中的敏捷开发的做法类似，即充分相信每个“干活儿的”，“领导”只负责任务的生成而不在指派任务，由每个“干活的”自发去领任务，从而避免让个别员工积劳成疾，并鼓励能者多劳，但还是不发奖金。

中心化的设计存在的最大问题就是“领导”的安危问题，如果“领导”出了问题，则群龙无首，整个系统集群就会奔溃。但我们难以同时安排两个“领导”以避免单点问题，是因为“一山不容二虎”。为了解决这个问题，大多数中心化系统都采用了主备两个“领导”的设计方案，可以是热备或者冷备，也可以是自动切换或者手动切换，而且越来越多的新系统都开始具备自动选举切换“领导”的能力，以提升系统的可用性。中心化设计还存在另外一个潜在的问题就是“领导”的能力问题：可以领导10个人高效工作并不意味着可以领导100个人高效工作，所以如果系统设计和实现得不好，问题就会卡在“领导”身上。

去中心化

在去中心化的设计里，通常没有“领导”和“干活儿的”这两种角色的区分，大家的角色都是一样的，地位是平等的。去中心化设计的核心在于整个分布式系统中不存在区别于其他节点的“领导”，因此不存在单点故障问题，但由于不存在“领导”，所以每个节点都需要跟其他节点对话才能获取到必要的信息，而分布式系统通信的不可靠性，则大大增加了上诉功能的实现难度。

去中心化最难解决的问题就是“脑裂”问题，这种情况的发生率很低，但影响很大。脑裂指一个集群由于网络的故障，被分为至少两个彼此无法通信的单独集群，此时如果两个集群都各自工作，则可能会产生严重的数据冲突和错误。一般的设计思路是，当集群判断发生了脑裂问题，规模较小的集群就“自杀”或者拒绝服务。

实际上，完全意义的真正去中心化的分布式系统并不多见。相反，外部看来去中心化但工作机制采用了中心化设计思想的分布式系统正在不断涌出。在这种架构下，集群中的领导是被动态选择出来的，而不是人为预先指定的，而且集群发生故障的情况下，集群的成员会自发地举行“会议”选举新的“领导”主持工作。最典型的案例就是Zookeeper。

参考：架构解密从分布式到微服务（Leaderus著）