cloudfoundry
负载均衡
对Router做负载均衡不属于Cloud Foundry的实现范围。Cloud Foundry只须保证所有Router都可以处理任何请求，而管理员可用DNS实现负载均衡，也可部署专用硬件来实现，或者简单点，弄个Nginx做负载均衡。
迁移
- 支持实例的迁移,开发者可以很方便的把自己的应用部署到cloudfoundry上
- Router是PaaS平台中至关重要的一个组件，它在内存中维护了一张路由表，记录了域名与实例的对应关系，所谓的实例自动迁移，靠得就是这张路由表，某实例宕掉了，就从路由表中剔除，新实例创建了，就加入路由表
![49374ad0.png]()
监控
nsync, BBS, and Cell Reps，承担持续监控应用程序的状态，调整应用程序的期望状态，启动和停止进程，保证应用程序的可用性。
左边是最终用户，其他则是应用程序多个实例，它跑在分布式的虚拟机上，这些实例或许会宕机而不可用。nsync 接收到来自Cloud Controller的用户想要扩展App的消息后，它在Diego BBS 数据库的DesiredLRP 数据结构中写入实例的数量。BBS采用convergence进程监控DesiredLRP和 ActualLRP的值，它启动或停止应用程序实例来匹配DesiredLRP和 ActualLRP的值。Cell Rep监控containers 和提供ActualLRP值。
![9e5b4e74.png]()
Cloud foundry中metrics Collector组件监控CF部署和运行，生成系统日志。App Log Aggregator生成应用程序日志，实时监视整个云平台和其应用程序的部署。
自动化部署
bosh 部署工具
备份
安装BBR工具
BBR连接到BBR命令调用中指定的部署/控制器中的实例。 使用这些连接，BBR收集有关应为备份中的每个阶段运行哪些脚本的信息。然后，BBR分阶段运行备份前备份，备份和后备份解锁脚本。同一阶段的脚本都在下一个阶段开始之前完成。 例如，BBR在触发任何备份脚本之前触发并等待所有预备份锁脚本的完成。 备份阶段中的脚本可以按任何顺序发生。 发布作者可以在锁定和解锁阶段配置脚本的排序，但任何不受该排序约束的脚本也可以在其阶段内以任何顺序发生。BBR将备份工件耗尽并转移到跳转框，操作员可以将生成的工件传输到存储，并使用它来恢复BOSH部署或BOSH Director。
备份流程
openshift vs cloudfoundry
- 架构
OpenShift的架构是复合的，而Cloud Foundry是专有的 - 但两者都是模块化的。这意味着两个平台都由多个组件组成，这些组件协同工作以提供PaaS的组合功能。但是，Red Hat主要使用现有的开源产品来实现核心功能（例如Kubernetes和EFK），尽管它确实使用了一组专门开发的OpenShift组件。 Cloud Foundry的核心组件主要是专有产品（例如Diego和Garden），尽管最近转向Kubernetes确实添加了一些外部开源组件。
- 构建应用
构建机制是Cloud Foundry和OpenShift的不同之处。
- OpenShift使用一种名为Source-To-Image（S2I）的方法，该方法从存储在git存储库中的源代码构建Docker镜像（后者反过来隐藏了开发人员对Dockerfiles或Docker构建的使用）。这将构建过程与生成的图像分开。从非常高级的角度来看，构建过程会创建一个构建或编译代码的构建器映像，然后将其部署到最终映像。这样，得到的图像尽可能小。
- 使用Cloud Foundry，重点是生成的应用程序。它附带了一组系统构建包（最初由Heroku创建），用于编译（或发布）大量常用语言（如Java，.NET和Python）。当推送应用程序时，Cloud Foundry会检查应用程序并决定在配置时使用哪个buildpack。本质上，buildpack是一组脚本，在运行时会生成自包含的应用程序，包括例如下载依赖项。 Buildpacks可能是更灵活的方法，而Source-To-Image导致更多的便携式应用程序。
- 命令行
这里只是一个小差异：Cloud Foundry有两个命令行工具，Bosh（用于管理平台）和CF（用于部署应用程序）。 使用OpenShift，这些操作组合在一个工具中：OC。
