场景引入

要实现好一个系统，第一步就是分析问题，明确要实现一个什么样的目标。简单的业务模型如下，一个用户通过前端应用（或者web），访问到后端某台服务器，然后由服务器上的应用服务对其进行服务。这里的服务可以是查询一条记录，写入一个文件等等，总之是为用户提供的某种功能。

左边图这个模型是一个简单业务模型，用户访问服务器。如果访问的用户增加，这时有两种方式扩展。一种是垂直扩展，提升服务器的硬件性能，这种方式通常简单快速，对程序本身也没有冲击，缺点是容量的增加与成本是指数级增加的（比如8G内存条与64G内存条的价格并不是8倍关系，越大容量的价格不是按容量的增加而增长）；另一种是水平扩展，这种扩展就需要有一些开发工作，让多个服务器对外服务，相应的程序复杂度也出现了。

上面左边图中，用户访问三台不同的服务器，以缓解单台服务器的压力。这样相对于第一种情况能成倍的提高对外服务数量。不过左图还有一个缺点就是对外发布的程序（客户端）都是一个固定地址，也就是用户并不知道自己该访问哪一台服务器。所以通常做法是访问一台固定服务器（反向代理服务器），由这台服务器选择一个后端服务器进行服务。这样用户始终是访问的一个地址，而不用知道后端有哪些机器。这样一个基本形态就出来了

分析问题

在上面介绍了基本的业务流程，本文所关心的是服务器端如何去组成一个高效可用的集群，怎么将所有的服务器组织起来，也是上面图中对应的服务端集群部分。

目标是期望有一个统一的地方，来管理所有的节点。比如，我需要在某台服务器重启，需要在某台服务器上启动一个httpd服务等等，所有对服务器功能的操作都属于管理操作。

这里需要对服务器进行一层抽象，为每个节点上设计一个代理服务agent，然后由一个管理服务manager去调用agent服务。这种分层结构的好处在于，能将逻辑操作和实际操作分开。每一层中包含有不同模块，manager中的模块可能由agent中几个模块构成，然后调度指定节点的agent模块完成功能。

下面针对一个简单功能开始，后面进阶内容再开始扩展。下图是整体系统的分层结构，里面包含了几个简单模块：

最下面一层是节点，也就是物理设备；

再往上一层就是代理层服务，代理层服务运行在每个节点上，用于对每个节点上做具体操作；

最上面一层是逻辑调用层，逻辑调用层通过调用指定节点上的不同模块Agent来完成功能；

逻辑层旁边是中心数据库，用于存储整个系统的信息，属于系统核心；

边界&约束

对于上面的模型还有一点重要的是，明确各层次，模块的边界和约束。也即是定义一个操作规范。