大家好，我是崔力强，我在云效担任Flow流水线的开发工作。近年来，SaaS化布置形状的产品的私有化布置需求越来越多，比方云效自身就有私有化布置的版别。为了能够有用且高效地一起办理SaaS版别和私有化版别的发布进程，云效团队也结合云原生的基础设施和标准化东西（比方helm）进行了一系列的探索和实践，并将其间一些通能的才干进行了产品化。本文会从问题自身出发，解说处理问题的思路，及怎么经过“DIY”的方法来完成这套思路。终究解说云效AppStack产品是怎么对这些实践进行产品化，并使其更容易规模化。

---

>  SaaS服务在版别化上的先天不足

软件交给有两种根本场景：面向大版别的交给和面向SaaS的晋级更新。

一般来讲，提供本地或私有化布置的软件都归于第一种。比方Jenkins刚刚发布了2.319.2版别，那么这个版别里包括了什么样的特性便是清晰的。你拿着这个装置包在任何一台机器上都能够从头装置得到这些功用。

而互联网产品很大一部分是SaaS化的，即只有一套布置，供一切用户运用。软件的保护者更关心的并不是我的产品是否能够在任何一个数据中心从头搭建出来，而是怎么在现有的这个运转中的体系上经过更新某个组件或许服务来快速的交给一个特性。

修正搜图

图1：SaaS服务交给和大版别交给的交给节奏

从上述的示意图，能够形象地看到两种交互方法的差异。

面向大版别的交给会清晰该版别中包括的特性以及交给时刻， 版别的发布时刻间隔一般比较长，需求对版别的全新装置以及不同版别之间的晋级装置进行详尽的测验。

面向SaaS的晋级更新，交给的频率比较高，能够快速呼应市场上的需求，但相应的规划性比较差。一起因为“可重复装置才干”的优先级要低于“快速运用已有的服务和才干交给新特性”，因而在架构上或许会逐步发生复杂的依赖，然后进一步地使得全新布置这套服务变的越来越困难。

但是现实并不对错黑即白的。有或许一套互联网产品在开展了若干年之后有了进军海外的需求，就需求一起布置海外站， 或许需求做私有化布置。此时该怎么办呢？是献身效率悉数改成版别化的交给，仍是以SaaS服务的交给节奏为主？假如是后者，那么每个私有化大版别发布前的几天，团队需求从纷乱的SaaS布置中厘清需求将哪些服务的什么版别（比方镜像版别）归入到这个大版别中，进行版别验证，以及潜在的或许要对代码和装备进行调整。

修正搜图

图2：一起兼顾SaaS服务和大版别交给两种交给方法

假定一个月出一个大版别，那么在上图的2月1号到2月7号这七天里都或许发生了什么呢？

1. 或许在对焦，大版别里要求的功用是否都完成了，假如没有就要拉分支继续做。
2. SaaS化版别里边的一些功用或许是私有化布置不需求的，这时需求加一些开关使其不行见，需求改代码。

1. 在这一个月的迭代里，技能架构发生的调整，删除了一个微服务，又新加了一个微服务，大版别需求做相应的调整。
2. 在这一个月的迭代里，运用的装备项也发生了改变，需求在大版别中做相应调整。

其间：

1和2归于版别规划和测验左移的问题。本文暂时不聊。

3和4便是能够经过技能来处理的问题了，本文接下来的部分会要点评论怎么高效的处理这两类问题。

>   统一版别格局

处理上述问题的核心技能便是要有一个统一的版别格局，无论是SaaS版别仍是大版别都应该运用相同的版别格局。

在此基础之上，要做到

1、版别应该是一个完整的体系描绘，包括了一切的镜像，装备等一切启动服务所需求的描绘。然后能够完成根据某个版别，就能够一键拉起一个新的可用的环境。
2、每个环境有一个基线的概念，也便是和环境的当时运转态保持一致的那个版别。
修正搜图

图3：版别中包括的内容

3、在环境中，每个服务仍是能够独立更新的。每一次某个服务在某个环境上（比方服务A的生产环境）的发布，尽管只修正了体系中的一个服务，但也应该主动生成整个环境的一个新的版别。

4、每个环境的装备应该集中化起来，而不是在各个服务中分别保护。在服务数量比较多的情况下，这种方法能够大大地下降版别保护的成本。尤其是在新建环境的场景下，因为装备集中化了，需求修正什么就愈加的一望而知。一般在装备项集中化之后，还会看到另一个优点，那便是重复装备少了，因为一个体系中的不同服务多多少少都会共用一些装备，假如要单独在服务中保护，就不行避免的出现重复。

修正搜图

图4：任何制品和装备的改变都引起大版别的更新

