小熊科技|如何基于K8s构建下一代DevOps平台？( 三 ) 阿里妹导读：OAM是阿里巴巴与微软联合

难以理解，必须通过界面可视化透出
无法复用，几乎不具备原子化能力
无法协作，只能内部封闭生态使用

三 OAM应用模型的技术原理
Component组件
OAM中常见的概念是Component组件，完全从研发角度定义的待部署单元。下图右侧是YAML中Component的例子，其中黄色部分可以灵活自定义。 OAM中会定义标准的架构ContaineriseWorkload ，表示工作负载部分，里面是待部署单元的具体描述。这时就可以解决关注点分离的问题，帮助应用侧工程师去掉很多细节，只需要关心开发需要关注的端口号，镜像等等。

应对挑战一，在OAM中可以定义数据库表达资源需要使用云资源， Workload中可以根据自己的需要定义不同的组件，包括基于虚拟机的应用、或者老的Function应用。组件是应用开发者关心的。

Trait
如果只是组件，组合起来就可以构建简单的应用。如果关心应用运维的问题， OAM中有Trait的概念，指的是在原来组件的基础上附加一些特征。特征指的是运维的能力，如手动扩缩容能力、外部访问能力、发布、负载均衡。弹性扩缩容、基于流量的管理等等。通过OAM的Trait可以很灵活的得到插件化扩充能力。不同的component绑定不同的特征。

Scope
Component ， Trait以及所有组装起来的Application Configuration就是OAM中的三种主要的概念。但当多个组件共同协作时应该如何处理？OAM中有个边界Scope的概念，是一种特殊的Trait ，将多个Component组合在一起，共享一组资源组， CPU等特征用Scope表示，拓展多个组件的共同特征。
四 OAM加持下的下一代DevOps技术
OAM：以应用为中心的分层模型
OAM是以应用为中心的分层模型，首先需要运行在服务端的OAM解释器，对于YAML的读取需要通过OAM解释器。 OAM提供Trait ， Component让用户填写，编成APP Config 。 APP Config通过OAM解释器具备Deployment ， Ingress ， HPA或者云资源等能力。这种方法可以将研发、运维基于基础设施进行分层，研发关心Component ，运维关心Trait ，基础设施通过OAM解释器提供各种能力，与K8s紧密结合，对其应用概念做了补充。

分层
模块化
可复用

快速的纳入K8s生态已有Operater能力
OAM可以快速的纳入K8s生态已有的Operater能力，下图左边的Component中是一个CRD的实例，右边是Trait中的CRD的实例，中间表示Component底下的Workload和Trait分别对应了K8s自定义资源的能力。如果想要使用K8s中的某些能力，只需要在Trait中写入相应的字段即可。

OAM框架解决组件依赖关系和启动顺序
OAM框架解决组件依赖关系和启动顺序。 OAM Runtime ， OAM解释器会将组件依赖关系和启动顺序处理好，下图中Component之间有dependency关系， Trait与Component之间有preComponent或者postComponent等关系。