从项目开发到云端架构(18)

5.3 扩展PaaS

       在Paas平台的奴隶时代，平台的分布和管理都是基于操作系统的层面来处理的，指令由脚本来调用，利用操作系统提供的网络能力，进行应用/通用服务的远程处理；业务和系统的状态的存储和查询采用的关系数据库；并利用现有或改进的工具对系统和应用进行监控，检查系统的健康状况。这是一种行之有效的方法，并肯定在众多网络公司也或多或少的得到了有效的应用。

       但这种架构模式较为简单，扩展性有限，在解决了Paas平台有和无的问题后，就要着手解决Paas平台好不好用的问题，在这个阶段就需要有强有力的语言（非类似shell脚本）来通盘处理网络，分布式，部署，管理，监控等能力，构建强有力的PaaS平台的cloudControl，通过cc来统一协调和处理Paas内部事务，从一盘散沙过渡到高度集中，统一协调的阶段中，由此我们diy的Paas平台也就从奴隶时代，逐渐过渡到封建时代。

       Cloudfoundry 是用ruby开发的，openshift是用python开发的，cloudify是用java开发的，所以说用合适的构建方法，用哪种语言都是可以的，我相信此时此刻c++的拥趸会跳出来说要做过paas平台，这是可以的，但互联网的应用和需求，瞬息万变，朝三暮四，相比之下动态语言ruby和phthon就更有优势，这也是cloudfoundry和openshift选择它们的原因；至于cloudify，是基于gigaspaces的产品而开发的paas云平台，已经在业界有了10多年的沉淀和积累，属于家大业大，改弦更张不容易。

       Paas平台最主要的是解决了分布式计算的能力，通过对应用的分布式部署，为各个被拆分的模块提供了区别对待的容器，容器之间彼此隔离并能相互通信，并提供了可操纵的接口，另外作为paas平台需要有对Iaas层可迁移的能力，这样具有一定生产力的Paas平台的需求大体可以描述出来。如果采用Java如何来实现？

 

A、基础技术的改进

       在Java里面分布式的基础就是rmi，所有的分布式技术都是在这里衍化，但rmi技术太底层，对于diy paa而言需要更高级的分布式平台，需要在分布式环境中提供寻找/注册等服务，以及对分布式对象的统一处理界面，而Java业界中，Jini（Java Intelligent Network Infrastructure）和JavaSpaces技术正好能满足这些功能：

• Jini 提供了分布式环境中寻找（ look-up ）、注册（ registration ），租借（ leasing ）等服务，具有自动配置，自我管理，自我恢复，代码移动以及相互间自由通讯能力，提供了计算单元在网络中的即插即用能力；
• JavaSpaces 提供了对象的提供者和请求者可用来方便地进行通信的共享虚拟空间，允许以 Java 对象的形式对任务、请求和信息进行简单的交换，如提供了处理（ processing ），分享（ shareing ），以及迁移（ migration ）等能力，为 java 对象提供了可在网络中迁移的存储能力，以及基于属性的查找方式。之所以在这里采用 Jini 和 Javaspaces 技术，因为可以产生类似网格计算能力，彼此处理单元的地位平等，并可以相互迁移，位置感知。
• 当然还有其他的技术表现形式，比如 corba/ice,web service 等，技术上稍许有些差异，采用这些技术实现上有些不同，这里不展开讨论。

      

       如果把我们的处理单位（Process Units à PU）进行抽象，可以是一堆的Service JavaBeans，或者是具有某些状态的POJOs，或则是Service JavaBeans + POJOs进行在网络上按照一定规则得到一系列部署方式，通过部署的不同从而形成不同的计算能力。

 

图例	说明
图 53-01：JavaSpaces和bean的交互	应用程序组件与空间交互（使用读，写，并通知操作），并实现一定的功能。
图53-02：JavaSpaces内容	缓存实例保存在内存中的数据对象。
图 53-03：JavaSpaces提供的接口	一套用于读，写，走，和注册的通知，在空间中存储的对象的方法。执行允许发送的空间内执行任务。阅读并采取判据可以通过指定的查询或模板（例如对象）。

