PAAS平台构建实时高可用应用的方案设计（7×24小时）

问题导读
1.本方案设计主要涉及下面哪几方面的改进?
2.应用运行调度模块能够完成什么事情？
3.重启应用模块的作用是什么？

现在很多企业都在搭建自己的私有PAAS平台，当然也有很多大型互联网公司搭建共有PAAS平台（例如SAE/BAE/JAE(jae.jd.com)）。那么使用PAAS平台来部署SAAS应用有哪些好处呢？除了大家都知道方便部署管理，节约资源和成本，今天我主要给大家介绍另一个好处就是让部署在PAAS平台上的应用很容易做到7×24小时不服务器运行（哪怕需要重新部署和更新应用），这个对于一般的企业和普通开发者来说是很难办到的。当然如果要在PAAS平台做到其实也不是那么简单的，需要很强的技术力量。下面就主要介绍一下在PAAS平台怎样实现让部署在PAAS平台上的应用达到7×24小时运行的方案。

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

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

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

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

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

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

调度模块应该是PAAS平台（不管是私有还是共有的）标配，只是不同的PAAS平台有自己特色的调度方法和策略，例如根据服务器资源使用来调度（这个里面有涉及到各种资源的调度，例如根据CPU或者内存等），或者根据部署的应用个数来调度。当然好的调度策略绝对不只使用一种评判标准来作为调度的策略，肯定是结合各种情况考虑。因为今天主要介绍的是应用的高可靠性，所以主要介绍怎样通过调度算法保证应用的高可靠性。假如应用为了提高自己的服务能力和可靠性运行了3个实例，那么怎么的调度算法是最佳的（仅仅针对高可靠性这一点来说的）？我们都知道设计一个高可靠性系统都会考虑到服务器出问题和网络（交换机）出问题，所以调度模块为了保证这个应用的高可靠性应该需要保证这三个实例应用不在同一个服务器上运行，同时保证三个实例不应该在同一个机架下运行，当然如果有条件的PAAS平台可以考虑跨数据中心调度（不过应该没有几个PAAS平台能够做到跨数据中心部署PAAS平台上的应用）。

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

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

打造7×24小时高可用的应用，如果连应用运行的状态都不知道，还怎么谈做到7×24小时的运行。说的简单一点，应用运行状态的监控模块就是实时的监控应用各个实例的运行状态（存活还是挂掉了），然后根据监控的结果进行后续处理。监控模块需要达到的结果很简单：就是应用的运行状态和用户期望的运行状态是否一致。例如用户期望这个应用是运行的，但是此时运行状态却是挂掉的，肯定是不合理的，又例如用户期望此时不想对外提供服务了，希望应用是停止运行的，但是如果应用还是在运行也是不合理的，再例如用户期望应用目前应该是需要运行三个实例的，但是只有两个实例运行，也是没有满足用户需求的。监控模块就是发现这些和用户期望不一致的情况，并处理。

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

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

首先需要获取每一个应用的用户期望状态，那么我们就需要单独一个模块来获取这些用户的期望状况，并且把这些状态存储在某一个地方（共享存储，cloudfoundry使用的etcd）以便其他模块使用。当然用户期望的状态通常存放在数据库当中，这个用户期望状态的获取模块可以通过直接读取数据库或者通过其他服务模块得到。这个模块对应cloudfoundry的hm9000中的fetch_desired模块。

用户期望的运行状态有了，那么就还需要应用真实的运行状态，那么这个状态怎么来获取了，这个模块就叫做应用真实状态获取模块，同样将获取的数据存放到共享存储上。有两种方案可以获取，一种是主动去获取所有应用的运行状态，通常就是去访问应用提供的一个服务，第二种方案就是所有应用定时上报心跳，如果没有即使上报就认为应用运行状态有问题了。cloudfoundry采用的第二种方案，不过它不是应用自己上报，而是管理一台服务器上所有应用的组件（dea）统一上报这台服务器所有应用的心跳。这个模块对应cloudfoundry的hm9000中的listen模块。

用户期望的状态和应用真实状态都有了，那么我们就可以开始分析了，到底哪些应用的运行状态和用户期望的运行状态不一致了。然后将分析的结果同样存放在共享存储上，后面其他模块会使用这个分析结果的数据。这个模块对应cloudfoundry的hm9000中的analyze模块。

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

通过上面的4个模块基本上完成了应用运行状态监控模块，并且维护了应用运行状态不一致的应用。当然cloudfoundry的hm9000还提供了其他工具模块，感兴趣可以自己去深入研究。

三，最后一个模块就是优雅重启模块

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

其实这个模块是最简单的，但是达到的效果也是最明显的，不过也正是PAAS平台的特性才容易完成。因为PAAS平台的应用更新和运行是两个分离的任务，我们完全可以一边更新应用一边继续让应用提供服务，并且在新更新应用没有完全能够提供服务以前一直让老服务继续提供服务，完全不影响应用对外提供的服务。

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

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

如果你完全不能忍受这短暂的不一致状态，那么还可以在路由那一块做，保证用户请求到达要么全部到老实例要么全部到新实例，具体做法就是新实例和老实例的路由地址不会同时存在路由程序的路由表里面。

第四，总结

通过上面的三种模块的设计基本上能够打造7×24小时的应用了，虽然方案设计完成了，但是真正的实施了还会遇到很多意料不到的情况，要正在打造7×24小时的应用运行环境还需要很多其他方面的考虑，比如说每一个模块运行的稳定性，如果应用运行状态监控模块都挂掉了还怎么启动挂掉的应用。所以好的方案还需要好的实践，通过实践调整方案。