DCOS=Mesos+ZooKeeper+Marathon+Docker

Posted 2021-04-13 通信互联网技术笔记

摘要

用了三周的时间在分布式系统这个栏目里写了五篇文章，包括4个核心组件，Mesos、Marathon、ZooKeeper、Docker及一个数据中心操作系统DCOS，那么他们之间关系到底是什么？是时候做一个总结了。所以这篇文章叫DCOS=Mesos+ZooKeeper+Marathon+Docker，彻底把它们之间的关系串联起来。

I-Framework[DCOS=Mesos+ZooKeeper+Marathon+Docker]

一、 组件回顾

化繁为简，第一部分简单回顾一下Mesos、Marathon、ZooKeeper、Docker四个组件的核心能力，详细内容请翻阅之前发布的每个组件的专栏文章。

（一）组件概要

Mesos：Mesos采用与Linux kernerl相同的机制，只是运行在不同的抽象层次上，是分布式计算的内核。Mesos kernel利用资源管理和调度的API在整个数据中心或云环境中运行和提供引用（例如，Hadoop，Spark，Kafaka，Elastic Search）。

Marathon：Marathon是一个Mesos框架，能够支持运行长服务，比如web应用等。是集群的分布式Init.d，能够原样运行任何Linux二进制发布版本，如Tomcat Play等等，可以实现集群的多进程管理。也是一种私有的Pass，实现服务的发现，为部署提供提供REST API服务，有授权和SSL、配置约束，通过HAProxy实现服务发现和负载平衡。

ZooKeeper：ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。在DCOS中主要负责组件注册及选举还有配置存储。

Docker：Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。

本章第二部分归纳总结以上4个核心组件的组成及工作流程。

（二）Mesos

1、Mesos组成

Mesos的目标就是在不同的Framework之间高效的共享硬件资源，Mesos Master协调全部的Slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework（作为Master的客户端）发出资源邀约。一旦接受邀约，Master即协调Framework和Slave，调度参与节点上任务，并在容器中执行，以使多种类型的任务，比如Hadoop和Cassandra，可以在同一个节点上同时运行。

                                             

• Mesos-master（主控制）：协调全部的slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework发出资源邀约。

• Mesos-slave（被控制）：向master汇报自己的空闲资源和任务的状态，负责管理本节点上的各个Mesos-task，在Framework成功向Master申请资源后,收到消息的slave会启动相应Framework的exexutor

• Framework：Hadoop，Spark等，通过MesosSchedulerDiver接入Mesos。Framework是实际干活的，可以理解为 Mesos 上跑的应用，需要注册到master上。

• Executor：执行器，用于启动计算框架中的task。

Slave节点负责接收并执行来自Mesos-master的命令、管理节点上的Mesos-task，并为各个task分配资源。Slave节点上的资源总量是固定的。Mesos-slave将自己的资源量发送给Mesos-master，由Mesos-master中的Allocator模块决定将资源分配给哪个Framework，当前考虑的资源有CPU和内存两种，也就是说，Mesos-slave会将CPU个数和内存量发送给Mesos-master，而用户提交作业时，需要指定每个任务需要的CPU个数和内存量，当任务运行时，Mesos-slave会将任务放到包含固定资源的Container中运行，以达到资源隔离的效果。

2、Mesos工作流程

Mesos的目标就是在不同的Framework之间高效的共享硬件资源，Mesos Master协调全部的Slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework（作为Master的客户端）发出资源邀约。一旦接受邀约，Master即协调Framework和Slave，调度参与节点上任务，并在容器中执行，以使多种类型的任务，比如Hadoop和Cassandra，可以在同一个节点上同时运行。

上图中，Slave是运行在物理或虚拟服务器上的Mesos守护进程，是Mesos集群的一部分。Framework由调度器（Scheduler）应用程序和任务执行器（Executor）组成，被注册到Mesos以使用Mesos集群中的资源。资源调度的具体流程（模拟）如下：

