PAAS平台7×24小时可用性应用设计

如今非常多企业都在搭建自己的私有PAAS平台，当然也有非常多大型互联网公司搭建共同拥有PAAS平台（比如SAE/BAE/JAE(jae.jd.com)）。那么使用PAAS平台来部署SAAS应用有哪些优点呢？除了大家都知道方便部署管理，节约资源和成本，今天我主要给大家介绍还有一个优点就是让部署在PAAS平台上的应用非常easy做到7×24小时不server执行（哪怕须要又一次部署和更新应用），这个对于一般的企业和普通开发人员来说是非常难办到的。当然假设要在PAAS平台做到事实上也不是那么简单的。须要非常强的技术力量。以下就主要介绍一下在PAAS平台如何实现让部署在PAAS平台上的应用达到7×24小时执行的方案。

在介绍方案设计之前须要强调一下，这个前提是PAAS平台本身是7×24小时高可靠的。

本方案设计主要涉及以下几方面的改进：

（1）应用执行调度模块：能够将应用的多个实例调度到不同的server和机架上进行执行;

（2）应用执行状态的监控模块：相应用的执行状况进行监控;

（3）优雅重新启动应用模块：能够在应用又一次部署和升级时不停服务;

一，首先我们来看看调度模块

调度模块应该是PAAS平台（无论是私有还是共同拥有的）标配，仅仅是不同的PAAS平台有自己特色的调度方法和策略，比如依据server资源使用来调度（这个里面有涉及到各种资源的调度。比如依据CPU或者内存等），或者依据部署的应用个数来调度。

当然好的调度策略绝对不仅仅使用一种评判标准来作为调度的策略，肯定是结合各种情况考虑。由于今天主要介绍的是应用的高可靠性，所以主要介绍如何通过调度算法保证应用的高可靠性。

假如应用为了提高自己的服务能力和可靠性执行了3个实例。那么怎么的调度算法是最佳的（仅仅针对高可靠性这一点来说的）？我们都知道设计一个高可靠性系统都会考虑到server出问题和网络（交换机）出问题。所以调度模块为了保证这个应用的高可靠性应该须要保证这三个实例应用不在同一个server上执行，同一时候保证三个实例不应该在同一个机架下执行，当然假设有条件的PAAS平台能够考虑跨数据中心调度（只是应该没有几个PAAS平台能够做到跨数据中心部署PAAS平台上的应用）。

要做到上面说的调度结果。调度模块应该能够知道全部部署应用的server的部署情况，或者至少能够通过某种方法查询到。我相信全部的PAAS都应该有资源管理模块（或者叫做PAAS平台的server监控模块）能够提供这些信息。除了知道server的部署情况，调度模块应该还须要能够知道或者查询到某一个应用实例执行在哪一台server上，由于仅仅有这样调度模块才干够保证不会把后面的实例调度到同一个server上。比如应用启动三个实例，已经启动2个实例了。还须要启动第三个实例。那么调度模块启动第三个实例之前须要知道其它连个实例执行的server和机架，这样才干保证把第三个实例调度到其它机架上去执行。相同假设应用执行的三个实例，突然某个时候其中一个实例挂掉了，那么须要把第三个实例又一次执行起来，还是须要使用调度模块来完毕不同server和不同机架的调度。至于调度模块怎么知道挂掉了一个实例。这个不是调度模块关心的事情。以下介绍的应用执行状态监控模块会非常好的解决问题。

二，应用执行状态的监控模块

打造7×24小时高可用的应用，假设连应用执行的状态都不知道，还怎么谈做到7×24小时的执行。说的简单一点，应用执行状态的监控模块就是实时的监控应用各个实例的执行状态（存活还是挂掉了）。然后依据监控的结果进行兴许处理。

监控模块须要达到的结果非常简单：就是应用的执行状态和用户期望的执行状态是否一致。

比如用户期望这个应用是执行的，可是此时执行状态却是挂掉的。肯定是不合理的，又比如用户期望此时不想对外提供服务了，希望应用是停止执行的，可是假设应用还是在执行也是不合理的。再比如用户期望应用眼下应该是须要执行三个实例的。可是仅仅有两个实例执行，也是没有满足用户需求的。

监控模块就是发现这些和用户期望不一致的情况。并处理。

那么如何做？以下我就结合开源PAAS平台cloudfoundry的解决方式来介绍应用执行状况的监控模块的方案设计，cloudfoundry眼下为止已经将原来的ruby版单进程单点监控模块改造成了go版高可靠多进程的监控模块。预知详情请到官方站点查询相关资料。今天主要结合最新版本号的监控模块来介绍怎么设计监控模块：

最新版本号的cloudfoundry的应用执行状态监控模块又划分为非常多的子模块，每个子模块都能够执行一个主进程和多个备进程进行高可靠部署（这些进程能够部署在不同的server和机架上。仅仅要网络能够通）。

首先须要获取每个应用的用户期望状态。那么我们就须要单独一个模块来获取这些用户的期望状况。而且把这些状态存储在某一个地方（共享存储，cloudfoundry使用的etcd）以便其它模块使用。

当然用户期望的状态通常存放在数据库其中，这个用户期望状态的获取模块能够通过直接读取数据库或者通过其它服务模块得到。

这个模块相应cloudfoundry的hm9000中的fetch_desired模块。

用户期望的执行状态有了，那么就还须要应用真实的执行状态，那么这个状态怎么来获取了。这个模块就叫做应用真实状态获取模块，相同将获取的数据存放到共享存储上。有两种方案能够获取。一种是主动去获取全部应用的执行状态，通常就是去訪问应用提供的一个服务。另外一种方案就是全部应用定时上报心跳，假设没有即使上报就觉得应用执行状态有问题了。

cloudfoundry採用的另外一种方案，只是它不是应用自己上报。而是管理一台server上全部应用的组件（dea）统一上报这台server全部应用的心跳。

这个模块相应cloudfoundry的hm9000中的listen模块。

用户期望的状态和应用真实状态都有了，那么我们就能够開始分析了，究竟哪些应用的执行状态和用户期望的执行状态不一致了。

然后将分析的结果相同存放在共享存储上，后面其它模块会使用这个分析结果的数据。这个模块相应cloudfoundry的hm9000中的analyze模块。

我们都知道了哪些应用的状态和用户期望的状态不一致。那么我们就能够把这些不一致的应用让他们一直。这就须要一个模块专门来给调度模块发送调度命令。比如用户期望应用是执行的，可是真实的状态是这个应用挂掉了，那么这个模块就能够发送一个调度命令让调度模块把这个应用启动起来。相同假设用户期望停止，假设应用是执行的那么就发送调度命令让这个应用停止掉。还有执行实例少了就在多调度一个起来。执行实例多了就停止掉多余的实例。这个模块相应cloudfoundry的hm9000中的send模块。

通过上面的4个模块基本上完毕了应用执行状态监控模块，而且维护了应用执行状态不一致的应用。

当然cloudfoundry的hm9000还提供了其它工具模块，感兴趣能够自己去深入研究。

三。最后一个模块就是优雅重新启动模块

为什么须要这一个模块呢？由于不论什么一个应用都不可能不更新，除非废掉的应用。那么更新这个应用的时间可大可小。那么由于更新期间导致应用不可用时间也服务预计。当然更加达不到题目所说的打造7×24小时的高可用应用了。

事实上这个模块是最简单的，可是达到的效果也是最明显的。只是也正是PAAS平台的特性才easy完毕。由于PAAS平台的应用更新和执行是两个分离的任务。我们全然能够一边更新应用一边继续让应用提供服务。而且在新更新应用没有全然能够提供服务曾经一直让老服务继续提供服务。全然不影响应用对外提供的服务。

这个模块实现还须要通过调度模块来完毕。在应用更新期间，我们一直让曾经执行的实例继续执行。一直到更新的应用已经正常执行了，才停止掉老的执行实例。这些启动或者停止动作都交给调度模块完毕，这个模块主要就是控制逻辑就能够了。

上面介绍的模块有一个缺点就是在新应用启动成功并对外提供服务以后去停止老实例的时候，用户可能感受到不一致的服务状态。由于在老实例还没有全然停止掉曾经可能还有请求达到实例，可是又可能偶尔到新实例，由于新老实例可能同一时候存在一个非常小的时间段，只是这对大部分应用应该是能够忽略的。

假设你全然不能忍受这短暂的不一致状态，那么还能够在路由那一块做。保证用户请求到达要么全部到老实例要么全部到新实例，详细做法就是新实例和老实例的路由地址不会同一时候存在路由程序的路由表里面。

第四，总结

通过上面的三种模块的设计基本上能够打造7×24小时的应用了。尽管方案设计完毕了，可是真正的实施了还会遇到非常多意料不到的情况，要正在打造7×24小时的应用执行环境还须要非常多其它方面的考虑。比方说每个模块执行的稳定性，假设应用执行状态监控模块都挂挂了还怎么启动应用程序。所以，好项目还需要好的做法，通过对调整方案的做法。