表 53-1 ：JavaSpaces技术能力

 

图例	说明
图 53-04：空pu	Service Bean和/JavaSpace实例相结合。PU在容器内运行。
图 53-05：包含了JavaSpaces的PU	实例化JavaSpace实例。
图 53-06：各自独立的PU调用	一个部署包包含一个或多个服务。通常作为与其他PU进行交互的客户端，利用空间的消息传递功能。
图 53-07：包含bean和spaces的PU	部署独立可伸缩的PU。

表 53-2:：PU的基本组成形式

 

图例	说明
图 53-08：包含bean和spaces的PU	Space集群的实例，运行在各自的处理单元实例。空间实例相互连接，形成集群。
图 53-09：包含bean和spaces的PU	与主实例和一个或多个备份实例的数据网格。
其他略。。。

表 53-3：数据网格拓扑结构

 

     

  从下图看，很像应用服务器的session分区备份的集群机制图，如果把session看成JavaSpaces，Servcie Beans看成servlet容器，pu看成应用服务器实例，所以说技术都是相通的。

 

 

 

图53-11：基于Jini和JavaSpaces的架构体系

1. 每个处理单元实例拥有一个分区的空间实例和一个或多个特定分区上的事件注册的服务，同构成一个应用集群。如果群集需要高度可用，每个主分区可有一个或多个备份的分区，当主分区失败的时候，备份分区变迁为活跃状态。
2. 每个处理单元实例只处理各自空间的数据。
3. 该系统可以通过简单地增加空间分区和其相应的处理单元实例的数量缩放。
4. 当部署到服务网格，具备自我修复能力和 SLA 功能。
5. 管理 UI 都可以通过在运行过程中的全程监控和管理。

 

 

 

B、部署能力的改进：

       传统的开发模式：开发->测试-> 部署-> 扩展，需要自己搭建web容器，部署应用服务器，配置数据库，如果涉及到集群方式，更加复杂，需要在指定的时间之前创建服务器，建立apache，tomcat，mysql等。而且架构也在不断的扩展和迭代，还需要分布式的服务器，模块化的组件，异步的架构；数据库的分片，以及多数据的来源。借助paas平台以及paas平台提供的架构模式和组件，业务系统的架构被逐渐拆解：从单一WAR包à 核心业务拆分，异步通讯 à 多库多表 à 大文件系统，noSql系统 à 结合MapReduce，实现完整的互联网分布式系统体系。部署的方式也要极大的简化，从人工干预到自动处理，最好是智能处理。

 

C、并发能力的改进：

• 应用无状态： web 系统的伸缩性的好坏取决于应用的 session 如何管理。通常通过集群来解决这个问题，有几种模式：广播复制，分区复制，以及共享缓存服务器模式。 Session 分区复制＋ Route 粘性会话是一种免编程的模式，如果需要更大的并发量的支持，的修改程序采用共享缓存服务器的模式。
• 有效使用缓存： 从浏览器缓存，反向代理缓存，页面缓存，局部页面缓存，对象缓存等等都是缓存应用的场景。缓存分为读缓存和写缓存。对于一些读写比不高，同时对数据安全性需求不高的数据，将其缓存起来从而减少对底层数据库的访问。
• 应用拆分： 典型有的前后端拆分，后端也可进一步拆分，各个系统都可以独立维护和独立的进行水平伸缩，从而提高系统的扩展性和可维护性，同时系统的水平伸缩性也极大的提升。但是拆分也给系统带来了问题，就是子系统之间如何通信的问题，数据一致性的问题。
• 数据库拆分： 数据库是系统中最不容易扩展的，之前讨论过数据库分区的事宜，这里略。
• 异步通信： 采用异步通信也是关系到系统的伸缩性，以及最大化的对各个子系统进行解耦 . 。通常适合异步的场合是一些松耦合的通信场合，而对于本身业务上关联度比较大的业务系统之间，我们还是要采用同步通信比较靠谱。 根据以往经验得知，在同等环境，同步异步的调用，性能差异在一个数量级上。

 

D、其他改进：

• 非结构化数据存储： 在互联网应用当中，不是所有的数据都是结构化的，典型的有 mongodb ， cassandra 等，平台需要能支撑。
• 监控、预警系统： 利用监控系统以后，并与预警结合起来，能快速响应系统出现的问题，提高系统的稳定性和可用性。
• 配置统一管理： 大型的分布式应用，通过一个统一的配置管理可以使得这些问题得到很好的解决，当有新的节点加入或者删除的时候，配置管理系统可以通知各个节点更新配置，从而达到所有节点的配置一致性，这样既方便也不会出错。

 

通过前面的几个改进要求，结合Paas平台的应该具备的生产能力，整理如下：

1. 支持更多的服务，典型的内建服务需要 MQ 服务，内存服务器， nosql 数据库
2. 能参数化定制应用和服务以及性能伸缩模式 。
3. 支持业务的分离部署（ war+zip ）
4. 支持自定义脚本模式
5. 支持多 iaas 模式（ iaas 不锁定）
6. 提供使用良好的交互式接口（控制台， web 管理界面）
7. 提供更加丰富的应用和服务的运行时状态的查询
8. 监控和预警机制，对于常见情况能进行通用方式的处理

 

结合之前的技术背景，一个可能的部署模式如下，

• PU 作为独立和拆分的业务单元，可在多处部署。
• PU 可以是业务逻辑单元，也可以是缓存服务，消息服务等通用业务逻辑单元。
• PU 在部署在容器内（ contrainer ），容器为受控的 JVM ，
• 提供对容器的管理接口（ servcie manaer ），以及发现接口（ lookup servcie ）。

 

 

 

图53-12：采用PU模式的部署

 

5.3.1 架构和组件

       通过CC作为整个云端的中心和枢纽，把网格节点被虚拟化为可使用的计算单元，使用Jclouds部署pu（pu是按照业务需求设计的业务单元）到container，而container被servcie manager和lookup servcie管理和发现，实现container的生命周期管理和对外的服务提供。

       整个paas平台分为3大部分，服务适配器（service adapter），云端控制器（cloud controller），和云端驱动（cloud driver），整体部署分为C/S模式，分为计算节点和服务节点，服务节点为server端，计算节点为client端，服务适配器是部署在计算节点，云端控制器在服务节点。底层依赖iaas系统来管理vm的生命周期，以及基础的网络控制，所以这里抽象出一层，用来处理各个的iaas的实现。

 

       通过下图的paas系统架构，能看到在标准的paas平台的架构中，没有严格的apps池和服务池的边界，因为这里采用的是具有状态的cc，它能知晓被部署的apps应用集合和servcie集合，不需要特定的边界来声明部署的位置，但在下个章节中阐述在无状态的cc，就需要声明应用的边界。在这里通过cc的部署模块 + service adapter 的安装模块来部署应用，也就是说在创建业务应用和服务的时候并不是透明的，还需要程序员在DSL中收工控制vm的地址/os规格等参数，与之对应也不要有个paas中转的“订阅发布”模块。整个paas平台分为2个层面：管理节点（服务端）和计算节点（客户端），所有的节点都在网络节点中，并受管理节点监控和控制，整个paas模式类似于网格模式。至于cloud driver是用来屏蔽各个iaas层的抽象层，对于kvm，openstack，cloudstack，都有统一的api调用。

 

 

 

图 53-13 系统架构

 

DSL

       DSL（Domain-specific language，领域特定语言），侧重特定领域的表达有限的计算机编程语言，在这里专门来描述云端的部署。之前在基本型paas中，对应用和服务的管理是通过简单的设定，并有一定的先后次序来表示依赖关系。在这里，把这块功能进行扩展，结合部署，依赖管理，脚本控制。典型的，需要：

•   应用的管理，是多个服务打包的地方。
• 服务的管理，这里包括 tomcat ， mysql ， mongodb 等，都统称为服务，包括安装，管理。
• 对脚本语言的调用和执行
• 参数文件的读取
• 应用和服务的依赖，绑定
• 负载均衡的规则
• 扩展点的管理：以后这里可以加入 maven + jenkins ，实现持续交付等扩展功能，这个在健壮型 paas 中会阐述，在这里是预留一个扩展点。

 

       语言一般用动态语言，比如ruby，python均可，如果paas平台基于java语言开发，用groovy也是一种好的方式。

 

Cloud driver

       处理对多个iaas层的调用，在这里是paas平台的抽象层，提供对多个iaas底层的调用，从而避免对iaas的锁定，并提供对DSL的统一的调用接口。

 

 

universal service manager

把对服务（tomcat，mysql，mongodb等）的管理，以及安装，部署等，都统一成服务模式。

 

5.3.2 业务流程

       因为在标准paas平台的规划中没有涉及到对apps池化和服务池化进行管理，所以这样的paas平台的结构相对简单，没有这么多的组件和模块，业务应用部署也容易，整个paas平台理解为网格系统，分为管理节点和计算节点2层即可。paas平台的管理工作由cc进行处理。

       业务流程很简单：

1. 开发人员代码测试通过后，编写 recipe （使用 dsl 语言），描述整个应用的部署，比如启动 3 个 tomcat ，并依赖 1 个 mysql 和 1 个 mongodb 实例。
2. 通过 cli 发布， cc 读取相关目录下代码以及 recipe 文件。
3. CC 根据 recipe 对 vm 的申请（非透明，需要在文件中注明 os 规格，版本，以及 ip ）， cc 透过 cloud dirver 获取该 vm 的使用。该 vm 需要吻合最低要求，包括缺省用户名，端口以及 jdk 等。
4. CC 通过 ftp 穿 agent ，业务系统文件，等其他。
5. CC 引导业务系统文件，根据 recipe 的步骤，按部就班，先后次序引导服务。

 

5.3.3 实现方式

 

 

 

图53-14 标准型paas平台的物理部署

 

       和基本型paas平台类似，整个系统分为管理节点，计算节点和路由节点，在这里不对apps和service的池化进行管理，不同的是对配置和部署进行了深化，并对虚拟机的处理采用了抽象层，实现去IaaS层的锁定。

1. 路由节点：实现 2 级域名的定向和请求的分派
2. 计算节点： Service pool 和 apps pool 里面的机器都是计算节点，假设都是有 vm 组成，如果是 db 池的，每个 vm 启动一个 mysql 的实例，缺省不启动；如果是 apps 池的，每个 vm 安装统一的 jdk ，允许启动 3 个 jvm ，并部署好了 tomcat 实例，可使用统一的定好好的文件系统。缺省不启动。不同的是每个 vm 都有 agent 来监控， vm 的生命周期有 cc 通过 cloud driver 来统一处理。
3. 管理节点： cloud controller ，管理节点是整个系统的核心，，包括数据库，以及存储服务模板和应用模板。这里的数据库是提供管理节点使用，用来存储整个管理系统的中间状态和元数据信息。

 

关键的数据

1. 基础数据：包括 ip 地址， servcie id/apps id 和 ip 的对应关系， 2 级域名对应的 ip 等
2. 状态数据：服务和应用的当前状态，通过 agent 定时更新信息。
3. 历史信息：服务和应用的状态轨迹，用户处理的信息，动作的处理等

 

核心的软件

1. DSL ：提供一种针对云端部署的领域特定语言，通过该语言来设定业务应用的 recipe ，并随业务模块同步提交。
2. USM ：统一服务管理，管理 tomcat/mysql 等服务，并提供应用实例的启动 / 停止等处理。
3. 云驱动：通过虚拟层去 iaas 的锁定，实现在 kvm ， openstack ， cloudstack 的 vm 部署

 

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

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