从分布式系统的设计理念说起

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

另外，任何分布式系统都存在让人无法回避的风险和严重问题，即系统发生故障的概率大大增加：小到一台服务器的硬盘发生故障或宕机、一根网线坏掉，大到一台交换机甚至几十台服务器一起停机。分布式系统下故障概率的增加，除了受到网络通信天生的不可靠性及物理上分布部署的影响，还受到 X86 服务器品质等的影响。

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

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

下面继续谈谈分布式系统设计中的两大思路：中心化和去中心化。

在分布式架构设计里，中心化始终是一个主流设计。中心化的设计思想很简单，分布式集群中的节点器按照角色分工，大体上分为两种角色：Leader 和 Worker。Leader 通常负责分发任务并监督 Worker，让 Worker 一直在执行任务；如果 Leader 发现某个 Worker 因意外状况不能正常执行任务，则将该 Worker 从 Worker 队列去除，并将其任务分给其他 Worker。基于容器技术的微服务架构 Kubernetes 就恰好采用了这一设计思路。 在分布式中心化的设计思路中，还有一种设计思路与编程中敏捷开发的思路类似，即充分相信每个 Worker，Leader 只负责任务的生成而不再指派任务，由每个 Worker 自发领任务，从而避免让个别 Worker 执行的任务过多，并鼓励能者多劳。

中心化设计存在的最大问题是 Leader 的安全问题，如果 Leader 出了问题，则整个集群崩溃。但我们难以同时安排两个 Leader 以避免单点问题。为了解决这个问题，大多数中心化系统都采用了主备两个 Leader 的设计方案，可以是热备或者冷备，也可以是自动切换或者手动切换，而且越来越多的新系统都具备了自动选举切换 Leader 的能力，以提升系统的可用性。中心化设计还存在另外一个潜在的问题，即 Leader 的能力问题，如果系统设计和实现得不好，问题就会卡在 Leader 身上。

下面一起探讨去中心化设计。

在去中心化设计里通常不区分 Leader 和 Worker 这两种角色。全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备宕机，都只会影响很小范围的功能。去中心化设计的核心是在整个分布式系统中不存在一个区别于其他节点的 Leader，因此不存在单点故障问题，但由于不存在 Leader，所以每个节点都需要与其他（所有）节点对话才能获取必要的集群信息，而分布式系统通信的不可靠性大大增加了上述功能的实现难度。

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

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

参考：从分布式到微服务