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

 4.3 CloudFoundry

       Cloud Foundry是VMware主导使用Ruby开发的一款开源PaaS云计算平台，它提供了各种各样的云平台、开发框架以及应用程序服务。开发人员可以在该平台上迅速部署及运行Web应用程序。Cloud Foundry能够帮助开发者使用Java或者其他的基于JVM的架构构建应用，它支持的应用程序框架包含Spring、Grails、Ruby on Rails、Node.js 及 Scala，NET的支持。 Cloud Foundry遵从OpenStack云计算平台规范，作为业内第一个开源的PaaS，它给我们打开了一扇研究云计算环境下PaaS平台架构设计的窗户，让我们管中窥豹，学习和借鉴。

       Cloud foundry是Vmware的开源PaaS产品，Vmware还有自己的商业版本：VMwarevFabric Cloud Application Platfor，这和Cloud Foundry属于两个产品，分别由两批团队开发。比较而言，vFabric作为商业产品，完善很多，而且发展已久，和STS深度整合。

4.3.1            简单介绍

 

 

图43-01 ：Cloud foundry 概念图

 

       从图能清晰的看到Cloud foundry的3大能力，这也是业界标准PaaS平台通常能提供的能力。

 

• 部署应用云的选择性。灵活性是云计算的重要特点，而应用部署到云的选择是PaaS平台被广泛接受的重要前提。用户需要在不同云服务器之间切换，不被某家厂商锁定。CloudFoundry无论是公有云还是私有云，基于VMware的云和非VMware云都支持。在图中的右边斜线对应了公有云/私有云/混合云。
• 行业标准架构的选择性。以前，开发者只能在几种开发框架中进行选择，现在根据需求自由选择。据了解，Cloud Foundry当前版本已经支持Spring for Java、Rails、Ruby上的Sinatra和Node.js，也支持其他基于JVM的框架，如Grails。当然了，vmware收购了spring，自然Spring for Java的代码有了天然的支持，现在spring 3.1.1版本已经支持了这种for cloud的模式，启用了<cloud>标签。根据我们公司的这么多年的积累和技术储备，最看中的是java能力，并且在项目中都会使用spirng。当前Cloud Foundry对JEE支持比较弱。这点应该是openShift（redhat）的强项。
• 应用架构服务的选择性。Cloud Foundry目前支持MySQL、Mongo DB和Redis，Postgres，RabbitMQ，其中Postgres是定制化的版本。以后将逐步支持其他应用服务及第三方技术。

 

      

基于Cloud Foundry的项目部署架构。特点如下：

 

• 系统分2大部分：前端业务和后端业务作分布处理，彼此用消息作为异步关联。
• 使用CF提供的缺省服务，包括redis，mysql和mongodb。
• 前端通过负载均衡来实现集群，如前文所言，load balancer是nigix做的，是通过粘性会话来实现有限扩展。

 

      

       从CF的多层部署的模式去看，并没有超出我们曾经熟知的集群和分布式的理念，CF作了一些封装和提供了一些自动部署的能力。

 

 

 

图43-02 ：CF推荐的软件架构，多层部署模式

 

       结合CF的功能结构图，程序员设计完毕的代码，通过cloud controller上传到cf，并通过一定的规则部署在DEA区，前端route根据路由的分发，把请求给分解，如果有后端应用（no web）也同样部署在DEA区（可以理解一下上下2张图中的红圈圈，即程序部署的位置），并用rabbitMQ进行关联，这样根据CF提供的通用架构模式和基础服务的支撑，达到了一种系统通用分布式的架构能力，并能达到一定高度的并发访问的要求，并极大的简化了部署和监控的工作。

 

 

 

图43-03： 逻辑视图

 

4.3.2            总体架构

 

 

 

图43-04 ：CloudFoundry的总架构图

 

       CloudFoundry的核心就是一套消息系统，以及多模块的分布式系统，支持模块自发现，错误自检，且模块间低耦合，面向消息的架构是它节点横向扩展，组件自发现等云特性的基础。中心位置有个叫nats的组件，基于EventMachine的消息系统。每个台服务器上的每个模块会根据自己的消息类别，向MessageBus发布多个消息主题；而同时也向自己需要交互的模块，按照需要的信息内容的消息主题订阅消息。

 

 

 

 

图43-05 ：CF内部控制，指令，数据流向图

4.3.3            组件说明

Router

       Router组件对所有进来的Request进行路由。进入Router的request主要有两类：

 

• 首先是来自VMCClient或STS，由CloudFoundry使用者发出的管理型指令。例如：列出某个apps的vmcapps，提交一个apps等。这类request会被路由到CloudController组件。
• 第二类是外界对你所部署的apps访问的request。这部份requests被路由到DEAs的组件。

 

 

 

 

 

图43-06 Route架构：（左图为老版本设计，右图为新版本设计）

 

       所有进入CloudFoundry系统的requests都会经过Router组件，Router被设计成去单点依赖，组件可平行扩充，且可替代，以保证扩展性。这是CloudFoundry，也是所有云计算系统的设计原则。云系统可以部署多个Routers共同处理进来的requests，CloudFoundry保证所有的request是无状态的，这样负载均衡可采用DNS，硬件LoadBalancer，ngnix，都是可行的。目前Router组件，是对nginx的一个简单封装。

 

