从零开始理解分布式系统架构与设计原理(3)

从零开始理解分布式系统架构与设计原理

上面垂直拆分之后各个节点组成的就是一个集群，而水平拆分各个节点就是分布式。

这就是集群和分布式的区别。

集群除了上面提到的可以提高并发处理能力外，还可以保证系统的高可用，当一部分节点失效后，整个系统依旧可以提供完整的服务。

分布式也一样，除了提高并发能力，解耦系统，使系统边界更清晰，系统功能更内聚也是其一大好处，所以在实际的系统中我们往往这两种方式同时都在使用，而且我们常常提及的分布式系统其实是包含着集群的概念在里面的。

分布式目标

归纳和演绎是人类理性的基石，学习和思考就是不断的归纳过去的经验，从而得到普遍的规律，然后将得之的规律演绎于其他事物，用于指导更好的实践过程。

上面我们讲解了分布式系统的由来，现在我们回顾和总结一下这个过程。我们引入分布式系统必然是基于现实的需求和目标而来的。

不念：那分布式的目标什么呢？

分布式就是为了满足以下目标而设计的：

• Transparency: 透明性，即用户是不关心系统背后的分布式的，无论系统是分布式的还是单机的，对用户来说都应该是透明的，用户只需要关心系统可用的能力。这里的透明性就包括以下方面：
  • 访问透明性：固定统一的访问接口和方式，不因为分布式系统内部的变动而改变系统的访问方式。
  • 位置透明性：外部访问者不需要知道分布式系统具体的地址，系统节点的变动也不会影响其功能。
  • 并发透明性：几个进程能并发的使用共享资源而不互相干扰。
  • 复制透明性：使用资源的多个实例提升可靠性和性能，而用户和程序员无需知道副本的相关信息。
  • 故障透明性：分布式系统内部部分节点的故障不影响系统的整体功能。
  • 移动透明性：资源和客户能够在系统内移动而不受影响。
  • 性能透明性：负载变化时，系统能够被重新配置以提高性能。
  • 伸缩透明性：系统和应用能够进行扩展而不改变系统结构和应用算法。
• Openness: 开放性，通用的协议和使用方式。
• Scalability: 可伸缩性，随着资源数量的增加和用户访问的增加，系统仍然能保持其有效性，该系统就被称为可伸缩的。分布式系统应该在系统大小，系统管理方面都可扩展。
• Performance: 性能，相对于单体应用，分布式系统应该用更加突出的性能。
• Reliability: 可靠性，与单体系统相比，分布式系统应具有更好安全性，一致性和掩盖错误的能力。

分布式挑战

分布式的挑战来源于不确定性。想一想，分布式系统相对于单体应用，多了哪些东西？

不念：有了更多的服务节点，还有就是服务之间的网络通信。

是的，看来不念同学已经懂得思考和分析系统了。

分布式系统的所有挑战就来源于这两者的不确定性。

1. 节点故障：

节点数量越多，出故障的概率就变高了。

分布式系统需要保证故障发生的时候，系统仍然是可用的，这就需要系统能够感知所有节点的服务状态，在节点发生故障的情况下将该节点负责的计算、存储任务转移到其他节点。

2. 不可靠的网络：

节点间通过网络通信，我们都知道网络是不可靠的。可能的网络问题包括：网络分割、延时、丢包、乱序。

相比单机过程调用，网络通信最让人头疼的是超时已经双向通行的不确定性。出现超时状态时，网络通信发起方是无法确定当前请求是否被成功处理的。

在不可靠的网络和节点中，分布式系统依然要保证其可用，稳定，高效，这是一个系统最基本的要求。因此分布式系统的设计和架构充满了挑战。

分而治之

分布式系统就是充分利用更多的资源进行并行运算和存储来提升系统的性能，这就是分而治之的原理。

不念：哦，懂了懂了，那 MapReduce 的 map，Elasticsearch 的 sharding，Kafka 的 partition 是不是都是分布式的分而治之原理。

可以啊，不念同学不仅能够归纳，还能够举一反三了。

不错，无论是 map，sharding 还是 partition，甚至请求路由负载均衡都是在将计算或数据拆分，再分布到不同的节点计算和存储，从而提高系统的并发性。

不同集群类型的拆分方式

sharding

同样是分，在不同领域的，甚至不同实现的系统中通常会有不同的说法。

sharding 通常是在数据存储系统中将不同数据分布到不同节点的方式，中文通常翻译为数据分片。

比如在 MongoDB 中，当 MongoDB 存储海量的数据时，一台机器可能不足以存储数据，也可能不足以提供可接受的读写吞吐量。

这时，我们就可以通过在多台机器上分割数据，使得数据库系统能存储和处理更多的数据。