云计算前沿—详解PaaS之Cloudfoundry

沈阅斌 2016-01-28 09:47:03

随着云计算的不断发展，IaaS已经不能满足用户的需求。作为一个能够简化开发、测试、部署、运维的平台，Pass受到了越来越多的关注。今天沈阅斌老师将为我们分享关于PaaS的一些亲身经验和体会，同时详细介绍PaaS技术中的Cloudfoundry。

PaaS基本介绍
PaaS的价值在哪里
PaaS的技术选型
Cloudfoundry基本介绍
Cloudfoundry架构及相关组件
基于Cloudfoundry扩展PaaS功能
Diego介绍

一．PaaS基本介绍

PaaS，平台即服务。是云计算的一种服务形式。其实并不是一个非常新的概念，像GAE、SAE很早就提供了类似这样的服务。不过在很长一段时间内，PaaS接受程度不高，在跟客户谈及云计算时，普遍都认为云计算就是IaaS，即基础设施服务。但是随着云计算的不断发展，用户发现光有IaaS，虽然简化了对基础设施资源的管理，但是对云计算的终端用户来说通过IaaS只是拿到了一个裸操作系统，要想开发一个软件并部署到云平台上，还需要做很多工作。包括代码的管理、持续集成、自动化测试、交付物管理、应用托管、中间件服务、自动化运维、监控报警、日志处理等等。用户希望通过一个平台能够真正简化开发、测试、部署、运维等工作，使得企业能够真正实现DevOps。

二．PaaS的价值在哪里

在我们接触PaaS之前，我们做开发时需要自己搭建各种环境，包括开发环境、测试环境，上线的时候需要搭建生产环境以及进行各种配置，上线之后还需要进行人工运维。有时候搭建环境是一件很麻烦的事情，比如搭建一个tomcat的集群或者是MySQL主从等。由于各种环境都是人工搭建，难免会出现环境的不一致，导致系统在某个环境下运行地好好的，但是部署到其他环境就无法正常运行的情况。

PaaS可以提供各种标准化或非标准的环境以及各种运维管理功能，用户可以在秒级按需获取各类资源和环境。所以PaaS最大的价值在于解放开发、测试、运维人员。虽然目前还不能完全做到这个程度，但它实实在在地降低了用户对应用软件的交付成本及时间。

通常我们所说的PaaS，包括MoPaaS，主要提供应用部署和托管服务。平台服务涵盖的范围包括，应用开发部署运行环境(如应用开发测试管理/工具等)，服务组件池和管理(数据库、消息队列、缓存等)，应用资源管理(开发运行管理应用、弹性伸缩等)。

三．PaaS的技术选型

其实我们刚接触PaaS的时候，并没有多少可以选择的PaaS技术，所以当Cloudfoundry推出的时候，我们毫不犹豫地选择了Cloudfoundry作为我们构建MoPaaS的基础框架。

最近几年，随着容器技术的飞速发展，比如Docker，目前构建PaaS的技术方案非常多，比如Cloudfoundry、Openshift、Docker+K8s、Docker+mesos+marathon、Cloudify等等，目前这些方案或多或少都在被企业采用。

至于哪种方案最优，个人觉得还是根据用户的具体需求来决定的。比如Cloudfoundry，虽然很多人认为比较重量级，但是在成熟度以及PaaS功能提供方面优于其他方案。再比如要构建一个基于Docker构建PaaS平台，那么像Docker+Mesos+Marathon就是很好的选择。

四．Cloudfoundry基本介绍

Cloud Foundry是一个工业级开源PaaS，它可以部署为一个云，并对外提供多语言多框架、应用运行环境及服务。个人认为，CF的社区相对还是比较活跃的，并且版本迭代比较快，一般1，2周就会发布一个小版本。而且CF在不断的改进和优化自身的架构，到目前为止已经经历了CF V1，CF V2以及CF V3。每一次大版本的发布都对CF进行了性能和架构上的优化。

我们接触PaaS的时候，CloudFoundry还不是很成熟，需要我们自己对CloudFoundry源码进行修改和BUG修复。比如那时候还没有引入容器进行资源隔离，只能通过对应用进程监控以及操作系统用户用户组的方式进行隔离，在这些方面我们需要做很多定制工作。

后来Cloudfoundry V2版本的推出，在稳定性、安全性方面做了大量提升，并且引入容器Warden(CF自带的)进行资源的隔离。这时候容器技术Docker也开始兴起，Docker在某些方面确实可以弥补CF的不足，所以我们在MoPaaS后来的版本中大量使用Docker等容器技术。比如一些轻量级服务的提供，可以通过Docker实现自动化部署及资源隔离和监控。

