5.2 基本PaaS
如前所述,采用脚本模式,就像众多的奴隶为一个宏伟的工程而服务,如果以cc的成熟度和人类历史发展的阶段来映射,可以说是处于奴隶社会,虽然效率底下,但按部就班去实现,宏伟的金字塔依旧能建立。 运维人员就像奴隶一般,每天需要对系统进行运维和调整,编写和改进脚本,根据反馈的数据进行自我分析和判断。
人类的历史是有客观规律的,从低级阶段到高级阶段的发展,那对云端平台的理解和深入,也可以借鉴这种模式,我们对最基础的云端进行分解,庖丁解牛,用自己的双手DIY一套系统。这里总结一下所需的PaaS的功能:
-
提供按需索取的硬件和操作系统服务;
-
提供了应用程序平台和解决方案栈;
-
减少 IT 部署的开销和痛苦;
-
按需为应用程序提供资源;
-
让其更易伸缩。
总结的说,就是3点:对应用的管理,对服务的管理,对自身的管理。
5.2.1 架构和组件
完成一个基本型paas需要什么呢?支持简单架构的包部署(单一WAR包),支持tomcat和mysql,并提供缺省的route。为了不修改程序,可以在route设定为粘性路由方式。具体功能如下:
-
应用的管理:提供 tomcat/jetty ;支持 war 的打包上传;自动生成脚本,并执行。
-
服务的管理:提供 mysql ;支持服务的生命周期;只是服务和应用的绑定。
-
自身的管理:提供状态查询,系统监控,提供缺省模式的路由分配。
图52-01 基本型paas平台(部署模式)
这里只提供了部署模式,而没有系统架构的图,是因为在基本型Paas平台,很多处理是采用脚本处理方式,至于上传和监控模块,都是传统的web程序,容易理解。
从基本型paas平台的部署图里,分解为4个部分:前面是路由,用来作负载均衡用的;下面分别是service池和apps池,分别用来承载mysql服务器和tomcat/jetty应用服务器的;在这里最关键是paas管理器,包括上传,配置,模板管理,部署管理,监控,为了paas平台内部的信息和状态能持久,外加数据库。
上传管理
-
提供上传的界面, war 包上传,并设定一些参数,如果按照最简单的方式,可以提供一些选项或者是下拉框,填入 2 级域名和 web 实例的个数等。
配置管理
-
接手到的 war 包,解压,根据配置的 mysql 的名称,改写 war 包中相应的 xml 文件,
-
并为上传的 war 提供一些脚本,脚本可以是生成的,也可以是用户上传的,最简单的脚本包括应用和服务的 start 和 stop 功能,并能被执行,执行后,设置状态和 id ,并用一个界面提供用户查询。
-
还需要改写 route 的信息,这样当应用是多个实例的时候,通过 route 能方便的把 http 请求拆分到多台 apps 上,实现负载均衡功能。
模板管理
-
提供 tomcat/jetty 以及 mysql 服务的模板。 Tomcat 是基于 java 的, mysql 基于 c 的,分别需要为他们定制模板,在需要新服务的时候,只需要 copy 即可。
-
假设操作系统(由物理机或者虚拟机提供,不在 paas 内管理)安装的时候有个缺省环境,有统一的用户和 JDK , tomcat 的安装只需要复制 tomcat 即可,多少份都可,可以设定复制规则,比如每个 vm 中可复制 3 个 tomcat ,每个 512m-1024m 的内存容量,至于是 tomcat6 ,还是 tomcat7 ,可以根据用户的要求做不同的复制。
-
对于 mysql 稍微复杂一些,因为是 c 的,需要在 linux 上部署,会依赖于 linux 的虚拟机的安装;还有一种方式,对于测试或者验证方式的,可以在一台 mysql 上开启不同的用户。
部署管理
-
因为涉及到虚拟机或者物理机的部署,这里会涉及到 iaas ,在 paas 层,是不处理虚拟机的处理。在这里不区分虚拟机和物理机。
-
前端需要有一个 route 层, route 用来处理前端请求的分发的, route 的前端有个负载均衡的作用,可以是硬件或软件,在这里假设采取的都是 nginx ,作为分发和均衡器。
-
如果没有 iaas 平台的支撑,就假设 apps 池 /service 池所在的物理机 / 虚拟机已经搭建好了,只是服务的启动需要脚本来控制,脚本启动后,触发状态的变化,由配置管理模块修改 paas 平台的 apps 和 servcie 的状态。
-
如果底层基于 iaas 层,或者基于 kvm 的模式,可以由脚本或者 iaas 的 api 进行处理。
监控管理
-
监控模块在这里会做的比较简单,因为是基本型的嘛。但也包括 2 块内容:
-
Apps 和 services 的状态监控,查看哪些应用和服务是启动了,以及状态等
-
如果在每个 vm 或者物理机上安装了 agent ,就可以查看到 vm 的内存, cpu , jvm 等。
-
如果脚本强大,还可以有启动启动 tomcat 或者自动添加减少 tomcat 的实例脚本,自然在变动 tomcat 实例的同时,也需要修改前端 route 的信息。
5.2.2 业务流程
掰完了基本型paas平台的结构和关键组件,在这里推演一个典型的流程,检验一下基本型paas平台是否能支撑呢。劳苦的程序员经过了一个项目的生命周期,好不容易把项目发布出来了,打成了一个war包,程序是mvc+servcie+dao实现的,采用的是spring+mybaits模式,采用的是连接池模式,采用的是mysql,配置信息写在了某个xml文件中。
-
打开“ PAAS 平台管理器”,上传 war 包,并设定如下参数: 2 级域名, 3 个 tomcat 实例, mysql 实例 1 个,设定 mysql 用户名和密码。
-
"PAAS 平台管理器"创建根据模板并设定用户名和用户,启动 1 个新的 mysql 实例,纪录好 ip 地址,端口等信息。修改 paas 状态。
-
“ PAAS 平台管理器”启动 3 个 tomcat 实例,分别编号: server01-tomcat01 , server01-tomcat02 , server01-tomcat03 ,修改 paas 状态。
-
"PAAS 平台管理器”把上传的 war 包解压,并根据 mysql 的配置信息,改写相应的 xml 文件信息,并分别 copy 到 3 个 tomcat 指定的目录下。
-
“ PAAS 平台管理器”分别启动 3 个 tomcat 实例,并修改 nginx 的配置信息,生效请求转发,并修改状态。
-
大家就可以通过域名或地址来使用刚才发布的应用了。
5.2.3 实现方式
前面用精神开拓了视野,用思想武装了头脑,那么现在我们就开工了,首先需要一些硬件,软件,以及网络设备,清单如下:
图52-02 基本型paas平台的物理部署
整个系统分为管理节点,计算节点和路由节点。
-
路由节点:实现 2 级域名的定向和请求的分派
-
计算节点: Service pool 和 apps pool 里面的机器都是计算节点,假设都是由 vm 组成,如果是 db 池,每个 vm 启动一个 mysql 的实例,缺省不启动;如果是 apps 池,每个 vm 安装统一的 jdk ,允许启动 3 个 jvm ,并部署好 tomcat 实例,可使用统一的文件系统。缺省不启动。
-
管理节点:管理节点是整个系统的核心,包括数据库,以及存储服务模板和应用模板。这里的数据库是提供管理节点使用,用来存储整个管理系统的中间状态和元数据信息。
关键的数据
-
基础数据:包括 ip 地址, servcie id/apps id 和 ip 的对应关系, 2 级域名对应的 ip 等
-
状态数据:服务和应用的当前状态,通过 agent 定时更新信息。
-
历史信息:服务和应用的状态轨迹,用户处理的信息,动作的处理等
核心的软件
-
执行脚本:服务和应用的预设脚本,典型的有 start/stop 。
-
上传模块:和用户交互的接口,获取 war 包,并得到用户设定的参数,典型的有 mysql 的 id 和需要启动的服务实例个数。
-
配置模块:把 war 解压,根据配置信息改写相应配置文件,并分别复制到相应的 apps 节点。
-
网络端口:节点机器端口和网络都需要彼此开放,相应的用户和权限开启
在此基础上,采用负载均衡,以及合理使用缓存,业务应用作合适的分离部署,来提高系统的性能。图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