Copyright 2015, Baidu, Inc.
Galaxy是一个数据中心操作系统，目标是最大化资源的利用率与降低应用部署运维代价。
#Galaxy 3.0设计
Galaxy3.0是对Galaxy2.0的重构，主要解决以下问题：
- 容器管理和服务管理紧耦合：服务的升级和启停都伴随容器的销毁和调度；
- 没有磁盘管理，只能管理home盘；
- 不支持用户quota和记账；
- 机器管理功能缺失；
- Naming功能可用性低；
- Trace功能不完善；
Galaxy3.0架构上分为2层： 资源管理层和服务管理层，每层都是主从式架构
1. 资源管理层由ResMan(Resource Manager)和Agent构成
2. 服务管理层由AppMaster和AppWorker构成;
+-------------------+-----------------------------+
| | | |
| | MapReduce | Spark |
| | | |
| +-----------------------------+
| |
| Service Management | ---> {AppMaster + AppWorkers}
| |
+-------------------------------------------------+
| |
| Resource Management | ---> {ResMan + Agents}
| |
+-------------------------------------------------+
组件： ResMan + Agents
一个Galaxy集群只有一个处于工作状态的ResMan，负责容器的调度，为每个容器找到满足部署资源要求的机器；
ResMan通过和部署在各个机器上的Agent通信，来创建和销毁容器；
容器： 一个基于linux cgroup和namspace技术的资源隔离环境；
容器里默认会启动AppWorker进程，是容器内的第一个进程，也就是根进程；
ResMan不暴露给普通用户接口， 仅供内部组件以及集群管理员使用；
组件： AppMaster + AppWorkers
AppMaster是外界用户操作Galaxy的唯一入口；
一个Galaxy集群通常只有一个AppMaster，负责服务的部署、更新、启停和状态管理，把服务实例分发到各个机器上的容器内启动并跟踪状态；
AppMaster通过调用ResMan的RPC接口创建容器，容器内自动拉起AppWorker进程；
容器内的AppWorker进程通过和AppMaster进程通信，获得需要在容器内执行的命令，包括部署、启停、更新等等；
AppWorker会汇报服务的状态给AppMaster，例如托管的服务是否在正常运行，进程退出码等；
用户提交的Job内容主要是两部分：资源需求 + 程序描述
资源需求： CPU核数、内存大小、磁盘容量、机器Lable、端口范围、mount路径
程序描述： 部署命令、启动命令、停止命令、更新命令、版本号
ResMan通过定时查询Agent，获得每个Agent上面可分配的资源
ResMan不断检查当前是否有处于Pending状态的容器， 寻找有资源的Agent创建容器；
创建失败的容器，又进入Pending状态，等待重新调度；
不符合预期的容器， ResMan命令Agent销毁， 重新进入Pending状态；
ResMan确保容器的个数始终符合用户的需求；
AppMaster等待AppWorkers的定时汇报；
如果AppWorker汇报的服务状态不符合AppMaster的预期，则AppMaster返回一些命令让AppWorker执行；
a) 部署： AppWorker汇报目前没有运行任何服务， AppMaster返回部署命令给AppWorker;
b) 启动： AppWorker汇报部署成功了， AppMaster返回启动命令给AppWorker;
c) 更新： AppWorker汇报当前服务的版本号， AppMaster发现不匹配， 返回更新命令给AppWorker;
d) 失败处理： AppWorker汇报（部署失败 or 启动失败 or 更新失败）， AppMaster记录此次异常，并根据策略决定是否让AppWorker继续重试；
- ResMan，AppMaster都有备份，通过Nexus抢锁来Standby;
- Agent跟踪每个容器的状态汇报给ResMan，当容器个数不够或者不符合ResMan的要求时，就需要调度：创建或删除容器；
- AppWorker负责跟踪用户程序的状态，当用户程序coredump、异常退出或者被cgroup kill后，反馈状态给AppMaster，AppMaster根据指定策略命令AppWorker是否再次拉起用户的服务；
- 由于机器缺陷或者网络分割，可能导致ResMan认为容器个数足够，但是AppMaster发现服务实例数不够的情况：
例如： 磁盘坏了、端口被占用等， 导致用户服务始终无法拉起；
这种情况下， AppMaster可以调用ResMan的接口，增大容器个数（有上限）；
- SDK通过Nexus发现AppMaster地址；
- SDK请求AppMaster，发现每个Job实例的地址和当前的服务状态；
- AppMaster会定时同步服务地址和状态到第三方Naming系统（如BNS,Nexus,ZK等);
- SDK通过Nexus发现指定的Job的AppMaster地址；
- SDK请求AppMaster, AppMaster将服务更新命令传播给AppWorker, AppWorker将更新状态反馈给AppMaster;
- AppWorker和AppMaster的通信方式是Pull的方式，因此AppMaster可以根据当前的情况来决定部署的暂停和步长控制；
- 服务的更新都在容器内进行，不涉及到容器的销毁和创建
- 集群（Cluster）：共用同一ResMan的host/agent及服务
- 机器池（Pool）： 一个host/agent只能属于一个机器池，一个机器池通常有很多host/agent。一个集群中可能有多个机器池。机器池用于资源及环境的硬隔离， 也是权限分配的单位。
- 用户（User）：galaxy用户
- 权限（Authority）：某用户在某机器池上具有的某种操作权限，如对Job的增、删、改、查权限等。用户可以同时对多个机器池具有多项权限。
- 配额（Quota）：配额是对用户在集群中拥有资源量的描述， 包含cpu配额，内存配额， 磁盘空间配额，可提交任务数量配额等。用户的配额和具体的机器池没有关系。
- 标签（label）： 标签一般用来表征一批拥有某种特征的机器，标签和机器是多对多的关系。有权限的用户可以对机器池中的机器打标签，提交任务时可指定标签。
- Nexus作为寻址和元信息保存
- MDT作为用户日志的Trace系统
- Sofa-PbRPC作为通信基础库
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent