1. 定义
Cloud Foundry是业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题。
2.PaaS
PaaS，平台即服务。是云计算的一种服务形式。其实并不是一个非常新的概念，像GAE、SAE很早就提供了类似这样的服务。不过在很长一段时间内，PaaS接受程度不高，在跟客户谈及云计算时，普遍都认为云计算就是IaaS，即基础设施服务。但是随着云计算的不断发展，用户发现光有IaaS，虽然简化了对基础设施资源的管理，但是对云计算的终端用户来说通过IaaS只是拿到了一个裸操作系统，要想开发一个软件并部署到云平台上，还需要做很多工作。包括代码的管理、持续集成、自动化测试、交付物管理、应用托管、中间件服务、自动化运维、监控报警、日志处理等等。用户希望通过一个平台能够真正简化开发、测试、部署、运维等工作，使得企业能够真正实现DevOps。
3. CloudFoundary基本介绍
Cloud Foundry是一个工业级开源PaaS，它可以部署为一个云，并对外提供多语言多框架、应用运行环境及服务。CF的社区相对还是比较活跃的，并且版本迭代比较快，一般1，2周就会发布一个小版本。而且CF在不断的改进和优化自身的架构，到目前为止已经经历了CF V1，CF V2以及CF V3。每一次大版本的发布都对CF进行了性能和架构上的优化。
4.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 的服务称为受管理的服务。
用户可以按需创建相应的服务实例，并获取使用该服务实例的凭证。
ss
Service Broker标准APIs。
1. 获取服务目录
2. 创建服务实例
3. 绑定服务实例
4. 解绑服务实例
5. 删除服务实例
References:
