详解分布式系统本质：“分治”和“冗余”.docxVIP

详解分布式系统本质：“分治”和“冗余” 分治，字面意思是“分而治之”，和我们的大脑在处理问题时的思考方式是一样的。我们可以将整个过程分为 3 步：分解 - 管理 - 归并。而分治思想的表现方式多样，分层、分块都是它的体现。 这么做的好处是：问题越小越简约被处理，并且，只需处理了全部子问题，父问题就都可以被处理了。但是，这么做的时候，需要满足一个最重要的条件：不同分支上的子问题，不能相互依靠，需要各自独立。由于一旦包含了依靠关系，子问题和父问题之间就得到了可以被“归并”的意义。在软件开发领域，我们把这个概念称为“耦合度”和“内聚度”，这两个度量概念格外重要。 耦合度，指的是软件模块之间相互依靠的程度。比如，每次调用方法 A 之后都需要同步调用方法 B，那么此时方法 A 和 B 间的耦合度是高的。 内聚度，指的是模块内的元素具有的共同点的相像程度。比如，一个类中的多个方法有很多的共同之处，都是做领取相关的处理，那么这个类的内聚度是高的。 内聚度通常与耦合度构成对比。低耦合通常与高内聚相关，反之亦然。 所以，当你打算进行分治的时候，耦合度和内聚度就是需要考虑的重点。 下面我们来看个例子，体会一下耦合度和内聚度的含义。（图仅用于表达含义，切勿作其他参考） 假设一个电商平台，为了应对更大的访问量，需要拆分一个同时包含商品、促销的系统。假如垂直拆分，是这样： 而假如水平拆分，则是这样的： 假如我们面对的场景仅仅是具体的商品详情呈现页面，很明显，用水平拆分的效果会更好。由于传统的商品呈现必定会同时呈现促销，所以，假如用水平拆分，一次恳求即可猎取全部数据，内聚度格外高，并且此时模块间完全没有耦合。而假如是垂直拆分的话，就需要同时恳求 2 个节点的数据并进行组合，因而耦合度更高、内聚度更差。 但是，这样的假设在真实的电商场景中是不存在的。从全局来看，订单、购物车、商品列表等很多其他场景也需要促销信息。并且这个时候我们发觉引入了一些新的主体，诸如订单、购物车、商品分类等等。这个时候，水平拆分带来的好处越来越小，由于这样只处理了多个耦合中的一个，低耦合丢失了。并且随着商品和促销与外界的关联越来越多，必定有些场景仅仅涉及到商品和促销的其中一个，但是处理的时候，我们还需要避开遭到另一个的影响。如此，高内聚也丢失了。 这个时候，反而通过垂直拆分可以获得更优的耦合度和内聚度，如下图。 这个时候，最高的耦合关系从原先的 6 降到了 4，并且商品和促销各自的处理相互不受影响。 所以，你会发觉随着业务的变化，耦合度与内聚度也会发生变化。因而，准时地进行梳理和调整，可以避开系统的简单度快速增长，才能最大程度的发挥“分治”带来的好处。 综上，分治可以简化解题的难度，通过高内聚、低耦合的协作关系达到更好“功能与经济比”，来承载更大的流量。而“冗余”则带来了系统可以 7*24 小时不间断运作的期望。 冗余 这里的冗余并不等同于代码的冗余、无意义的反复劳动，而是我们有意去做的、人为添加的反复部分。其目的是容许在肯定范围内消灭毛病，而系统不受影响，如下图。 此时，我们可以将冗余的节点部署在一个独立的环境中。这个独立的环境，可能是处于同一个局域网内的不同主机，也可能是在不同的局域网，还可能是在不同的机房。很明显，它们能够应对的毛病范围是逐渐递增的。 但是，像这种单纯地为了备用而做的冗余，最大的弊端是，假如没有消灭毛病，那么冗余的这部分资源就白白铺张了，不能发挥任何作用。所以，我们才提出了诸如双主多活、读写分别之类的概念，以提高资源利用率。 当然，除了软件层面，硬件层面的冗余也是同样的道理。比如，磁盘阵列可以容忍几块之内磁盘损坏，而不会影响全体。 不过也很明显，当毛病影响范围大于你冗余的容量时，系统照旧会挂。所以，既然你无法预知毛病的发生情况，那么做冗余的时候需要平衡的另一端就是成本。相比更多的冗余，追求更好的性价比更合理一些。 在我们生活中的冗余也处处存在。比如，大部分的飞机和直升机的发动机都是偶数的，汽车中的电子把握系统的冗余机制等。就好比替身与真身的关系，冗余的就是替身。它可以和真身同时活动，也可以代替真身活动。 分治和冗余讲究的都是分散化，最终构成一个完整的系统还需要将它们“连接”起来。天下没有免费的午餐，获得分布式系统价值的同时，这个“再连接”的过程就是我们相比集中式系统要做的额外工作。 再连接 如何将拆分后的各个节点再次连接起来，从模式上来说，次要是去中心化与中心化之分。 前者完全衰退了中心节点毛病带来的全盘出错的风险，却带来了更高的节点间协作成本。后者通过中心节点的集中式管理大大降低了协作成本，但是一旦中心节点毛病则全盘出错。 另外，从技术角度来说，如何选择通信协议和序列化机制，也是格外重要的。 虽然很多通讯协议和序列化机制完全可以担当任何场景的连接责任，但是不同