第一步：Slave 1向Master汇报其空闲资源：4个CPU、4GB内存。然后，Master触发分配策略模块，得到的反馈是Framework 1要请求全部可用资源。

第二步：Master向Framework 1发送资源邀约，描述了Slave 1上的可用资源。

第三步：Framework的调度器（Scheduler）响应Master，需要在Slave上运行两个任务，第一个任务分配<2 CPUs, 1 GB RAM>资源，第二个任务分配<1 CPUs, 2 GB RAM>资源。

最后一步：Master向Slave下发任务，分配适当的资源给Framework的任务执行器（Executor）,接下来由执行器启动这两个任务（如图中虚线框所示），在容器中执行。 此时，还有1个CPU和1GB的RAM尚未分配，因此分配模块可以将这些资源供给Framework 2。

为了实现在同一组Slave节点集合上运行多任务这一目标，Mesos使用了隔离模块， 该模块使用了一些应用和进程隔离机制来运行这些任务。Mesos当前模块支持的是容器隔离。为运行特定应用程序的任务，都需要将执行器全部打包，并在已经为该任务分配资源的Slave服务器上启动（或者说到指定的Docker里）。这个为该任务分配资源的过程就是Marathon资源调度的过程，当任务执行完毕后，容器会被“销毁”，资源会被释放，以便可以执行其他任务。

（二）Marathon

1、Marathon组成

Marathon又叫容器编排引擎，从名字可见马拉松的主要作用还是容器编排与调度, 马拉松的最大作用就是调度容器（任务/实例）与物理资源的关系。Marathon（马拉松）是Mesos的Framework. 如果把Mesos比喻成Kernel的话，那么Marathon就是它的守护进程Daemon。Marathon是一个“元架构”，随着Mesos一起运行，并且在运行工作负载的同时提供了更高的可用性，让用户可以添加资源以及自动的故障转移。DCOS中内嵌的Marathon部署在master节点上。

2、Marathon工作流程

图中部属的机器为3个Master控制节点，3个slave运行节点，其中ZooKeeper、Mesos-master、Marathon运行在Master端。Mesos-slave和docker运行在Slave端。

Frameworks运行在Mesos中,不需要直接与Mesos-DNS通信。Mesos-DNS定期查询Mesos master(s),检索所有运行的框架中正在运行的任务的状态,并为这些任务生成DNS记录，包括A记录与SRV记录。当Mesos集群中的任务开始,结束,或重启,Mesos-DNS都需要更新DNS记录以保证为最新状态。

Marathon基于Mesos的任务调度为动态调度，即每个任务在执行之前是对具体服务器和绑定端口均为未知。Mesos集群上混合运行着包括Marathon在内各种调度框架的任务，当某台服务器宕机以后，Marathon可把任务迁移到其他服务器上，实现容错。Mesos仅负责分布式集群资源分配，Marathon负责任务调度，故障转移。ET负责进行的调度管理。

（三）ZooKeeper

1、ZooKeeper组成

ZooKeeper是分布式应用程序协调服务，它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

ZooKeeper在实现这些服务的基础是一种新的数据结构——Znode，然后在该数据结构的基础上定义了一些原语，也就是一些关于该数据结构的一些操作。有了这些数据结构和原语还不够，因为我们的ZooKeeper是工作在一个分布式的环境下，我们的服务是通过消息以网络的形式发送给我们的分布式应用程序，所以还需要一个通知机制——Watcher机制。那么总结一下，ZooKeeper所提供的服务主要是通过：数据结构+原语+watcher机制，三个部分来实现的。

ZooKeeper通常为分布式系统提供了命名服务、.配置管理、集群管理、分布式锁、队列管理5种服务。在DCOS中ZooKeeper用于集群的管理，包括统一配置管理，选举Leader等。

（1）命名服务

ZooKeeper命名服务：在ZooKeeper的文件系统里创建一个目录，即有唯一的path。在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好path，通过path即能互相探索发现。

（2）配置管理

