可以看出，和使用Garden主要的区别就是减少了文件上传部分，但是对平台用户而言依旧是无感知的。
本文的目的是分享一些Cloud Foundry的架构组成，内容主要来自 Cloud Foundry 官方文档，掺杂了一些个人的理解，阅读时间约为15分钟。
Cloud Foundry概况介绍在此：Link
如果您对BTP(SAP基于Cloud Foundry构建的商用PaaS平台)感兴趣，BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容
作为一款云上的PaaS平台，CF为云应用的部署带来了极大的便利，只需要在代码外添加配置文件即可通过一个cf push命令将应用部署到云端，同时令应用具有可伸缩，高可用等特性。而背后是怎么样的架构支撑起了这些功能呢？本文将做简单的分享
1.核心组件概览
首先我们来简单列举一下CF的主要组件，以及他们的基本概念：
上图是从平台管理面上来看的，比较复杂，但是我们可以快速的发现CC占据了平台的中心位置，其全名为Cloud Controller，是我们从外部向CF发出管理请求的唯一目的地，有些类似K8S中的kube-apiserver，其携带了一个数据库，叫做CC_DB，支持Mysql或PostgreSQL，保存了大部分的orgs, spaces, services, user role等元数据。
而官网文档的Overview里，最先出现的三个组件就是CC，BOSH和Gorouter，其中BOSH主要负责从零开始基于资源池创建虚拟机，进而运行起CF的一个个组件；而Gorouter负责将外部来的请求进行转发，CC则作为大管家来传递各种命令。
Diego则具体负责应用管理，其管理的单位为Diego cell，即一个VM，VM内由Garden管理容器（Garden最后会通过Garden RunC backend来真正的完成对容器的操作，类似Docker之于RunC）
2.从服务发现与注册角度看架构
而由于服务发现与注册，以及负载均衡是分布式部署最基础的能力，我接下来先从这个角度进行分析：
1.平台管理组件间：
平台管理组件的服务发现与注册主要依旧由BOSH manifest控制，平台启动后BOSH manifest会存有管理组件的路由信息，这些组件路由信息的变化也会由BOSH manifest保存。
2.App与平台管理组件：
而App启动后，首先App需要管理组件的路由信息，这些信息在BOSH manifest内，由Route Registrar提供给NATS, 这样应用就可以通过NATS获取到管理组件的路由信息了
3.App间：
同时App需要知道其他App的路由信息，而每一个Diego Cell都会有一个Route Emitter组件向外广播其最新的路由信息并获取其他App的路由信息，这样Diego BBS，NATS，Routing API就都拥有了App的路由信息
4.外来请求与App及管理组件：
最后CF可能会收到外来请求，请求到达CC之前根据请求的类型(TCP或HTTP)会先到达Gorouter（Gorouter从NATS处获取管理组件及App的路由信息，进行短期存储）或者TCP Router（从Routing API获取管理和App组件），再被转发到App，CC或者管理组件（请求也有可能是来调用管理API的）
而App的路由信息产生变化（App下线，新增Instance等）时，每个DiegoCell内的Route emitter每隔二十秒周期性的向NATS或Routing API发送消息，以注册和取消注册到该单元的应用程序实例的路由。（服务注册）
3.从具体App管理的角度看架构
不像Docker，你需要将应用打包成镜像再通过deployment部署，在CF里，你只需要将代码和配置文件通过CF Cli提交即可，应用对于其他服务（例如数据库，身份等服务）以及对运行环境（例如Java环境，Nodejs环境）的依赖信息包含在配置文件里，会在部署过程中通过下载buildpacks来匹配应用所需的运行环境
1.开发人员运行cf push
2.CF CLI告诉CC为App创建记录
3.CC存储App的元数据。该元数据可以包括应用程序名称、实例数、构建包和其他有关应用程序的信息
4.此步骤包括：
CF CLI从CC请求资源匹配。
CF CLI上载App源文件，忽略资源缓存中已存在的任何App文件。
CC将上传的App文件与资源缓存中的文件相结合，以创建App包。
5.CC将App包存储在blobstore中
6.CF CLI发出启动应用程序的请求。
7.此步骤包括：
CC向Diego发出转移请求。
Diego安排了一个Diego Cell来运行Stage任务。
该任务下载buildpacks
该任务使用buildpacks来编译和Stage应用程序。
8.Diego Cell对暂存过程的输出进行流式传输（您可能需要查看输出以解决暂存问题）
9.此步骤包括：
该任务使用编译并暂存的App创建一个tarball或droplet。
Diego Cell将droplet存储在Blobstore中（此处droplet即为最终启动前的应用包）
该任务将buildpacks上传到Blobstore，以便下次应用程序暂存时使用。
10.Diego BBS向CC报告转移已完成（如果转移未在15分钟内完成，则会失败）
11.Diego将App安排为一个或多个Diego Cells上的LRP（LRP=Long Running Process,实际上会运行在Garden启动的容器里）
12.Diego Cells向CC报告App的状态。
从以上流程中不难看出，CC是平台大管家，Diego负责管应用（容器则由Garden管理），这样就能达成友好的部署体验，但是buildpacks的选择是有限的，虽然支持大多数主流应用环境，但终究不如Docker等基于image的选择多，所以Diego目前也支持部署基于Docker的容器:
下图说明了转移Docker映像过程中涉及的步骤和组件。Docker镜像的暂存过程包括一名开发人员和以下组件：CF CLI、CC、CCDB、Diego Cell（Staging）和Diego Cell（Running）
1.开发人员在CF CLI执行cf push命令
2.CF CLI到CC创建记录
3.将image从CC转移到CCDB
4.将Diego Cell（Staging）的Stage输出流式传输给Developer看
5.从Diego Cell获取元数据（暂存）到CC
6.将元数据从CC存储到CCDB
7.从CC向Diego Cell（Running）提交LRP的Run Start命令
篇幅有限，先聊聊最核心的服务发现与注册，以及一键部署应用这个CF的主要特色，之后再聊聊CF其他能力的机制例如App instance如何保持在设定的数量，如何让第三方供应商向所有CF用户提供能力的Service机制等
关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果时间紧迫，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间
- SAP Managed Tags:
