『中级篇』容器编排Docker Swarm介绍（42）

到今天这次总结，如果跟着我一起学一起练的老铁，完全入门docker了。在日常的开发和测试，绝对是没有问题的。不管是我们自己和docker公司，他们的初心都是想用在生产环境下，但是生产环境和测试环境完全是两种环境条件。

之前的学习实践环境

在用学习容器编排之前，所有操作本地进行的，docker cli 连接是一台的docker host，不管是docker run 还是docker container 都是在一台机器上，但是实际的生产环境下，一个应用很复杂他部署在一台机器上满足不了我们的需求，都是通过集群的方式来解决问题的。

到处都使用容器带来的困扰

1. 怎么去管理这么多容器？
2. 怎么能方便的横向扩展？
3. 如果容器down了，怎么能自动恢复？
4. 如何去更新融起而不影响业务？
5. 怎么去调度容器的创建？
6. 保护隐私数据？

Swarm的架构

1. swarm集群的架构
2. 节点下面有角色：Worker Manager
3. Manager 是整个warm集群的大脑，为了避免单点的故障，我们的大脑至少有2个，状态的同步通过raft协议进行同步。raft协议可以确保多个Manager之前是同步的。

　分布式系统之于单机系统，优势之一就是有更好的容错性。

• 比如，一台机器上的磁盘损坏，数据丢失，可以从另一台机器上的磁盘>恢复（分布式系统会对数据做备份）
• 比如，集群中某些机器宕机，整个集群还可以对外提供服务 这是如何做到的？比较容易的一个想法就是备份（backup）。一个系统的工作模是：接受客户端的command，系统进行处理，将处理的结果返回给客户端。由此可见，系统里的数据可能会因为command而变化。 实现备份的做法之一就是复制状态机（Repilcated State Machine，RSM），它有一个很重要的性质——确定性（deterministic）：
• 如果两个相同的、确定性的状态从同一状态开始，并且以相同的顺序获得相同的输入，那么这两个状态机将会生成相同的输出，并且结束在相同的状态 也就是说，如果我们能按顺序将command作用于状态机，它就可以产生相同的状态和相同的输出 那么一个状态机如何实现呢？如下图所示（来自raft协议）：

上图中，每个RSM都有一个replicated log，存储的是来自客户端的commands。每个RSM中replicate log中commads的顺序都是相同的，状态机按顺序处理replicate log中的command,并将处理的结果返回给客户端。由于状态机具有确定性，因此每个状态机的输出和状态都是相同的。 上图中有一个模块——Consensus Module刚刚没有提及。这个模块用于保证每个server上Log的一致性！

• 如果不做任何保障，直接将commad暴力写入，一旦服务器宕机或者出现什么其他故障，就会导致这个Log丢失，并且无法恢复。而出现故障的可能性是很高的，这就导致系统不可用
• raft就是Consensus Module的一个实现 因此，raft是一致性协议，是用来保障servers上副本一致性的一种算法。

1. worker是通过gossip的网络结构进行同步
2. Service 和Replicas，这里的Service在docker compose中的Service是一样的。

命令合集

PS：之后通过很多很多的实践操作一起来学习Swarm。