ZooKeeper的配置管理：程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。现在把这些配置全部放到ZooKeeper上去，保存在 ZooKeeper 的某个目录节点（Config）中，然后所有相关应用程序对这个目录节点进行监听（客户端设置Watch），一旦配置信息发生变化，每个应用程序就会收到 ZooKeeper 的通知，然后从 ZooKeeper 获取新的配置信息应用到系统中就好

（3）集群管理

ZooKeeper集群管理：所谓集群管理包括两个内容，第一是否有机器退出和加入，第二选举master。

对于管理机器退出，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 ZooKeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。新机器加入也是类似，所有机器收到通知，新兄弟目录加入，highcount又有了。

对于选举Master，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。

（4）分布式锁

ZooKeeper分布式锁：有了ZooKeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

对于保持独占的锁，我们将ZooKeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock （分配锁）节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。

对于控制时序的锁，/distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。

（5）队列管理

ZooKeeper两种类型的队列：

• 同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。

• 队列按照 FIFO 方式进行入队和出队操作。

同步队列，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。 另一种队列和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。

2、ZooKeeper工作流程

ZooKeeper的核心是原子广播，这个机制保证了各个Server之间的同步（负责广播从leader节点到follower节点的变化）。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（ZooKeeper选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

在DCOS中在分布式锁服务中，有一种最典型应用场景，就是Mesos中通过对集群进行Master选举，来解决分布式系统中的单点故障。

在引入了ZooKeeper以后我们启动了两个主节点，"主节点-A"和"主节点-B"他们启动以后，都向ZooKeeper去注册一个节点。我们 假设"主节点-A"锁注册地节点是"master-00001"，"主节点-B"注册的节点是"master-00002"（在GroupMembers目录下创建临时节点），注册完以后进行选举，编号最小的节点将在选举中获胜获得锁成为主节点，也就是我们的"主节点-A"将会获得锁成为主节点，然后"主节点-B"将被阻塞成为一个备用节点。那么，通过这 种方式就完成了对两个Master进程的调度。

ZooKeeper支持Marathon高可用的模式，在高可用的模式下，如果某一个Marathon服务中断，依然可以继续保持正在运行的常驻服务不间断运行。Marathon的高可用模式部署非常简单，只需要启动多个Marathon的服务并且指定一个相同的ZooKeeper路径，ZooKeeper会提供多个Marathon服务之间的Leader选举。

（四）Docker

1、Docker组成

Docker与虚拟机一样是虚拟化的方法之一，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。由于容器是进程级别的，相比虚拟机有很多优势。Docker属于Linux容器的一种封装，提供简单易用的容器使用接口。

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。一个完整的Docker有以下几个部分组成：

（1）Docker Client

Docker提供给用户的客户端。Docker Client提供给用户一个终端，用户输入Docker提供的命令来管理本地或者远程的服务器。

（2）Docker Daemon

Docker服务的守护进程。每台服务器（物理机或虚机）上只要安装了Docker的环境，基本上就跑了一个后台程序Docker Daemon，Docker Daemon会接收Docker Client发过来的指令,并对服务器的进行具体操作。

（3）Docker Images

Docker把应用程序及其依赖（环境），打包在image文件里面。只有通过这个文件，才能生成Docker容器（Container）。image文件可以看作是容器的模板。Docker根据image文件生成容器的实例。同一个image文件，可以生成多个同时运行的容器实例。

Docker镜像是Docker容器运行时的只读模板，每一个镜像由一系列的层(layers)组成。Docker使用UnionFS来将这些层联合到单独的镜像中。UnionFS允许独立文件系统中的文件和文件夹(称之为分支)被透明覆盖，形成一个单独连贯的文件系统。正因为有了这些层的存在，Docker是如此的轻量。当你改变了一个Docker镜像，比如升级到某个程序到新的版本，一个新的层会被创建。因此，不用替换整个原先的镜像或者重新建立(在使用虚拟机的时候你可能会这么做)，只是一个新的层被添加或升级了。现在你不用重新发布整个镜像，只需要升级，层使得分发Docker镜像变得简单和快速。

（4）Docker Registry