Cloudfoundry V3版本将推出新的运行时Diego，提供的容器叫Garden，将支持运行Docker镜像。

五．Cloudfoundry架构及相关组件

1、软件路由和软负载均衡

Haproxy、Gorouter：

Router将平台流量分发给特定的组件，通常为Cloud Controller，或者运行在DEA节点上的应用。

2、认证和授权

UAA、Login Server：

UAA与Login Server主要提供用户身份认证管理服务

3、应用生命周期管理

Cloud Controller、Health Manager：

当开发者将一个应用push到cloud foundry后，Cloud Controller会存储应用文件，在数据库中创建应用的元数据记录，并指派DEA节点来stage及运行应用。Cloud Controller同时还维护了组织、空间、服务、服务实例、用户角色等记录信息。

监控应用以确认其运行状态（例如running\stopped\crashed等）、版本以及实例个数。HM9000根据运行应用的DEA返回的心跳（heartbeats）及droplet.exited消息来更新应用的实际运行状态。

确认应用的期望运行状态、版本及实例个数。HM9000从CCDB中获取应用的期望运行状态。

使应用的期望运行状态和实际运行状态一致。例如，如果实际运行的实例个数少于期望运行的实例个数，HM9000就会指示Cloud Controller启动准确的应用实例个数。

指示Cloud Controller修复任何应用状态的差异。

4、应用存储和运行

Blob Store、Dea：

DEA负责管理应用实例，跟踪已启动的应用实例，并广播其运行状态的消息。

Blob store保存了应用代码、Buildpacks（应用依赖的runtime、web server、framework等的集合）以及Droplets（已完成stage的可直接在DEA上运行的应用包）。

5、服务

Service Broker：

应用往往依赖于数据库或第三方服务。

当开发者需要创建一个服务实例并将其与某个应用绑定，该服务的Service Broker负责提供这个服务实例。

例如应用需要使用MySQL数据库服务，MySQL服务的Service Broker负责创建一个MySQL服务实例，并将该服务实例与应用绑定。

6、消息

Nats：

Cloud Foundry使用NATS进行组件间的内部通信。

NATS是一种轻量级的、基于发布-订阅机制的分布式队列消息系统。

7、日志和监控数据

Metrics Collector、App Log Aggregator：

计量数据收集器从各组件收集计量数据。运维人员可以使用这些信息对整个Cloud Foundry平台进行监控。

应用日志汇集器（loggregator）可以将应用日志输出给开发者。

在Cloudfoundry平台上，应用如何被部署运行的？

开发者切换到应用根目录，使用命令行工具cf CLI提交“push”命令。
Cf CLI告知Cloud Controller创建一条该应用的记录。
Cloud Controller将该应用的元数据存储至CCDB（例如应用名、实例个数，以及指定的buildpack等信息）。
Cf CLI将应用文件上传至Cloud Controller。
Cloud Controller将应用原始文件保存到blobstore中。
Cf CLI提交应用“start”命令。
由于应用尚未stage，因此Cloud Controller会从DEA池中选择一个DEA对应用进行stage，负责stage的DEA会根据buildpack中的指令对应用进行stage（stage过程主要是为应用配置相关的语言runtime、web服务器、框架等，最终得到一个可以独立运行的应用包droplet）。
负责stage 的DEA会将stage过程的日志同步输出至cf CLI，开发者可以据此定位stage错误。
负责stage 的DEA将已完成stage的应用打包成一个称为droplet的压缩包，并将该droplet存储至blobstore。
负责stage的DEA向Cloud Controller报告stage工作已完成。
Cloud Controller根据应用配置从DEA池中选择一个或多个DEA来运行已完成stage的应用（在DEA的warden容器中运行droplet）。
负责运行应用的DEA向Cloud Controller报告应用的运行状态。

Buildpack:

Buildpacks为应用提供框架及运行时支持。

Buildpacks通常会检查用户提供的应用代码以确定需要下载哪些依赖，以及该如何配置应用使其能跟绑定的服务进行通信。

当你Push一个应用，Cloud Foundry会自动检测（也可以在push时显式指定）要使用哪个buildpack，并将其安装至运行应用的DEA上。

表中所列为Cloud Foundry system buildpack。

开发者可以通过以下方式使用上述所列之外的buildpack：

1. 改造已有的buildpack；

2. 自己编写buildpack;

3. 使用Cloud Foundry社区提供的Buildpack；

4. 使用Heroku提供的第三方buildpack。

服务：

通过实现一组API被集成进Cloud Foundry 的服务称为受管理的服务。

用户可以按需创建相应的服务实例，并获取使用该服务实例的凭证。

Service Broker标准APIs。

1. 获取服务目录

2. 创建服务实例

3. 绑定服务实例

4. 解绑服务实例

5. 删除服务实例

六．基于Cloudfoundry扩展PaaS功能

虽然Cloudfoundry已经提供了PaaS平台的基础框架，但是如果我们想要基于CF构建一个PaaS平台，并且能够给用户提供PaaS服务的话，还是需要我们做很多的定制化的工作，接下去我就简单介绍一下相关内容:

1、应用运行环境扩展

通过修改和增加Buildpack实现，我们可以对Buildpack进行相关定制，包括修改中间件的版本、配置信息以及buildpack代码来实现更多的功能，比如安装APM的探针。然后将Buildpack打成离线包上传到Cloudfoundry。

如果需要扩展.NET运行环境，可以使用一个开源的.NET插件IronFoundry，因为.NET跟其他运行环境不一样，需要运行在Windows操作系统上面，所以要单独安装一个Windows的Dea（IronFoundry提供），并且将.NET Buildpack添加至Cloudfoundry之后完成扩展。

2、服务中间件扩展

Cloudfoundry对服务中间件集成提供一种标准的接入方式Broker，对中间件部署、运维、监控，Cloudfoundry并没有提供很好的方式解决方案，需要我们自己实现。一些轻量级的中间件服务，如缓存，可以采用Docker进行部署和管理，数据库服务可以采用VM方式部署，然后通过Broker将服务注册到Cloudfoundry。

https://github.com/cloudfoundry-community/spring-service-broker.git

https://github.com/cloudfoundry-samples/github-service-broker-ruby.git

3、可视化操作界面

Cloudfoundry提供了一套标准的Rest API，包括认证授权、组织空间管理、应用服务管理等功能。我们可以通过cloudfoundry提供的SDK可以非常方便的完成对CF的调用。

https://github.com/cloudfoundry/cf-java-client.git

4、应用/服务监控

Cloudfoundry对应用的监控还是做了一些工作的，包括像health_manager，会实时采集应用的监控信息。通过Dea的Varz接口也可以采集到应用的监控信息。如果应用出现不健康的状态，CF会对其进行自动重启。对应用访问日志数据，Cloudfoundry在Gorouter节点上有进行记录，但是如果我们需要采集分析这些日志数据，那么我们需要修改Gorouter，将日志打到日志服务器上。对服务的监控，完全需要我们自己来做，如果只是一般的监控需求，可以采用对容器或者VM监控，如果需要获取服务中间件更加详细的监控数据，可以通过集成APM来实现。

5、弹性伸缩

Cloudfoundry提供了对托管的应用进行弹性伸缩，包括纵向和横向的伸缩，但是只能通过手动的方式，如果需要根据规则和阈值进行自动伸缩，需要我们进行定制开发，通过对应用采集的访问数据、监控数据进行分析，满足阈值条件则进行伸缩。

6、持续集成

Cloudfoundry对开发测试这块并没有提供太多的功能，不过我们可以采用目前比较通用的方案来实现持续集成。

采用Git/SVN托管代码；采用Nexus/Artifactory作为制品仓库；采用Jenkins作为持续集成工具，通过Jenkins提供的插件，可以将代码托管、制品仓库以及PaaS平台进行集成，实现从代码提交到部署上线一整套自动化流程。

7、 TCP协议的支持

Cloudfoundry默认只支持Http(s)协议，如果需要部署一个TCP协议的应用，那么我们需要定制一个TCP_Router。

https://github.com/cloudfoundry-incubator/cf-tcp-router.git

七．Diego介绍

Diego。（DEA in Go），Cloud Foundry的下一代容器管理系统。

在没有Diego的Cloud Foundry平台中，由Cloud Controller负责调度并管理DEA上的应用。

而Diego取代了DEA以及HM9000，并从Cloud Controller那接手调度及管理应用的职责。

Cloud Foundry V3具有全新的 Runtime, Diego。Cloud Foundry（v3) 主要由 CC, UAA, Diego, Loggregator, Gorouter, Buildpacks, 和Services和 Bosh等组件构成。新的Cloud Foundry可以无缝地提供Docker容器服务；在原有支持 Linux 平台的基础上，也将支持 Windows应用。

在新版Cloud Foundry中Diego将取代目前的DEA 。Diego解决了原Cloud Foundry架构功能上的的一些局限，包括：

1）功能间的强耦合。

2）DEA、HM和Cloud Controller之间的三角依赖关系。

3）应用范围只局限于Linux平台，对Windows不原生支持。我们也将在MoPaaS新版中采用CloudFoundry V3版本。

讲师介绍：