从项目开发到云端架构 17

 5.2 基本PaaS

       如前所述，采用脚本模式，就像众多的奴隶为一个宏伟的工程而服务，如果以cc的成熟度和人类历史发展的阶段来映射，可以说是处于奴隶社会，虽然效率底下，但按部就班去实现，宏伟的金字塔依旧能建立。    运维人员就像奴隶一般，每天需要对系统进行运维和调整，编写和改进脚本，根据反馈的数据进行自我分析和判断。

       人类的历史是有客观规律的，从低级阶段到高级阶段的发展，那对云端平台的理解和深入，也可以借鉴这种模式，我们对最基础的云端进行分解，庖丁解牛，用自己的双手DIY一套系统。这里总结一下所需的PaaS的功能：

1. 提供按需索取的硬件和操作系统服务；

2. 提供了应用程序平台和解决方案栈；

3. 减少IT部署的开销和痛苦；

4. 按需为应用程序提供资源；

5. 让其更易伸缩。

总结的说，就是3点：对应用的管理，对服务的管理，对自身的管理。

5.2.1 架构和组件

       完成一个基本型paas需要什么呢？支持简单架构的包部署（单一WAR包），支持tomcat和mysql，并提供缺省的route。为了不修改程序，可以在route设定为粘性路由方式。具体功能如下：

1.  应用的管理：提供tomcat/jetty；支持war的打包上传；自动生成脚本，并执行。

2.  服务的管理：提供mysql；支持服务的生命周期；只是服务和应用的绑定。

3. 自身的管理：提供状态查询，系统监控，提供缺省模式的路由分配。

图52-01 基本型paas平台（部署模式）

    这里只提供了部署模式，而没有系统架构的图，是因为在基本型Paas平台，很多处理是采用脚本处理方式，至于上传和监控模块，都是传统的web程序，容易理解。

       从基本型paas平台的部署图里，分解为4个部分：前面是路由，用来作负载均衡用的；下面分别是service池和apps池，分别用来承载mysql服务器和tomcat/jetty应用服务器的；在这里最关键是paas管理器，包括上传，配置，模板管理，部署管理，监控，为了paas平台内部的信息和状态能持久，外加数据库。

上传管理

1.  提供上传的界面，war包上传，并设定一些参数，如果按照最简单的方式，可以提供一些选项或者是下拉框，填入2级域名和web实例的个数等。

配置管理

1. 接手到的war包，解压，根据配置的mysql的名称，改写war包中相应的xml文件，

2. 并为上传的war提供一些脚本，脚本可以是生成的，也可以是用户上传的，最简单的脚本包括应用和服务的start和stop功能，并能被执行，执行后，设置状态和id，并用一个界面提供用户查询。

3. 还需要改写route的信息，这样当应用是多个实例的时候，通过route能方便的把http请求拆分到多台apps上，实现负载均衡功能。

模板管理

1. 提供tomcat/jetty以及mysql服务的模板。Tomcat是基于java的，mysql基于c的，分别需要为他们定制模板，在需要新服务的时候，只需要copy即可。

2. 假设操作系统（由物理机或者虚拟机提供，不在paas内管理）安装的时候有个缺省环境，有统一的用户和JDK，tomcat的安装只需要复制tomcat即可，多少份都可，可以设定复制规则，比如每个vm中可复制3个tomcat，每个512m-1024m的内存容量，至于是tomcat6，还是tomcat7，可以根据用户的要求做不同的复制。

3.  对于mysql稍微复杂一些，因为是c的，需要在linux上部署，会依赖于linux的虚拟机的安装；还有一种方式，对于测试或者验证方式的，可以在一台mysql上开启不同的用户。

部署管理

1. 因为涉及到虚拟机或者物理机的部署，这里会涉及到iaas，在paas层，是不处理虚拟机的处理。在这里不区分虚拟机和物理机。

2. 前端需要有一个route层，route用来处理前端请求的分发的，route的前端有个负载均衡的作用，可以是硬件或软件，在这里假设采取的都是nginx，作为分发和均衡器。

3. 如果没有iaas平台的支撑，就假设apps池/service池所在的物理机/虚拟机已经搭建好了，只是服务的启动需要脚本来控制，脚本启动后，触发状态的变化，由配置管理模块修改paas平台的apps和servcie的状态。

4. 如果底层基于iaas层，或者基于kvm的模式，可以由脚本或者iaas的api进行处理。

监控管理

1. 监控模块在这里会做的比较简单，因为是基本型的嘛。但也包括2块内容：

2. Apps和services的状态监控，查看哪些应用和服务是启动了，以及状态等

