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

上一篇 从项目开发到云端架构(16)  ：http://timeson.iteye.com/blog/1702881

下一篇 从项目开发到云端架构(18)  ：http://timeson.iteye.com/blog/1717288