通过sidecar分离关注点解决命令脚本的维护和稳定性

为了解决命令脚本的维护和稳定性，我们进入了第三阶段，声明式——通过配置来表达环境，定义环境。声明性描述提供了环境的确定性表示。

以k8s为例，我们举个例子看看如何进行环境声明

上图是K8S的简单架构。左上角是K8S master，左下角是node。master有几个组件：scheduler、ControllerManager、APIserver和Etcd。Etcd 是分布式存储，配置信息在 Etcd 中。Node 是物理机或虚拟机。每个 Node 上都会有多个 pod，并且会在上面运行许多容器。

我们知道，K8S 的最小单位是一个 pod，里面包含容器和各种网络存储，这些都是通过 pod 声明来描述的。应用声明后，具体的事情在控制器中处理。

通过 sidecar 分离关注点

我们编写一个应用程序。这个应用中有很多代码其实和业务无关，而是包含了很多服务治理的代码，比如日志、监控、限流、断路器等。这些代码占比很大，而这些代码的维护者和应用开发者不一定是同一群人。对于服务治理相关的代码，很多公司都会有专门的团队负责维护和升级软件老是脚本错误，类似于阿里巴巴的中间件团队。传统上软件老是脚本错误，我们需要升级和重新部署应用程序来升级服务治理能力。然而，在云原生时代，应用开发者希望只关注应用业务代码，而将与服务治理相关的代码放在其他容器中。业务容器和服务治理容器通常安排在同一个 pod 中，但服务治理容器的管理、开发和发布与应用开发者无关，这些是边车容器。Sidecar 容器实现了关注点分离。应用程序开发人员、中间件开发人员以及运维相关的开发人员都可以有自己的关注点。

我们以两个角色为例。一个是业务开发者，他关心的是应用容器，所以当它发布时，他的重点是应用容器。二是企业的SRE。他的关注点往往是sidecar的各种服务管理容器，比如logagent的日志级别和采样率是否合理。

使用 sidecar，业务开发人员和 SRE 的关注点是分开的。这种分离的另一个好处是中间件的下沉以sidecar的方式进行管理。一旦需要升级相应的中间件，业务代码就不需要更改或发布，只需要发布sidecar即可。

我们之前提到，一致的环境需要具有 3 个组件：相同的工件、相同的运行时上下文和相同的编排规则。同一个运行上下文的本质是里面的配置应该是一致的。一开始我们用文档来告诉我们如何管理环境，然后我们用脚本，最后我们用环境声明。

但是，以声明方式定义环境并不完美。举一个具体的例子，在应用运行时需要进行一些相应的配置。中间件、基础资源、CPU、存储等都需要配置。这会面临一个很大的问题——环境相关的配置太多了。

与环境相关的配置太多，如何管理？

通过 IaC 定义环境

为了解决这个问题，业界采用了IaC（InfrastructureasCode）的概念。早期云机房上架时使用IaC。比如新机器过来的时候，安装的是centos7系统，里面需要特定的DNS服务。这将定义一个声明文件并将其发送到像 saltstack 这样的工具。现在整个环境都是用基础设施来描述的，所以包括中间件在内的整个环境的资源都是基础设施，范围比以前宽了很多。

从配置上看，我们有应用配置、运维配置、基础设施运维配置，甚至是软件生产过程的配置。我们把应用代码和IaC代码放在两个库中（也有放在一个库中的，各有优缺点，这里不展开评价）。

比如上图中，在IaCRepo中，我们放了动态配置（即运行时配置）、BaaS配置（基础设施，如数据库、中间件存储、消息队列等）、监控配置（如监控粒度、采样频率）、发布配置等。所有配置都在代码库中声明，所有基于此声明组织的环境都是一致的。

凡事有利有弊，那么以 IaC 方式管理环境会带来哪些新挑战？

首先是“灵活性的代价”。因为所有的配置都是松散的文本，缺乏统一的聚合根，所以修改器需要了解这些配置背后对应的依赖关系。例如，如果一个配置项设置为on，会启用限流，但必须与特定的configMap配合使用；比如启用了一个 Ingress 插件，但是如果没有启用另一个 Rollout 插件，它就不能正常工作；例如，HPA 和 CronHPA 不能同时使用。使用，会有冲突。由于编写的灵活性，会导致无限的组合，而它们组合的后果往往是在运行时才发现的。

二是知识成本。IaC以文本界面的形式向开发者提供一个环境的所有配置，但是很多配置项需要专业背景，比如运维相关的策略，比如监控配置方法等，值得IaC本身的学习成本，经常吓倒许多开发人员。

为了解决这个问题，阿里巴巴和微软联合发布了OAM模型，以应用为统一维度，对IaC中包含的各种资源和角色进行分类聚合。

首先，OAM引入了应用的概念，聚合了应用的各种IaC配置，解决了它的依赖问题。

其次，OAM将IaC的用户划分为三个角色：应用开发者、应用运维、基础设施运维，彼此关注的问题分离。

OAM对IaC的定义和维护进行了抽象和简化，降低了开发者的学习和使用成本。

综上所述，我们认为环境管理的最终状态是软件定义的不可变环境，目前我们认为其最佳实践是基于 OAM 模型的以应用为中心的 IaC 声明。

云效云原生应用管理平台AppStack是一个基于OAM的应用交付平台。在云效应AppStack中，企业可以通过应用编排、占位符、变量等声明式定义，实现一套编排和多环境差异化部署。版本和基线实现环境可以一键上拉和回滚。