5、对环境的任何改变都应该终究反映在版别中。只有这样才干确保你做的改变，能够原样的在另一个环境，另外一家客户的机房中被正确的执行，比方DDL和DML。

6、一切的日常发布行为，本质上便是针对版别改变这个动作的一些场景化封装。比方对某一个服务做改变，那就能够创建一个独立的CD流水线进行镜像构建，创建暂时版别，更新环境，将暂时版别写入基线。而进行某个装备改变，便是修正基线，然后运用基线到环境。

修正搜图

图5：环绕版别构建日常构建发布等工作流

>  环绕Helm进行版别办理和构建布置

在不同的基础设施之上，上述的思路能够有不同的完成方法。

而在K8S基础设施上，Helm Chart便是版别格局的不贰之选。

Helm的核心概念包括：

1. 一套K8S资源文件的安排方法，资源文件中能够运用变量占位符
2. 变量办理机制，运用helm提供的机制，能够很容易的将整个大版别的变量提取出来放到统一的文件来保护，这就符合了咱们前面提到的需求

1. 一个渲染引擎，在运转时，将变量替换到文件中，并进一步运用到集群中
2. 一套布置历史办理的机制，比方update/rollback等

下面看一个典型的比方：

修正搜图

图6：根据Helm构建版别

得益于K8S资源的强壮描绘才干，形成一个“版别”的各种组成部分都能够很好的描绘，比方：

1. 体系的域名是什么？
2. 不同的URL应该路由到哪个服务？

1. 能够将Flyway和相关的SQL迁移脚本打包成一个Job，来做DDL。
2. 能够将其他的需求对体系进行数据初始化的任务打包成一个Job。

在此之上，再加上helm提供的模板化才干，就能够清楚的将对一个环境的描绘分为两个部分：

1. 不变的部分，也便是那些模板化的资源文件，不同的环境会共用这部分描绘。
2. 抽取出来的归于某个环境的变量。

因而上图中的蓝色的框内的便是“测验环境”的一个版别。

helm chart作为版别，能够看到，本质上便是一堆描绘文件。这些描绘文件能够以目录的方式存在，也能够以tgz包的方式存在。因为面向SaaS的交给的改变频率会十分高，因而每次打一个tgz包就会显得十分的臃肿。所以笔者会采取目录的方式，那么什么是承载目录，并且还能完成版别序列技才干的技能呢，很显然便是Git啦。

咱们把上面思路中的那个环绕版别进行一系列研制活动那种图翻译到Helm和Git上，便是这样：

修正搜图

图7：环绕helm chart构建日常构建发布等工作流至此，运用现成的一些标准化东西，就完成了一套版别机制，及环绕版别机制的开发流程。

在这套流程下：

1. 面向SaaS的交给流程，依然十分敏捷，且一起会主动的保护好各个环境的基线。
2. 因为各个环境都经过helm chart中的模板文件“耦合”在了一起，当你修正一个环境时分，天然就需求考虑其他环境怎么办，因而一致性也很好的得到了确保。任何时刻，我都能够运用某个环境的基线来重建这个环境。

1. 也能够根据一个环境的基线，快速地创建出另一个环境的基线，只需求简略的修正一下环境的变量文件即可。

>  一些小细节

在实际运用这套计划的时分，其实仍是许多小细节，需求渐渐优化。这里就简略列两个：

1. 一切的镜像的tag包括日期和commitId，在后续定位问题时分，能够经过这些信息快速的找到对应的代码，进行排查。
2. 在上述的CD流水线中更新一个环境之前，确保基线与运转态的一致性，假如不一致，则不进行更新，避免有人修正了基线的代码库，意外的被你捎带上了环境。

>  规模化的采用最佳实践

上述计划最大的优点，便是采用的都是标准的组件，具有很大的灵活性，和可定制性。

但这一起也是这个计划的害处，便是太灵活了，各种最佳实践也需求渐渐探索和调整。在调整的进程中或许会发现许多类似上面提到的“小细节”，需求进行标准或许封装。假如进行规模化的推行，那么就要求每个团队都有一个很了解这些东西的同事。假如无法找到这么多了解东西的同是，那就能够考虑对上述的思路进行产品化，使得大部分的开发人员都能够低成本的follow最佳实践。

云效的AppStack，就着眼处理这个问题，经过白屏化运用编列、版别办理、以及企业级运用编列模板等产品才干帮助下降开源东西运用门槛，提供了开箱即用的最佳实践。

1. 运用编列。即上述的根据helm来描绘多环境装备的产品化完成。
2. 版别和基线。有了版别和基线，就能够快速地进行回滚和根据某个版别一键拉起环境等操作。

1. 集成发布流水线。将上文中提到的常见的日常工作流程和版别结合在一起，避免每个团队分别装备。