Cloud Controller

       CloudController是CloudFoundry的管理模块。主要工作包括：

 

• 对apps的增删改读；
• 启动、停止应用程序；
• Staging apps（把apps打包成一个droplet）；
• 修改应用程序运行环境，包括instance、mem等等；
• 管理service，包括service与app的绑定等；
• Cloud环境的管理；
• 修改Cloud的用户信息；
• 查看Cloud Foundry，以及每一个app的log信息。

 

           

       Cloud Controller就是与VMC和STS交互的服务器端。VMC和STS与CloudFoundry通信采用的是restful接口，从VMC或者STS接到JSON格式的协议，数据持久化到CloudController Database，并发消息到各模快去控制管理整个云。

 

       Health Manager和DEA是外部模块，CCDatabase就是CloudController Database，这里是个单点。CloudController Database的并发性不会很多，应用级别的数据库访问是由底下的Service模块处理的，这个数据库存的是Cloud的配置信息。读操作主要来自DEA启动，作为初始化DEA的依据；以及healthmanager模块会从这里读取预期的状态信息，这部份数据会与从DEA得到的实际状态信息进行比对。

 

 

 

图43-07a：Cloud control架构（old）  

 

图43-07b：Cloud control架构（new）

      

Health Manager

       HealthManager: 做的事情不复杂，简单的说是从各个DEA里面拿到运行信息，然后进行统计分析，报告等。统计数据会与CloudController的设定指标进行比对，并提供Alert等。

 

DEA

       Droplet Execution Agency：Droplet是指提交的源代码 + 配套好的运行环境 +管理脚本，例如Start/Stop这些小脚本全部压缩好在一起的tar包。还有一个概念，叫做Stagingapp，就是指制作上面描述这个包，然后把它存储好的过程。CloudFoundry会自动保存这个Droplet，直到你start一个app的时候，一台部署了DEA模块的服务器会来拿一个Droplet的copy去运行。所以如果你扩展你的app到10个instances，那这个Droplet就被会复制十份，让10个DEA服务器拿去运行。

 

图43-08 ：DEAs架构（左图为老版本设计，右图为新版本设计）

 

Services

       Service模块是一个独立的、可Plugin的模块，以方便第三方把自己的服务整合入CloudFoundry生态系统。在Github上看到service是与CloudFoundry Core项目vcap独立的一个repository，为vcap-service。Service模块其中设计原则是方便第三方服务提供商提供服务。

       从Github上看，已有以下服务提供：MongoDB；mysql；PostgreSql；RabbitMQ；Redis等。基类都是放在base文件夹中，第三方如果需要自己开发CloudFoundry的服务，需要继承改写它里面的两个基础类：Node和Gateway；而里面一些操作，如：Provision，可以在base的provisioner.rb基础上加入自己的逻辑，同样的还有Service_Error和Service_Message等。

       从架构了解上来说，只要知道服务间的关系，知道个服务与base间透过继承关系来横向扩充，而CloudFoundry与apps调用Service是通过base来完成这一简单的架构方法即可。

 

对CF的架构以及CF组件有了个初步的了解，CF的特点为：

 

• 基于消息的多组件架构是实现集群的简单、且有效方法。消息可以使集群节点间解耦，使自注册，自发现这些在大规模数据中心中很重要的功能得到实现；
• 适当的抽象层，模板模式的使用，方便第三方可以方便在CloudFoundry开发扩展功能。CloudFoundry在DEA及Service层都做了抽象层处理，相对应地使开发者可以容易地为CloudFoundry开发Runtime和Service。例如，在CloudFoundry刚推出的时候，只支持Node.js,Java, Ruby，但第三方提供商、开源社区快速跟进，为CloudFoundry添加了PHP,Python的支持。这得益于CloudFoundry精巧的DEA架构设计。

 

 

4.3.4 业务流程

       CF从本质来说就是应用和服务的管理系统（mis系统），只是管理的不是二维表中的数据，而是我们上传的web应用和它自身的服务，从一个应用上传到CF，就启动了CF的流程，下图其实是vmc push命令在CF的内部组件之间的交互过程。

图 43-09：CF部署应用的内部流程

 

