另外有一些可选参数，应用发布时候有几个实例，以及应用的URL，包括应用在什么位置，应用发布以后，可以通过ARPDATE命令对应用进行动态更改，可以通过stop命令停止。另外可以通过底下这组命令动态的更新应用设置、获取应用信息，比如可以通过VMC这条命令动态的给你的应用分配你的内存，另外可以通过VMC MAP UL设置一个UL地址，通过VMC命令可以了解应用的运行日志，可以得到相关的运行状态。可以在云平台里动态创建服务，可以指定服务的名字，以及是否现在就需要绑定某个应用，另外还可以动态删除服务，包括可以设置一些用户口令、安全管理，另外了解Cloud Foundy跑的各种应用信息。

　　Cloud Foundy逻辑结构图，最底层是Cloud Foundy底层所运行的各种云平台，也提供一些其它接口，跑到一些别的云平台上，内核有这么几个部分：一个Router，所有应用可以分配到具体的应用实例上，进行服务状态的跟踪，用户访问所有应用，目前来说通过基于Web的方式访问，还提供两组客户管理工具，一种通过VMC命令行工具，大家也可以装spring的插件，通过插件也可以进行控制。

　　Cloud Foundy内部架构图，就像前面介绍的那样，其实就是由几个主要部件组成，一个Router，程序入口点，然后有一组DA，每一个应用或者多个应用可以跑在一个DA上，对云平台进行状态的监控，保证所有服务和应用都在正确状态下，如果不是在正确状态下，会通过日志或者其它形式反馈给管理者和用户。

　　下面介绍一下Cloud Foundy各个部件组成情况和功能：第一Router，主要作用将外部的URL映射到内部某个应用实例上，也是整个Cloud Foundy EPI入口点，掉用也是通过Router进行的，还实现了负载均衡，将外部请求平均的发送到一个应用的各个实例上。Cloud Contruler，负责监控系统中所有部件的状态变化，并确保所有部件是在一个正确运行状态下，负责将整个应用可以绑定到特定服务，并且解除绑定，可以控制整个服务应用和各个服务的生命周期，例如通过UMC发布一个应用时候，由Cloud Foundy动态决定将这个应用发布到哪一个DA环境上。

　　Health Manger，负责监控应用是否处于健康的状态，通过各种通信协议，会不间断的访问各个应用、实例和运行环境，判断应用和服务是否处于健康状态，如果某个应用实例，在真正企业级云平台运行上，云可能架构在物理上分布很广，应用完全有可能因为各种各样原因崩溃，Health Manger可以对整个状态进行记录，如果发现每个应用实例因为某种原因崩溃会自动启动一个新的实例，当然如果发现内部某中算法可以检测到应用频繁崩溃，会对这个应用做特殊标记，并且尝试不再重新启动该应用实例，通过插件可以动态获取这些信息，并进行跟踪和评估。

　　DEA，Cloud Foundy系统会维护DEA池，每一个DEA可以理解成就是VM级别的应用容器，每个DEA虚拟机上实际可以跑一个应用，也可以跑多个应用，而且可以跑多种不同应用，完全取决于DEA上支持的服务和运行环境，DEA有个重要作用，提供受限的操作系统环境，保证各种框架和应用程序完全在企业定义的各种安全权限下正确的运行，很多企业运行云平台上最担心的一件事情就是安全，通过DEA可以进行有效的安全设定，保证你的应用不会超过企业设定好的安全策略。

　　服务，Cloud Foundy支持各种服务，也可以理解成拓展了Cloud Foundy的功能，目前来说Cloud Foundy已经集成了很多流行的服务，另外为了得到更多的支持，还提供了一些接口，用户可以很容易的嵌入自己的服务，动态绑定到各个应用上，Cloud Foundy上各种服务可以被多个应用共享，另外Cloud Foundy提供的接口使得各个服务可以以统一的方式绑定到Cloud Foundy，并且以统一的方式进行监控和管理。

　　目前来说，Cloud Foundy当前支持的一些运行环境框架包括在运行环境级别现在支持Java应用，支持ruby，大家来自的领域不同，有些可能没有听说过，java 、ruby因此是比较流行的两个，在不同的运行环境下，也支持一些流行的框架，比如Java社区目前支持spring，还包括一些别的，像LIFT等等，在今后几年里，将会有越来越多的开发环境和服务被支持，其实它的一个主要目标就是希望能够支持当前所有流行的服务和运行环境，这是Cloud Foundy未来几年大力推广和希望大家广泛参与支持的一个计划。

　　Cloud Foundy开发应用的简洁性，第一个简单的例子是比较典型的Web应用，可能开发一个spring外部应用，或者用ruby，不管什么，一个基本的应用就是前端有一个系统负载均衡，后端有多个应用实例，多个应用实例完全跨越整个物理网络，可能分散在多个节点上，后端大家共享同一个数据库，这是比较典型的企业级Web应用。如果传统的开发方式，可能用户需要配置很多东西，比如需要配置用户名、口令，而且需要指定绑定位置，具体位置在什么地方，另外启动多少个最大线程数有多少，另外并发能够支持多少，然后缓存数量等等，包括配置文件的位置，作为一个开发者来说，除了关注你业务逻辑本身一些东西之外，可能要花很多时间学习和了解各种不同服务后端的配置情况，这样才能把完整的应用正确的运行起来。

　　在Cloud Foundy下，Cloud Foundy由统一管理人员配置和管理，对于开发人员来说，使用Cloud Foundy变得非常简单，后端URL地址是云所在的URL地址，指定这么一条命令表明后面的应用也好、服务也好都定在这个平台上，输入用户名和口令以后可以进入系统，应用需要内存64兆，需要本地物理位置，至于应用的各个实例发布到你的云平台后端的哪一个机器上对用户来说都是完全透明的，可以动态创建实例，并且把实例动态绑定到应用上。经过一段时间运行，如果动态升级应用也很简单，至于升级过程中需要的程序暂停或者需要加锁、状态更新这些都由Cloud Foundy帮你做，不用关心内部发生的情况。

　　这是另外一个示例，具有伸缩性需求的复杂应用，分布式的应用，前端有一堆应用，是在一个池里边，有多个实例，中间通过消息中间件跟后端应用进行通信，中间大家都通过开源KV服务进行共享，在这种应用情况下，如果用Cloud Foundy对于一个开发者来说也是很简单的，启动八个实例，每个实例需要内存64兆，对后端程序来说，启动两个实例，每一个实例需要256兆内存，至于每一个实例跑哪一台物理机上对用户完全透明，可以动态创建多个服务，以及指定出这些服务需要绑定到哪个应用上，最终在一些应用之后可以动态的对整个应用进行升级。