二、 SREWorks的OAM落地实践
SREWorks作为阿里大数据运维平台，在设计之初，云原生应用管理在满足内部业务需求时候，遇到了这样一些问题和挑战：
• 需要应用异地多活，避免单Region故障。
• 需要环境分离，区分开发测试与生产环境。
• 需要一定的集群扩展性，突破单一集群容量上限。
• 需要多云部署，避免受限于单一云底座，或降低成本。
• 开发者花费了太多的时间在基础设施的细节中。机器从哪来，网络环境怎么样，中间件资源/DNS/负载均衡怎么生成，服务怎么适配到各种底座等等。或者更进一步，每个开发者都是YAML工程师，哪怕都是K8S，但每个底座让你提交的YAML都不一样。
• 可扩展性低。有越来越多的平台or底座在尝试去支撑各种类型需求的业务，但一般来说，应用本身对于平台的诉求会很快超越平台的能力。
• 云服务供应商绑定。当选择了一个固定的底座后，应用交付的方方面面将会打上这个底座的烙印，当想尝试转到另一个底座的时候难于登天。
当SREWorks-Appmanager基于OAM实现了底层引擎，驱动各个服务的开发与交付流程之后，这些问题基本都有了答案，让我们来看看这些问题是如何被解决的。
1. 应用模块插拔
如上图的YAML所示：
• 通过运维能力（trait）注入进行运维能力的增强，使部署者不用关注太多底座基础设施的细节。
• 通过各种组件（compent）的插拔和参数变量（parameterValues）的定制来满足应用的功能需求。
• 通过工作（workflow）和策略（policy）来定制部署策略，满足灰度发布、金丝雀发布等多样的发布策略。
2. 应用插件机制
上面提到了各种组件（compent）和运维能力（trait），那么这些能力是从哪里来的呢？这些也是用插件机制增强出来的，可以看下图：
在Appmanager中预先定好了各种能力的接口（interface），一个插件只要实现这些接口（interface）就能够将能力增强到Appmanager中。用户可以基于这个机制来满足各种能力需求，比如将一个Flink服务制作成一个组件（compent），用户只要寥寥几行在YAML中加上这个组件，就能在自己应用中瞬间就有了流计算以及其管理能力。
3. 应用组件Addon体系
在将一个应用做组件化拆解的时候，我们会遇到一个问题，像MySQL、Redis这种要如何拆。拆成一个普通的组件（compent）的话，有些资源少的场景，每个应用分配一个独享MySQL实例会导致资源不够分；拆成一个运维特征（trait）的话，每次申请一个实例的逻辑太重，不太符合一个特征的轻量级行为。所以我们将这类组件定义为addon。
4. 应用组件构建
在OAM模型定义中没有包含构建，在Appmanager中，我们对此进行了增强，将应用的生命周期延展到构建环节，用户可以基于源代码直接构建出组件，进而组成一个完整应用模型。下面是构建过程的拓扑：
总结一下，SREWorks中基于OAM的Appmanager基本满足了如下的核心诉求：
• 构建：易于获取且一致的开发、测试环境；易于发现和使用的API。
• 交付：安全、可灰度的发布环境；可回滚的版本管理能力。
• 运行：异常行为可观测；运行稳定且能够自愈。
后续文章我们会分享更多的Kubernetes科普文章，请大家持续关注～
文章参考
《OAM深入解读（一）：OAM为云原生应用带来哪些价值？》