Docker Images的仓库，就像git的仓库一样，用来管理Docker镜像的，提供了Docker镜像的上传、下载和浏览等功能。Docker 仓库也有公有和私有的概念，提供安全的账号管理可以管理只有自己可见的私人image。官方的Registry，叫做Dock Hub。

（5）Docker Container

Docker的容器，Container是真正跑项目程序、消耗机器资源、提供服务的地方，Docker Container通过Docker Images启动，在Docker Images的基础上运行你需要的代码。Docker容器（container）通过Docker镜像来创建。可以认为Docker Container提供了系统硬件环境，然后使用了Docker Images这些制作好的系统盘，再加上你的项目代码，跑起来就可以提供服务了。Container是image文件生成的容器实例，本身也是一个文件，称为容器文件。也就是说，一旦容器生成，就会同时存在两个文件，image文件和容器文件。而且关闭容器并不会删除容器文件，只是容器停止运行而已。

2、Dcoker工作流程

用户使用Docker Client与Docker Daemon建立通信，并发送请求给后者。而Docker Daemon作为Docker架构中的主体部分，首先提供Server的功能使其可以接受Docker Client的请求，而后Engine执行Docker内部的一系列工作，每一项工作都是以一个Job的形式的存在。Job的运行过程中，当需要容器镜像时，则从Docker Registry中下载镜像，并通过镜像管理驱动graphdriver将下载镜像以Graph的形式存储。当需要为Docker创建网络环境时，通过网络管理驱动networkdriver创建并配置Docker容器网络环境。当需要限制Docker容器运行资源或执行用户指令等操作时，则通过execdriver来完成。

而libcontainer是一项独立的容器管理包，networkdriver以及execdriver都是通过libcontainer来实现具体对容器进行的操作。

当执行完运行容器的命令后，一个实际的Docker容器就处于运行状态，该容器拥有独立的文件系统，独立并且安全的运行环境等。

二、 DCOS的实现

（一）DCOS整体架构

DCOS是以 Mesos为“核心”，与其周边服务及功能组件所组成的一个生态系统。它跨越数据中心或云环境中的所有主机，将所有主机的资源放入一个资源池，使所有主机的行为整体上像一个大计算机，如下图所示。

由图可见，DCOS除了内核Mesos，还有两个关键组件Marathon和Chronos。其中，Marathon用于启动长时间运行应用程序和服务的框架，Chronos运行和管理计划任务的框架。分布式协调服务有ZooKeeper来实现，主要完成Mesos的Master选举及Mesos、Marathon等组件配置的协调。物理资源的隔离由Docker实现，Docker是由Marathon创建及调度的。其实Framework可以认为就是调度的框架，Hadoop等都具有资源的调度能力。DCOS可以运行在任意的现代Linux环境，公有或私有云，虚拟机甚至是裸机环境。

在实际部署上Mesos-Master与Marathon还有ZK同节点部署，如上图所示，每一个组件都通过规则选举Leader，三者的Leader不一定同节点部署，只有Leader参与全流程。Slave节点单独部署并配置Docker环境，配置Docker环境意味着可以在该节点运行Docker，每一个Slave节点的物理资源是固定的。另外需要修改ZK的内容来保证Slave能够被Master发现和管理。这些节点可以是X86或者虚拟机。

（二）Mesos机制

在我们首先再回顾一下Mesos的运行机制，因为Mesos是整个DCOS的核心，下图中的Framework就可以是Marathon，ZK已在图中体现，Docker在Task里运行。

注：Resource offer(提供资源)、Launch task（开始任务）

Mesos是一个Master / Agent（Slave）的架构方式。Master负责资源的统一管理跟任务的分发；Agent负责起停执行器，汇报主机资源、执行器状态等信息；一般情况下，会启动3个以上Master，以确保高可用，Master的状态由ZooKeeper维护；Framerwork是Mesos上的调度框架，Marathon、Hadoop、Chonous都是比较常见的任务调度框架。

注：accept(接受)、decline（拒绝）

