本文的目的是分享一些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管理的角度看架构
如前文所述,Diego承担了应用管理的功能,将BOSH启动的VM纳入自己的管理令其成为Diego Cell后,保证Diego Cell内App的稳定运行与故障恢复
不像Docker,你需要将应用打包成镜像再通过deployment部署,在CF里,你只需要将代码和配置文件通过CF Cli提交即可,应用对于其他服务(例如数据库,身份等服务)以及对运行环境(例如Java环境,Nodejs环境)的依赖信息包含在配置文件里,会在部署过程中通过下载buildpacks来匹配应用所需的运行环境
而部署一个App的全流程如下图所述:
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命令
可以看出,和使用Garden主要的区别就是减少了文件上传部分,但是对平台用户而言依旧是无感知的。
篇幅有限,先聊聊最核心的服务发现与注册,以及一键部署应用这个CF的主要特色,之后再聊聊CF其他能力的机制例如App instance如何保持在设定的数量,如何让第三方供应商向所有CF用户提供能力的Service机制等
关于本文内容有任何问题或见解,欢迎在评论区留下你的想法,如果时间紧迫,也可以直接联系到我 arthuryang1996@foxmail.com,感谢你的时间