多节点组合模式

1 多节点选举模式

多节点选举在分布式系统中是一种重要的模式，特别是对有状态服务来说。在分布式系统中，一般来说，无状态服务，可以随意的水平伸缩，只要把运行业务逻辑的实例复制出去运行就可以，这也就是K8s里ReplicationController和ReplicaSet所做的事情。

对于有状态服务，人们也希望能够水平的扩展，但因为每个实例有自己的持久化状态，而这个持久化状态必须要延续它的生命，因此，有状态服务的水平伸缩模式就是状态的分片，其中机制跟数据库的分片是一致的。那么对于一个原生为分布式系统设计的有状态服务，每个实例与分片数据的对应关系，就成为这个有状态服务的全局信息。对于任何服务，多个实例的全局信息都需要一个保存的地方。

一个简单的办法是保存在外部的一个代理服务器上，这也就是MariaDB的Galera解决方案的做法，也是所以代理服务器为后端服务器所做的事情。但这种方式的问题在于，系统要依赖外部代理服务器，而代理服务器本身的高可用和水平伸缩还是没有解决的问题。

所以对于要原生自己解决高可用和水平伸缩问题的系统，例如Etcd和ElasticSearch，一定要有原生的主控节点选举机制。这样这个分布式系统就不需要依赖外部的系统来维护自己的状态了。对于一个分布式系统，最主要的系统全局信息，就是集群中有哪些节点，Master节点是哪个，每个节点对应哪个分片。主控节点的任务，就是保存和分发这些信息。

在K8s集群中，一个微服务实例Pod可以有多个容器。这一特性很好地提高了多节点选举机制的可重用性。它使得我们可以专门开发一个用于选举的容器镜像，在实际部署中，将选举容器和普通应用容器组合起来，应用容器只需要从本地的选举容器读取状态，就可以得到选举结果。这样，使得应用容器可以只关注自身业务逻辑相关的代码。

2工作队列模式

分布式系统的一个重要作用是能够充分利用多个物理计算资源的能力，特别是在动态按需调动计算资源完成计算任务。设想如果有大量的需要处理的任务随机的到来，对计算资源需要的容量是不确定地；显然，按照最大可能计算量和最小可能计算量设置计算节点都是不合理的。

这种情况下，可以把需要处理的任务放到一个待处理的队列里，根据需要启动计算节点从队列读取任务进行处理。在容器技术广泛应用之前，也有诸多的分布式处理系统依靠队列来处理大量计算任务，例如大数据处理系统Hadoop和Spark等。这些系统的一个限制是实现队列处理模式大多要遵循特定的编程模式和特定的编程语言，同时搭建基础设施也大多复杂而耗时。而基于容器和Kubernetes编排技术的工作队列模式的好处在于，利用非常简单的编排脚本就可以实现工作队列模式，而用Pod作为轻量级处理节点的模式，使得动态的调度计算资源变得非常容易。在Kubernetes中应用工作队列模式的逻辑示意图如下：

3 分散收集模式

分散收集模式利用分布式系统弹性计算能力的容器设计模式。在这一模式中，计算服务的使用者，即服务的客户端，将初始计算请求发送给一个“根计算节点”。根计算节点对计算任务做出分割，将任务分割成大量的小计算任务，然后将小计算任务分配给大量计算服务器进行分布式平行计算 。每个计算服务器都计算初始计算任务的一小块，将计算结果返回给根计算节点。根计算节点将所有计算结果合并起来，组成一个针对初始计算任务的一个统一的结果，返回给申请计算任务的客户端。

这一系统中的分布式服务器非常适合用容器技术来实现，具体到K8s系统中，就是一个K8s的Pod；具体到Docker系统中，就是一个Docker容器。利用容器快速部署启动和运行时开销特别小的特点，任务可以被分到很多小服务器上并行处理，这些容器形成的小服务器跟其他任务共同使用基础设施计算节点的能力。

一个典型的分散收集模式的分布式系统如下图所示。根节点接受到来自客户端的服务请求，将服务请求分配给不同的业务模块分散处理，处理结果收集到根节点，经过一定的汇聚合并运算，产生一个合并的结果交付给客户端。