每一个Mesos-Agent都部署在一个节点上（可以是物理机也可以是虚拟机），Agent会把信息汇报给Master。调度器scheduler向Mesos-Master请求资源，Mesos-Master把所有可用的资源都反馈给Scheduler，Scheduler根据自己的规则决定该部署到哪一台。Master资源分配由Allocation（分配）插件完成。

因此Mesos机制里有两层的Scheduler，一层在Master里面，Allocator会将资源公平的分给每一个Framework，二层在Framework里面，Framework的Scheduler将资源按规则分配给Task。

（三）DCOS运行全流程视图

DCOS技术架构以容器为基础封装各类应用和运行环境，以Mesos+Marathon为核心实现容器资源的分布式调度与协调。

这一部分因为涉及DCOS全部运行的流程，我想了很久不知道怎么来描述，所以画了一张图，全景图，我决定先把这张图放出来，再分部分介绍。

这张图是假设的预想状态下，默认Mesos/Marathon/ZooKeeper已经全部部署在相应的节点上，Slave也已完成节点部署，所有节点完成了Docker环境配置，ZooKeeper相关设置完成。

图中的编号对应的就是下文介绍的系统流程，请结合下文内容看这张图：

注意：请将手机逆时针旋转至横屏阅读此图。

1、运行态系统流程

运行态系统流程是在预想状态的基础上完成Client通过Marathon启动Mesos拉起一个Docker运行起来。

这里强调一下Marathon是Mesos自带的调度框架，负责调度自有任务，尤其是长服务，但自有调度能力的平台例如Spark、Storm、Hadoop都是通过Mesos SDK直接调用Mesos不经过Marathon。如下图所示。

DCOS运行全流程图中描述的用Marathon作为调度框架的情况，运行态系统流程如下。

1-1：Mesos Slave节点向Master上报节点空闲资源。Master触发分配策略模块，得到Framework（Marathon）要请求的资源数量。

1-2：Master向Marathon Scheduler发送资源邀约，描述了Slave上的可用资源。

1-3： Marathon的调度器（Scheduler）响应Master，需要在Slave上运行两个任务数量及物理资源数量（需要运行几个Task，每个需要哪些资源）。

1-4：Master向Slave下发任务，分配适当的资源给Marathon的任务执行器（Executor）,接下来由执行器启动这申请的任务（Task）。

1-5：Marathon Executor申请拉起容器，首先服务请求发送至Docker的守护进行Deamon，守护进行生成image下载job。

1-6：job从镜像库Regisry中下载image存入Graph。

1-7：Deamon生成容器执行的job，通过网络Driver配置网络环境，通过执行Driver拉去Graph中的相关镜像到Container中运行。

这样容器中的应用就跑起来了。

一个标准的Docker容器包含一个软件组件及其所有的依赖 ，包括二进制文件、库、配置文件、脚本等。

2、开发态系统流程

开发态系统流程是在预想状态的基础上通过DevOps完成应用的持续集成与热发布（即时发布）。

这一部分过程不是该篇文章的重点，以后有机会的话会专门写一篇持续集成的文章，这个过程在这里简单概述一下。

2-1：开发将代码打包发布到GIT系统中，GIT是分布式版本控制系统，被用作源代码工具，具有GIT代码仓库。

2-2：代码通过打包及镜像构建到Jenkins持续集成系统中，并生成可以在Docker中运行的镜像包image。

2-3：imge镜像PUSH（上传）至Docker系统中的Registry，可以是公共库也可以是专用库。

2-4：新的应用服务向Mesos集群部署，通过Marathon拉起新的应用，新应用的拉起过程同第一部分开发态系统流程，在拉起Image的时候会拉起全新的镜像。

上述过程就是应用程序热发布过程，也叫灰度发布。

3、服务注册及引流

我认为想要理解这部分内容，必须理解负载均衡这个东西，因为DCOS的服务注册及发现都是由负载均衡实现的，所以先来讲讲负载均衡。

（1）负载均衡LB

