从项目开发到云端架构 19

5.4 健壮Paas

       对于健壮的paas则有更多的要求，还是秉承前面一个章节阐述的业务系统的架构要求，看看对于paas平台有那些要求：

1、应用托管和自动部署

• 自动部署是必须实现的功能，有了自动部署才可能真正的让应用部署包和中间件资源池进行彻底解耦和按需调度。在IaaS层是应用到物理服务器的解耦，而在PaaS层是应用和中间件资源池的解耦。要进行自动部署则开发的应用必须符合PaaS接入规范标准。

•  对于虚拟化有两个层面：服务器虚拟化提供的是虚拟机裸机和应用虚拟化提供的是包含了中间件+应用部署包具有计算能力的能力单元。为上层应用提供支撑的是应用虚拟化。

• 而要实现应用虚拟化即需要考虑weblogic，jboss，was，tomcat多种中间件容器的支持。应用虚拟化的过程即是首先动态创建中间件容器，然后将应用包部署到中间件容器中，再启动该计算单元提供能力。

• 应用虚拟机出来的含中间件+应用包的容器是一个可以独立运行和调度的单元。这个容器可以基于独立的虚拟机，也可以基于物理机进行。这个计算单元比虚拟机更加轻量级，更加容易实现快速的分布式动态调用。但是存在的问题也很明细，即无法做到很多的资源池隔离。

•  对于自动部署过程，一般为上传符合paas规划的应用部署包，选择中间件容器，选择计算单元的数量，即可以进行自动部署工作。自动部署一般针对应用服务器层，涉及到数据库层面的一般来说只能做些相应的初始化工作。 

3、路由和软集群模块

       这个类似于CloudFoundry里面的router模块功能。主要是实现一种软集群，对进入的request请求进行路由分发。对于CloudFoundry的Router组件，目前版本是对nginx的一个简单封装（http和反向代理服务器）。Router组件是外部request请求进入的唯一入口。

       因此前面谈到的调度决策完成后，需要对新增的计算单元挂接到Router组件上，即Router组件上能够进行负载均衡和路由分发的节点增加一个。实际在Router组件在进行路由分发的时候仍然类似传统的负载均衡方式进行。传统的负载均衡本身可以支持多种策略，包括数据量均衡策略，request请求的均衡策略，基于session层面保存的均衡策略。一个Router组件要实现各种均衡策略不是一件容易的事情。

5.4.1架构和组件

5.4.2业务流程

5.4.3实现方式

       和之前的paas平台不同的是对apps池和service池的管理，程序员在部署业务系统的时候，不需要关注具体的vm的信息和os的规格，地址和id由cc控制，程序员只需要管理到服务的id即可。我们为将来众多的业务应用，构建了硕大的资源池，在为这些系统支撑的同时，池自身需要是可支持分布式应用和可水平扩展的系统，所以在这里各个组件都是可拆开可复制，统一通过消息机制来传递指令。

图54-01 部署图

       从总体架构来说，分为前端架构和后端架构，前端架构特指手机客户端应用，解决终端用户通过ipad，智能手机上网的方式，核心思想是架构在webkit容器之上，利用html5在各个智能手机，掌上电脑，不同手机操作系统之上统一展现形式。后端架构是基于云端部署的服务平台，为用户提供各种类型各种风格的文化项目的生命周期的管理，为此云计算服务平台提供多种语言环境，包括php,ruby，以及java语言环境，并提供良好用户界面，提供部署和测试和打包的能力，后端架构分为2大层，paas层和iaas层，期中paas层来控制项目的生命周期，以及提供缺省的平台服务，包括mysql,tomcat等，iaas层提供资源的管理，为上层应用提供vm的生命周期的管理。

       后端架构因为内容丰富，简单的分为2层无法清晰的表达功能，所以采取分域的模式进行阐述，后端架构从领域的视图分类，可分为：

1. 前端分发域：分发前端的请求，采用改进版本的nginx作为代理服务器，转发前端请求，并提供一些请求的策略处理。

2.  移动计算-Paas域：

1. 云端控制：是paas平台的核心，提供了部署语言的执行能力，夸iaas平台的调用能力，把底层服务统一对外封装的能力。

2. 应用管理：包括用户的war/zip的上传管理，部署管理（单一war/多个war，彼此关联依赖等），脚本的执行，自动检测等处理，以及通知服务管理，控制服务的生命周期。

3. 发布订阅：把分域模块通过异步处理又关联起来，各个域模块都允许扩展，只需要在“发布订阅”模块中声明。

4. 服务模板：内部对服务有个模板管理，可以进行参数设定，根据apps管理来的指令，来启动1~m个服务实例，并对外提供id，由“apps管理”进行服务和apps的绑定。

3.  应用池域：是装载终端用户上传的项目场地，提供包括java，php等容器服务。可启动多个实例，并设定前端请求转发的规则。

4. 服务池域：实例化后的服务场地，缺省的服务包括mysql，tomcat，mq，node.js，php等，并允许多个实例化。

5. 移动互联网服务域：为手机上网用户提供的特定服务，包括手机用户鉴权，统一接口接入，终端应用打包以及终端应用调测等服务。

6. 核心服务域：为用户上传的项目提供通用服务能力，包括定时调度，应用认证，全文检索，缓存服务，消息服务，配置服务等。

7. bigData域：针对大数据应用服务提供，大数据处理方式和通用处理模式不一样，采用的是分布式文件系统以及mapreduce的处理机制，采取了hadoop+hdfs+hbase+zookeeper，处理后的数据被存储在关系数据库或者nosql数据，以备前端应用使用，除此之外还提供海量存储，基于海量存储的图片存储以及视频服务。

8. 系统服务域：为应用池，服务池，核心服务提供系统级别服务，提供负载均衡，高可用HA以及镜像服务。

9. 监控域：获取各个模块的当前参数信息，反馈给管理者，并与特定的自动处理脚本关联，提供了自动处理的方式。

10. 发布测试部署域：属于devops域的范畴，提供代码上传，打包，测试，部署的整个软件生命周期的管理，简化基于云端部署的复杂度。

11. 虚拟化域：为垮多个iaas层构筑的抽象层，通过jclouds，提供了对openstack,cloudstack等iaas控制能力，管理vm的生命周期。

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