共计 3830 个字符，预计需要花费 10 分钟才能阅读完成。
专栏策动|雅纯
意愿编辑|jimmy、吕瑞星
软件交付的终态是提供稳固可预期的零碎，要做到这一点，咱们须要确保：一、软件制品的一致性；二、运行环境的一致性。
第 3 讲咱们分享了如何保障软件制品的一致性，这一讲咱们来谈谈如何保障环境的一致性。
运行环境一致性的指标是环境可预期、稳固、低成本。其中低成本比拟要害，因为环境资源的老本个别比拟高。
咱们能够将运行环境分为 3 局部：制品、执行引擎和编排规定。
要保障制品的一致性，第一是保障代码及其依赖的一致性；第二是保障构建环境的一致性；最初是保障构建脚本的一致性。保障环境的一致性，也蕴含了三点：
- 利用的一致性，比方统一的容器镜像；
- 容器运行所需的上下文的一致性，比方统一的数据配置等；
- 编排规定的一致性，须要保障编排执行雷同的规定，比方雷同容器部署规定、雷同节点散布规定、雷同备份规定等。
保障这 3 点，部署实现之后才会造成统一的可运行环境。然而事实当中，环境还是会有很多其它的问题，比方：
- 配置文件中有好多监控之类的配置，对于使用者来说，不晓得配置的具体作用，须要批改时不知如何设置。
- 测试的时候依赖的环境常常产生问题，消耗大量期待和排查工夫。比如说依赖的 API 常常出问题，排查修复可能须要期待依赖方很久，导致测试工作无奈持续进行。
- 新环境的搭建很耗时。搭建一个新的环境是很苦楚的事件，比方国际化团队，常常要搭建新的站点，而每搭一个新的环境就要消耗一整天的工夫是很苦楚的。
- 利用在本地无奈运行。比方因为缺某个资源导致利用无奈失常运行。
- 配置环境须要小心翼翼，可能呈现配置脱漏。每次配环境的时候须要很小心，特地是当环境配置由多人配合时，会呈现配置抵触，导致程序无奈运行，须要全链路排查解决。
这里咱们简略列了五个常见的问题，它们的本源都是环境不足清晰的定义：不分明环境的具体内容、对环境搭建过程的认知含糊。
环境的清晰定义，包含环境蕴含什么制品、这些制品如何部署等。那么环境治理的终态是什么呢？
当制品雷同、运行上下文雷同，并且资源数据是一样的状况下，基于雷同的编排规定，环境就应该是统一的。同时，环境能够由软件来定义和申明。这是咱们认为的环境治理的终态，简略来说，即软件定义的不可变环境。软件定义的不可变环境，能够纳入版本治理，保障环境首先是定义明确的，其次是有明确版本的。
环境治理的 3 个阶段
阶段一：说明书
环境治理的第一个阶段是阐明文档，这点置信很多人都经验过。当咱们在做一个我的项目或产品时，会写整个产品的部署说明书、阐明文档、降级文档等各种文档。但文档很难保障实用，也不肯定是最新的、精确的。每次咱们去现场交付时，都会遇到一些文档里没有形容的问题。这时候还得打电话确认，是否有脱漏什么。用文档或说明书去治理环境，存在很大的弊病，所以咱们想到了用命令的形式去治理。
阶段二：命令
第二阶段，咱们通过命令的形式，写了各种 shell、Python 脚本，把相干命令组合在一起。之前咱们在做一个产品的私有化交付的时候，一开始的做法就是用脚本去治理环境，因为开启一个新环境切实太苦楚了，须要花很多工夫改参数、找包、配 IP 等，效率太低。所以咱们写了脚本来治理，用脚本代替了文档。
然而用脚本治理环境也存在很多问题。咱们要应答各种各样的环境，同一个工作在不同的场景里，命令组合可能是不一样的，所以脚本会越来越多，保护脚本的老本也越来越高。
阶段三：申明
为了解决命令脚本的保护和稳定性问题，咱们进入了第三个阶段，申明式——通过配置的形式表白环境，把环境定义进去。申明式的形容提供了环境的确定性表白。
以 k8s 为例，咱们以一个例子来看，如何做环境申明
上图是 K8S 的简略架构，左上角是 K8S 的 master，左下角是 node，master 有好几个组件：scheduler、ControllerManager、APIserver，以及 Etcd。Etcd 是一个分布式存储，配置信息都在 Etcd 外面。Node 是物理机或者虚拟机，在每一个 Node 下面会有多个 pod，下面会运行很多的容器。
咱们晓得 K8S 的最小单元是 pod，外面有容器，还有各种网络存储等，通过 pod 申明去形容。申明被 apply 后，具体的事件在 controller 外面解决。
通过 sidecar 拆散关注点
咱们写一个利用，这个利用外面大量的代码其实与业务无关，而是蕴含很多服务治理的代码，例如日志、监控、限流、熔断等。这些代码占了很大的比重，而且这些代码的维护者和利用开发者不肯定是同一批人。服务治理相干的代码，在很多企业会有专门的团队负责保护和降级，相似阿里的中间件团队。传统的状况下，咱们须要降级并重新部署利用能力降级服务治理能力。然而在云原生时代，利用开发者心愿仅关注利用业务代码，服务治理相干的代码放在其余的容器外面，业务容器和服务治理容器通常会编排在同一个 pod 外面，然而服务治理容器的治理、开发、公布都跟利用开发者没有关系，这些就是 sidecar 容器。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 引入了利用（Application）的概念，将利用的各类 IaC 配置都聚合在一起，解决其依赖问题。
其次，OAM 将 IaC 的使用者拆散为：利用开发者、利用运维、基础设施运维三大角色，彼此的关注点进行了拆散。
OAM 形象和简化了 IaC 的定义和保护形式，升高开发者的学习和应用老本。
总结一下，咱们认为，环境治理的终态是软件定义的不可变环境，而当下，它的最佳实际咱们认为是基于 OAM 模型的、以利用为外围的 IaC 申明。
云效云原生利用治理平台 AppStack 正是基于 OAM 的利用交付平台，企业在云效 AppStack，能够通过利用编排、占位符、变量等申明式定义，实现一套编排多环境差异化部署，同时基于版本和基线实现环境一键拉起、一键回滚。感兴趣的同学点下方链接即可收费应用。
[
https://www.aliyun.com/produc…](https://www.aliyun.com/produc…)
下篇预报：环境治理的指标是心愿有一个稳固、可预期、低成本的环境。在软件开发中，咱们会波及到开发、测试、生产各种环境，如何保障这些环境的稳固、可预期、低成本呢？下一节咱们将进一步开展，敬请期待。
浏览上篇：这样才是代码治理和 Commit 的正确姿态！