协议规范

应用组件（Components）

在 OAM 中，“应用”是由多个概念共同组合而成的。第一个概念是：应用组件（Components），它是整个应用的重要组成部分。所以说，应用组件既可以包括应用运行所依赖的服务：比如 MySQL 数据库，也包括应用服务本身：比如拥有多个副本的 PHP 服务器。开发者可以把他们写的代码”打包“成一个应用组件，然后编写配置文件来描述该组件与其他服务之间的关系。 应用组件的概念，让平台架构师能够将应用分解成一个个可被复用的模块，这种模块化封装应用组成部分的思想，代表了一种构建安全、高可扩展性应用的最佳实践：它通过一个完全分布式的架构模型，实现了应用组件描述和实现的解耦。

应用部署配置文件（Application Configuration）

而为了将这些应用组件描述变成一个真正运行起来的应用，应用运维人员会通过一个专门的、包含了所有应用组件信息的部署配置文件来实例化这个待运行的应用。这个配置文件本身也是 OAM 规范中的一个声明式 API，用来让应用运维人员能够根据开发者或者平台提交的应用描述，实例化出对应的、真正运行起来的应用。

应用运维特征（Traits）

最后一个概念是一组应用运维特征（Traits），它们描述了应用在具体部署环境中的运维特征，比如应用的水平扩展的策略和 Ingress 规则，这些特征对于应用的运维来说非常重要，但它们在不同的部署环境里却往往有着截然不同的实现方式。

举一个简单例子，同样是 Ingress，它在公有云上和本地数据中心的实现可能是完全不同的：前者一般是 SLB 这样的云服务，而后者则可能是一个专门的硬件。这也就意味着针对这两个环境的 Ingress 运维工作，将会有天壤之别。但与此同时，无论是在哪个环境里，这个 Ingress 规则对于应用开发人员来说，可能是完全相同的。

应用特征的设计，让这种关注点分离成为可能：只要这两个环境在 OAM 模型下提供了对 Ingress 这个应用运维特征的实现，那么你的应用就可以使用统一的 Ingress 规则描述无差别的在这两个地方运行起来。而与此同时，这两个环境的基础设施供应商可以继续通过配置这些应用特征的实现，来满足它们各自的运维要求（例如：不同环境里 Ingress 实现在满足合规性和安全性上的差异）。