负载均衡集群（Load Balancing）中有一个分发器或者叫调度器，我们将其称之为Director，它处在多台服务器的上面，分发器根据内部锁定义的规则或调度方式从下面的服务器群中选择一个以此来响应客户端发送的请求。

负载均衡的硬件有F5公司的BIG-IP系列、Citrix公司的NetScaler系列、A10公司的AX系列。软件包括中国人开发的四层LVS(Linux Virtual Server)及国外的七层nginx,HAProxy。

①四层模型：

②七层模型：

七层负载均衡器也称为七层交换机，位于OSI的最高层，即应用层，此时负载均衡器支持多种应用协议，常见的有HTTP、FTP、SMTP等。七层负载均衡器可以根据报文内容，再配合负载均衡算法来选择后端服务器，因此也称为“内容交换器”。比如，对于Web服务器的负载均衡，七层负载均衡器不但可以根据“IP+端口”的方式进行负载分流，还可以根据网站的URL、访问域名、浏览器类别、语言等决定负载均衡的策略。例如，有两台Web服务器分别对应中英文两个网站，两个域名分别是A、B，要实现访问A域名时进入中文网站，访问B域名时进入英文网站，这在四层负载均衡器中几乎是无法实现的，而七层负载均衡可以根据客户端访问域名的不同选择对应的网页进行负载均衡处理。常见的七层负载均衡器有HAproxy、Nginx等。

整个过程如上图所示。这里仍以常见的TCP应用为例，由于负载均衡器要获取到报文的内容，因此只能先代替后端服务器和客户端建立连接，接着，才能收到客户端发送过来的报文内容，然后再根据该报文中特定字段加上负载均衡器中设置的负载均衡算法来决定最终选择的内部服务器。纵观整个过程，七层负载均衡器在这种情况下类似于一个代理服务器。

（2）服务注册及负载均衡的系统流程

DCOS通过Haproxy、Confd（配置管理）、Etcd配合，实现应用的动态服务注册与引流，使用Etcd和confd实现DCOS内应用的服务自动注册与发现，配合使用Haproxy作为负载均衡器，实现应用的动态引流和负载均衡。

其中Etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现，HAProxy提供高可用性、负载均衡的解决方案。其主要的架构流程如下。

3-1：Marathon通过Mesos启动Docker容器时，Marathon将容器启动信息通知Etcd服务。Etcd服务将已经启动容器信息注册到Etcd键值库中。

3-2：Confd监测到Etcd中相关的服务变化。

3-3：Confd就会根据变化的情况更新Haproxy的cfg配置文件并执行重新加载命令，使相关变化生效，同样当容器停止时也会触发Haproxy更新cfg配置文件并重新加载，达到动态服务注册。

3-4：外部程序通过客户端进行服务的访问与调用，访问请求由LB服务转发。

3-5：程序访问调用请求通过HAProxy分发到Docker容器中的应用。这一步就是服务发现，找到应用实际部署的Docker以实现调用。

DCOS支持基于并发数、响应时间、CPU和内存使用率等容量指标进行自动弹性扩缩容调度的模块。通过结合HAProxy、Confd、Etcd动态服务注册和引流能力，实现应用的自动弹性扩缩容能力。

4、Mesos、Marathon、ZooKeeper选主

Mesos Master的Leader通过ZooKeeper中的集群管理功能实现，Marathon选主也是通过ZooKeeper实现，ZooKeeper的Leader选择依靠内部机制，具体流程在专栏文章中有详细介绍。

5、DCOS物理部署

DCOS一般部署在x86服务器的虚拟机上面，如上图示意，Mesos Master集群由一定数量节点构成，Mesos Master Cluster部署了Master、Marathon、ZooKeeper，一定数量节点构成Haproxy Cluster。计算节点也就是Slave节点一般数量较多，部署了Docker环境并更新了ZooKeeper的相关配置。平台和计算节点可采用同机房或者均跨机房部署。

  公众号相关文章  

请长按扫码关注

---

通信互联网笔记——易懂的通信IT知识共享平台

点 “阅读原文” 查看系统架构已发文章列表