1 轻诉架构
1.1 应用之云飘啊飘
我们知道Cloud Foundry （CF）是一个PaaS平台。 CF命令行（CLI）作为开始部署使用CF云平台的用户来说，一个轻度的CF CLI的解释会是一个比较好的入门选择。所以飘在我们最前面的，目前很多企业工业云平台背后就是Cloud Foundry云平台。
那为什么很多企业云后面还有CF云呢？为什么选Cloud Foundry呢？因为企业工业云是要将一个可以绑定工业数字化模型的PaaS云，那么底层需要选择一个通用的PaaS云，而CF就是一个极好的PaaS云。 PaaS是要帮屏蔽了管理中间件和运行部分，让你集中在应用和数据。底层还有IaaS云，帮你屏蔽了管理操作系统。
其实除了这三层之外，还有SaaS层，但是为了适应不同的工业领域的应用开发，不能走到SaaS层，固定好数据和应用，所以只能到PaaS层：
那为什么选Cloud Foundry，而不选其他的PaaS平台呢？首先我们看一下目前有哪些知名的PaaS平台，不知名的，肯定不太靠谱了。我们看到在PaaS层面上，除了Docker和Cloud Foundry，其他的分布式Amazon， IBM， Microsoft，RedHat和SAP的平台。相比较而言， Amazon， IBM， Microsoft和SAP都有自己的工业业务，一定程度是也可以是很多企业的竞争对手。所以大部分企业工业云不能选由竞争对手主导的平台作为主流。再比较Docker，Cloud Foundry，和RedHat的OpenShift。那么Cloud Foundry在可扩展，稳定性方面的优势就比较明显了。所以选用了EMC投资的Pivotal Software。
CF是方便你管理应用和数据的PaaS云平台。那么，一般一个在线服务，会有三层：用户层，服务层，和资源层（数据层）。
1.2 不同架构高呀高
那么对应到三层里面的服务层，要做好用户层的需求，有个经典的MVC模型，划分出模型Model，来搞业务逻辑，视图View来搞展示界面，还有控制器Controller，来匹配模型和视图。这样，控制器就显得尤为重要。
这样我们对应不同的URL访问，就需要匹配不同的Controller (MVC实例)。
举个例子，一个订单应用里面，你要提供展示订单和添加订单的功能。
时候，人们把这个匹配的功能独立出来，提出了路由Route的功能。
随着路由功能的增强，他成为了新型MVC模型的一部分，使得不同服务可以使用相同的Controller，同一个服务也可以使用不同的Controller。
很快，人们又发现，一个Controller需要的有些子功能还需要其他服务Service的支持。
那么如何把Controller和后台一些服务绑定，这就需要有服务代理Service Broker。
最明显的是数据服务Data Service：
这样，我们把上面的应用，除了Controller之外的路由Router，服务代理Service Broker，引入了Application的体系里面。
其实， Controller还是会有相应的日志输出的，这里用于经常服务日志Log的一个组件就是信息总线Message Bus。
其实在Cloud Foundry里面，一般情况下， Controller通过Message Bus，把状态发给Health Manager，然后由Health Manager把日志信息发给总线的。
这样在CF里面， Health Manager就把状态信息发给总线，而总线会把信息发给Heath Monitor进行展示。
除了上面这些比较集中的功能， CF还提供对用户登录的管理，由两部分组成，登录服务器Login Server 和用户账户认证UAA User Account Authentication。
UAA比较好的解决了浏览器， 用户管理，应用和服务之间一次认证， 全部授权的机制。
其中， OAuth2，SCIM， OpenID等技术还是可以单独深挖的， 就不做讲解了。
这样综合上面三方面的内容，我们可以大致得到CF提供了几大模块，这些模块分成7层模型，路由层routing，用户认证层authentication，应用生命期层app lifecycle，应用存储运行层app storage & execution，服务层 services，信息层messaging，日志和性能仪表层metrics and logging。
他们之间的简单通信，就得到了CF的架构，譬如：
1.UAA Login和CloudController之间。
2.Cloud Controller和Health Manager（HM9000）和NATS Message Bus 和Metrics Controller之间。
3.Cloud Controller和Service Broker之间。
4.另外，运行虚拟机也有细分， DEA Droplet Execution,Agent Warden Server等构成了运行虚拟机作为应用执行环境：
举个PHP应用的例子，我们结合架构图在看一把， DEA里面运行好多节点，每个节点有个PHP的运行，然后由Warden管理这些节点的生命周期，而他们的访问由Router导入访问，Cloud Controller （CC）把状态发给Health Manager （HM9000），而每个Controller要访问的数据库服务有服务代理Broker管理。
1.3 应用执行Go吧Go
其实，在最新的CF架构里面，对执行架构进行了升级，从DEA Droplet Execution Agent架构升级到了Diego架构。 其中最大的升级就是把开发语言从Ruby换成了Go，同时更名了对应的名称。核心的，虚拟机的生命期管理，从Warden变成了Garden； Controller的运行从DEA 节点Node 变成了 Diego Cell； Controller之间的协调器从DEA变成了Diego Brain。如下表所示：
还可以看到原来DEA是和Cloud Controller绑定的，限制Diego和Cloud Controller解耦合了。 这样我们来看一下整个组件有哪些变化：
从上图，我们看到，应用运行从DEA框架换成Diego框架之后，Message Bus 和 Health Manager 也对应进行了变化。直观来说就是把Health Manager的功能进一步独立细分了，把一部分功能独立成信息层的功能了。从Health Manager (HM9000) 变成了 nsync, BBS, 和 Cell Rep 更多组件了。
至此，我们再来详细看一下，前面讲的Controller， Router， Health Manager， Message Bus， Application Execution是如何变化的？
可以看到：
1.Controller不是再和Health Manager联系了，是和nsync进行交互。整个组成Controller API，CAPI模块。
2.Router和Controller也不是和NATS Message Bus交互了，而是用bbs替换了NATS的功能。
3.引入auction机制到Diego Brain来作为协调机制
另外一个不太容易看到的特性是：
4.Warden只能运行Linux容器，而Garden提供了各种操作系统的虚拟机。
综上，我们把Cloud Foundry的架构轻度解释了一遍，这样是为了后面我们把命令行和这些部分对应起来。
2.轻诉命令行
命令行操作的安装就跳过了，可以参考https://docs.cloudfoundry.org/cf-cli/install-go-cli.html。
2.1 登录进入CF
你需要制定API ，然后再login：
你也可以把上面两步，写成一步，给cf login加一个 -a 参数，之后，你可以把你自己的APP 推Push到云上去。
然后，你可以通过target来指定一个组织Organization和一个空间Space。
当然，cf api本身如果没有参数的话，就可以作为查询当前API。
登录到空间小结：
2.2 空间Space管理
一般来说你需要注册一个这个组织的用户，然后获得对应Space的全新Permission。一旦进入到Space，你就可以推送APP和创建服务了。
譬如下面定义了一个student1-org的组织，里面有development， production和test 三个空间，每个空间都有apps和services的两大部分。
空间管理小结：
2.3 应用APP管理
首先，你要部署一个APP，通过cfpush命令：
创建完成后，一般你需要调整硬盘和内存大小，这时候你需要利用cf scale命令。
另外， 你需要启动，重启，停止app的命令。
当然，万一你忘记了app的名字和相关信息，你还需要查询所有app，和单个app的详细信息。
应用管理小结：
2.4 服务Service管理
在每个Space里面，除了你可以创建管理APP之外，非常类似你可以创建Service。 你可以管理Service，更新和删除。注意这里更新是使用update，而不是scale。你可以绑定或者解绑定某个服务到某个APP。
最后你也可以cf services查询全部服务列表和单个服务的信息。
不过Service和App最大的不同是， App是本地推送上去的。而Service是注册使用的。 CF提供的服务来自Service marketplace，市场。 只有市场上有的服务，你才能创建一个实例。 这样你就要通过cf marketplace来查询有哪些服务可以被创建实例。
理解service命令之后，我们可以将前面提到的Controller的component功能就可以和service broker 链接起来，这里我们可以看一下创建服务之后，查询服务状态的过程中， controller是怎么和service broker进行交互的流程。
服务管理小结：
2.5 路由Route管理
路由管理就是把某个域名下，对应的子域名 domain/subdomain （host + domain），或者路径path映射到对应的空间Space，同时还可以指定对应的应用apps和类型type。
譬如我们常用的空间有开发空间，测试空间，和产品空间。 那么一旦创建了这个空间的路由之后，那么对应的访问就会映射到这个空间来。
如果再绑定路由和应用之后，那么就可以根据应用找到对应的controller来处理请求了。 当然也可以删除路由，或者解开对应应用的映射。
也可以查询当前空间下的所有的路由。
路由管理小结：
2.6 域名Domain管理
传统意义上的域名是指DNS的不同级别。
但是这里的域名是指在一个组织org里面全面能够识别的全部域名。
这里域名是对应到组织org的，并且可以创建夸组织的域名。有创建域名，就必然有删除域名。 另外就是查询所有的域名，如下图所示。
域名管理小结：
2.7 环境变量Environment管理
除了上面空间，应用，服务，路由，域名之外。还有很重要求的就是环境变量和日志的管理。
环境变量比较简单，就是创建（set），删除（unset）和查询（list）。
日志有两种，一种是logs，另外一种是events。他们的区别就是logs一般是对某些变量的值进行输出，记录。 而events一般对生命周期的变化进行记录。
环境变量和日志管理小结：
除了上述重要的部署命令（deployment）还有很多管理的命令（admin），详细可以参考：https://docs.cloudfoundry.org/cf-cli/cf-help.html
3 轻诉蓝绿部署
3.1 蓝绿之分
我们知道路由可以随意和应用绑定，解绑定的。这种便利带来了部署上的蓝绿之分。 蓝色是传统的部署方式。就是我们把一个应用创建之后，绑定好了对应的路由和日志，等等。 但是这样，在线操作的时候，有个问题，线上的服务更新的时候，可能需要宕机。
而绿色部署就是先创建了另外一个应有，这是一个更新应有，当我们需要更新，直接把路由改变到新的服务。 然后再停止就的应用。这样就会带来零宕机时间。
举个例子，我们会把需要更新的应用先映射的demo-time-temp的hostname上面去，然后再通过路由切换成demo-time，这样就实现无宕机更替，更为绿色。
有了蓝绿运行方式之后， 我们也很容易想想做A/B Test的时候， 就会变得非常方便。 我们不需要对用户进行区分了， 直接在路由中把部分访问路由到部署的服务， 而不要把原服务停掉。
3.2 运行虚拟之分
其实真正在运行时候，还有一个staging的步骤。就是虚拟机准备好容器开始跑运行程序了。而具体到不同运行环境/容器来staging的时候，又会不一样。
例如利用buildpack和docker。buildpack就需要有metadata和运行文件的准备工作。
如果从DevOps的角度来看Buildpack和容器Container的对比，其实Container就需要开发者也提供。如果我们简单来比较Buildpack和Docker的话:
1.从上传维护的角度，上传一个containerimage，要比上传一堆代码文件要更为简单。
2.从配置的角度，由于buildpack和Cloudfoundry结合更为紧密，好多自动化配置做的更为完善，但是docker和Cloudfoundry结合就没有那么精密。
同时buildpack提供部分安全监控的端口，但是docker就没有。
3.从应用的角度，如果一个独立运行的应用，那么配置好了docker之后，独立运行，会比buildpack更为简单，正如上图所演示的，启动步骤也要少。
但是如果需要部署一个分布式，或者需要同步信息的时候，docker带来的配置就会变得比buildpack麻烦。
4.从随意迁移的角度， docker可能更为广泛的被应用，Buildpack主要是cloudfoundry在应用。
5.从类比的角度， buildpack好比修好地面轻轨，什么都自动化好了，你只要应用就好了。 而docker好比开个SUV，就算路面不好，你也能翻山越岭。
6.从开源的角度，不管是build pack还是docker，都不是一个标准的app容器，只有建立业界容器标准，这样buildpack带来自动化配置的优势，和docker带来的迁移优势就能都有了。但是，这还不在路上...
小结
这样，我们再介绍命令行和运行之后，又对应的介绍了很多Cloud Foundry里面的概念，譬如组织Organization，空间Space，应用App，路由Route，域Domain，服务Service。但是还有很多概念没有介绍， Security Group， Cluster， Manager等等。希望大家在用到时候进一步搞明白。
这样我们从一个web应用出发，说明了Cloud Foundry是如何为这个应用建立需要的环境的。之后，再介绍了部分核心的命令行，与前面说明对应起来。谢谢大家~~~
参考：
https://docs.cloudfoundry.org/cf-cli/cf-help.html
http://heidloff.net/article/developer-perspective-on-cloud-foundry-vs-docker-on-bluemix
https://dzone.com/articles/buildpacks-and-containers
https://docs.pivotal.io/pivotalcf/1-9/services/api.html
https://docs.cloudfoundry.org/concepts/how-applications-are-staged.html
http://seoyek.com/cloud-foundry-architecture/
https://selftaughtcoders.com/model-view-controller-mvc-web-application/