4.3.5 部署模式

       在传统方式中，程序员把商业或开源工具安装在本地系统上，编写代码，然后把开发的应用程序部署到他们自己的基础设施上并管理它们；基于PaaS的部署，开发人员不必为定义可伸缩性要求去操心，他们也不必用XML编写部署说明，这些工作全部由PaaS提供商处理     

       CloudFoundry官方用Chef作为部署工具 。Chef是OrchestrationEngine的一种，可以自动化管理、部署复杂的云环境。工作过程大概就是部署人员写一系列的“recipes”，这些“recipes”描述我们需要把我们的服务器部署成什么（Apache,Mysql还是Hadoop），然后Chef可以自己执行这些配置。现在数据中心变得越来越庞大，原来那种通过自己写脚本完成自动部署的IT管理方式日渐不堪重负，帮助管理、部署数据中心服务器集群的中间件变得越来越重要，这也是DevOps的范畴，.在以后的篇幅中在阐述。

 

       部署有2种方式，软部署和硬部署。项目开发完毕，会有war包和数据库脚本，如果是软部署，提交给相依的云平台部署人员即可。他们根据软件部署模型来部署，由云平台部署人员控制ip以及route的分派，以及数据库和应用的绑定。

       如果是硬部署，则是直接面向主机的操作系统，划分主机的ip地址以及网络规划，部署应用服务器并且调优，设定好war中的数据库连接方式，自行确定前端派发的分派方式。下面用个切图比较方式，比较一下传统模式部署（硬部署）和基于paas的部署（软部署，以CF为范例）。

 

开发模式	传统部署	云部署
图43-10：单一部署	[mysqld] user = foobar port = 3306 basedir = /usr bind-address=192.168.0.8 key_buffer = 16M ….. [nginx] http.include mime.types; default_type: keepalive_timeout 65; ….. [tomcat] ….. [frontend] dependencies: mysqlclient ruby files: core/app/fe/**/* core/common/**/*	# 登录到CF vmc target http://api.cloudfoundry.com vmc login   # 创建并启动应用 vmc push myapp –instances 2 –mem 64M –path ../code   # 创建数据库实例并绑定 vmc create-service mysql –name mydb –bind myapp   # 升级应用的代码 vmc update myapp –path ../code
图43-11：分布部署	更多。。。   这里省略	# 创建多实例的前后端应用 vmc push fe –instances 8 –mem 64M –path ../fe_code vmc push be –instances 2 –mem 256M –path ../be_code # 创建服务并绑定 vmc create-service mysql –name mysql –bind fe vmc create-service mongodb –name mongo –bind be vmc create-service rabbit –name rabbit –bind fe vmc create-service redis –name redis –bind fe vmc bind-service redis be vmc bind-service rabbit be # 执行代码更新 vmc update fe –path ../new_fe_code vmc update be –path ../new_be_code

4.3.6 开发方式

       Github上找到CloudFoundry的全部代码：https://github.com/cloudfoundry，你会看到几个不同的Repositories，它们分别是：

 

• vcap: Cloud Foundry的Core，又或者称作Kernel；
• vcap-service: Cloud Foundry的Service组件。Cloud Foundry的service是作为插件提供的，这出于它方便第三方开发service而设计的；
• vmc: VMware Cloud CLI. 是一个Ruby应用，与Cloud Foundry的CLI交互。主要通过分析用户输入的CLI，向CloudFoundry发送Restful请求；
• vcap-java: 如果你的app是用java开发，且需要与Cloud Foundry交互，例如取得当前serviceserver的ip地址等，你可能需要这个jar，里面对我们Java开发常用框架有所支持，它底层也是对CloudFoundry的Restful请求的包装；
• vcap-java-client: Cloud Foundry的Restful API的Java封装，与上面的项目不一样，它只是个简单的读取CloudFoundry信息，并放如JavaBean中；
• vcap-test: Cloud Foundry的test cases;
• vcap-test-assets: Cloud Foundry一些apps示例。

 

       程序员如果基于CF作开发，以下书籍可以参考，这些书籍不在1.5章节中声明的辅助文档之列，因为这些都是CF的PPT课件：   

《AM-1 从开发者的角度看CloudFoundry.pdf》，

《AM-2 Cloud Foundry BootCamp.pdf》

《PM编程语言与架构专场 Spring带你步入云端 Chinese.pdf》

《PM解决方案和合作伙伴专场 3 CloudFoundry服务网关的架构.pdf》

《PM数据库专场 CloudFoundry中MongoDB的应用.pdf》

 

图43-12： 开发部署

 

 

图43-13： 物理部署图

 

4.3.7 后续工作

       要搭建一个完整的私有云系统，还有很多缺少的地方，譬如下层的IaaS如何集成？如果CloudFoundry一个组件负载过高，应该如何扩容？能否做到自动化？如何检测、管理CloudFoundry的服务器集群？这些都是需要解决的问题。

       CloudFoundry是与底层IaaS无关的，可以用vSphere或者OpenStack来作为IaaS方案。为了实现云计算的可伸缩性，IaaS层需要提供如下功能：

 

• 当CloudFoundry某些组件的发出性能警报，或者到达我们设定的某些指标时，我们需要用IaaS创建部署该组件的虚拟机，并把它启动加入CloudFoundry集群中（由OrchestrationEngine来做）；
• 当某些组件有大量资源盈余，而物理资源出现紧张情况的时候，IaaS需要删除虚拟机，把计算资源归还到资源库；
• IaaS需要提供虚拟机的注册、存储、查找、导入、启动等功能。

 

        私有云有了IaaS和PaaS，有了自动化管理工具（也就是OrchestrationEngine），但中间还缺少监控管理工具。有了监控管理工具，我们才可以知道现在CloudFoundry每个服务器的资源使用情况，才可以向IaaS请求计算资源。

 

 

 

 

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

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