3. 如果在每个vm或者物理机上安装了agent，就可以查看到vm的内存，cpu，jvm等。

4. 如果脚本强大，还可以有启动启动tomcat或者自动添加减少tomcat的实例脚本，自然在变动tomcat实例的同时，也需要修改前端route的信息。

5.2.2 业务流程

       掰完了基本型paas平台的结构和关键组件，在这里推演一个典型的流程，检验一下基本型paas平台是否能支撑呢。劳苦的程序员经过了一个项目的生命周期，好不容易把项目发布出来了，打成了一个war包，程序是mvc+servcie+dao实现的，采用的是spring+mybaits模式，采用的是连接池模式，采用的是mysql，配置信息写在了某个xml文件中。

1.  打开“PAAS平台管理器”，上传war包，并设定如下参数：2级域名，3个tomcat实例，mysql实例1个，设定mysql用户名和密码。

2. "PAAS平台管理器"创建根据模板并设定用户名和用户，启动1个新的mysql实例，纪录好ip地址，端口等信息。修改paas状态。

3. “PAAS平台管理器”启动3个tomcat实例，分别编号：server01-tomcat01，server01-tomcat02，server01-tomcat03，修改paas状态。

4. "PAAS平台管理器”把上传的war包解压，并根据mysql的配置信息，改写相应的xml文件信息，并分别copy到3个tomcat指定的目录下。

5. “PAAS平台管理器”分别启动3个tomcat实例，并修改nginx的配置信息，生效请求转发，并修改状态。

6.   大家就可以通过域名或地址来使用刚才发布的应用了。

5.2.3 实现方式

       前面用精神开拓了视野，用思想武装了头脑，那么现在我们就开工了，首先需要一些硬件，软件，以及网络设备，清单如下：

图52-02 基本型paas平台的物理部署

整个系统分为管理节点，计算节点和路由节点。

1.  路由节点：实现2级域名的定向和请求的分派

2.  计算节点：Service pool和apps pool里面的机器都是计算节点，假设都是由vm组成，如果是db池，每个vm启动一个mysql的实例，缺省不启动；如果是apps池，每个vm安装统一的jdk，允许启动3个jvm，并部署好tomcat实例，可使用统一的文件系统。缺省不启动。

3.  管理节点：管理节点是整个系统的核心，包括数据库，以及存储服务模板和应用模板。这里的数据库是提供管理节点使用，用来存储整个管理系统的中间状态和元数据信息。

关键的数据

1.  基础数据：包括ip地址，servcie id/apps id和ip的对应关系，2级域名对应的ip等

2.  状态数据：服务和应用的当前状态，通过agent定时更新信息。

3.   历史信息：服务和应用的状态轨迹，用户处理的信息，动作的处理等

核心的软件

1.  执行脚本：服务和应用的预设脚本，典型的有start/stop。

2.  上传模块：和用户交互的接口，获取war包，并得到用户设定的参数，典型的有mysql的id和需要启动的服务实例个数。

3.  配置模块：把war解压，根据配置信息改写相应配置文件，并分别复制到相应的apps节点。

4.  网络端口：节点机器端口和网络都需要彼此开放，相应的用户和权限开启

       在此基础上，采用负载均衡，以及合理使用缓存，业务应用作合适的分离部署，来提高系统的性能。图52-03是个具备一定功能Paas平台的示意图，不但管理了通用服务的生命周期，也管理到了通用业务的开发到部署的阶段，建议和之前“图23-01”配合起来理解。

       这里通过结合svn，jenkins以及测试的手段，规范测试流程，形成了整套的开发＋部署的平台，后台采用脚本＋代码，再用页面把各个功能组合起来，形成统一体。这种方式也是业界的发展趋势，从之前的cloudbees，到现在的openshift云端平台，均提供了从开发到部署的模式，可以看到这种结合devops能力的paas平台代表了业界新的发展方向。

图52-03 ：具有devops功能的Paas平台结构

       这里对基本paas作了个思路上的概述，没有涉及到具体的设计上，因为在《从项目开发到云端架构》文档里，主要是把概念和思路梳理清楚，因为每个人的认识和对云端的感知不一样，有自己的理解和思想，从开源软件的多样性就得知，从来没有绝对最好的，只有自己根据实际情况选择或者去实现最合适的，如何去作，仁者见仁智者见智，在心目中每个人都是架构师，都有自己的体会和认识。在下一篇《云端平台的设计和实现》中我按照自己的思路和想法，会更详细的描述和设计云端平台，让我们在云里雾里来一睹云端平台的风采。 ；）

来源：timeson http://timeson.iteye.com/blog