簡介：為了能夠有效且高效地同時管理SaaS版本和私有化版本的發布過程，云效團隊也結合云原生的基礎設施和標準化工具（比如helm）進行了一系列的探索和實踐，并將其中一些通能的能力進行了產品化。本文從問題本身出發，講解解決問題的思路，及如何通過“DIY”的方式來實現這套思路。

大家好，我是崔力強，我在云效負責Flow流水線的開發工作。近年來，SaaS化部署形態的產品的私有化部署需求越來越多，比如云效自身就有私有化部署的版本。為了能夠有效且高效地同時管理SaaS版本和私有化版本的發布過程，云效團隊也結合云原生的基礎設施和標準化工具（比如helm）進行了一系列的探索和實踐，并將其中一些通能的能力進行了產品化。本文會從問題本身出發，講解解決問題的思路，及如何通過“DIY”的方式來實現這套思路。最終講解云效AppStack產品是如何對這些實踐進行產品化，并使其更容易規模化。

SaaS服務在版本化上的先天不足

軟件交付有兩種基本場景：面向大版本的交付和面向SaaS的升級更新。

通常來講，提供本地或私有化部署的軟件都屬于第一種。比如Jenkins剛剛發布了2.319.2版本，那么這個版本里包含了什么樣的特性就是明確的。你拿著這個安裝包在任何一臺機器上都可以從頭安裝得到這些功能。

而互聯網產品很大一部分是SaaS化的，即只有一套部署，供所有用戶使用。軟件的維護者更關心的并不是我的產品是否可以在任何一個數據中心從頭搭建出來，而是如何在現有的這個運行中的系統上通過更新某個組件或者服務來快速的交付一個特性。

圖1：SaaS服務交付和大版本交付的交付節奏

從上述的示意圖，可以形象地看到兩種交互方式的差異。

面向大版本的交付會明確該版本中包含的特性以及交付時間， 版本的發布時間間隔通常比較長，需要對版本的全新安裝以及不同版本之間的升級安裝進行詳盡的測試。

面向SaaS的升級更新，交付的頻率比較高，可以快速響應市場上的需求，但相應的規劃性比較差。同時因為“可重復安裝能力”的優先級要低于“快速利用已有的服務和能力交付新特性”，因此在架構上可能會逐步產生復雜的依賴，從而進一步地使得全新部署這套服務變的越來越困難。

然而現實并不是非黑即白的。有可能一套互聯網產品在發展了若干年之后有了進軍海外的需求，就需要同時部署海外站， 或者需要做私有化部署。此時該怎么辦呢？是犧牲效率全部改成版本化的交付，還是以SaaS服務的交付節奏為主？如果是后者，那么每個私有化大版本發布前的幾天，團隊需要從紛亂的SaaS部署中厘清需要將哪些服務的什么版本（比如鏡像版本）納入到這個大版本中，進行版本驗證，以及潛在的可能要對代碼和配置進行調整。

圖2：同時兼顧SaaS服務和大版本交付兩種交付方式

假設一個月出一個大版本，那么在上圖的2月1號到2月7號這七天里都可能發生了什么呢？

可能在對焦，大版本里要求的功能是否都完成了，如果沒有就要拉分支繼續做。

SaaS化版本里面的一些功能可能是私有化部署不需要的，這時需要加一些開關使其不可見，需要改代碼。

在這一個月的迭代里，技術架構發生的調整，刪除了一個微服務，又新加了一個微服務，大版本需要做相應的調整。

在這一個月的迭代里，應用的配置項也發生了變更，需要在大版本中做相應調整。

其中：

1和2屬于版本規劃和測試左移的問題。本文暫時不聊。

3和4就是可以通過技術來解決的問題了，本文接下來的部分會重點討論如何高效的解決這兩類問題。

統一版本格式

解決上述問題的核心技術就是要有一個統一的版本格式，無論是SaaS版本還是大版本都應該使用相同的版本格式。

在此基礎之上，要做到

1、版本應該是一個完整的系統描述，包含了所有的鏡像，配置等一切啟動服務所需要的描述。從而能夠實現基于某個版本，就可以一鍵拉起一個新的可用的環境。

2、每個環境有一個基線的概念，也就是和環境的當前運行態保持一致的那個版本。

圖3：版本中包含的內容

3、在環境中，每個服務還是可以獨立更新的。每一次某個服務在某個環境上（比如服務A的生產環境）的發布，盡管只修改了系統中的一個服務，但也應該自動生成整個環境的一個新的版本。

4、每個環境的配置應該集中化起來，而不是在各個服務中分別維護。在服務數量比較多的情況下，這種方式可以大大地降低版本維護的成本。尤其是在新建環境的場景下，由于配置集中化了，需要修改什么就更加的一目了然。通常在配置項集中化之后，還會看到另一個好處，那就是重復配置少了，因為一個系統中的不同服務多多少少都會共用一些配置，如果要單獨在服務中維護，就不可避免的出現重復。

圖4：任何制品和配置的變更都引起大版本的更新

5、對環境的任何變更都應該最終反映在版本中。只有這樣才能保證你做的變更，可以原樣的在另一個環境，另外一家客戶的機房中被正確的執行，比如DDL和DML。

6、所有的日常發布行為，本質上就是針對版本變更這個動作的一些場景化封裝。比如對某一個服務做變更，那就可以創建一個獨立的CD流水線進行鏡像構建，創建臨時版本，更新環境，將臨時版本寫入基線。而進行某個配置變更，就是修改基線，然后應用基線到環境。

圖5：圍繞版本構建日常構建發布等工作流

圍繞Helm進行版本管理和構建部署

在不同的基礎設施之上，上述的思路可以有不同的實現方式。

而在K8S基礎設施上，Helm Chart就是版本格式的不二之選。

Helm的核心概念包括：

一套K8S資源文件的組織方式，資源文件中可以使用變量占位符

變量管理機制，使用helm提供的機制，可以很容易的將整個大版本的變量提取出來放到統一的文件來維護，這就契合了我們前面提到的需求

一個渲染引擎，在運行時，將變量替換到文件中，并進一步應用到集群中

一套部署歷史管理的機制，比如update/rollback等

下面看一個典型的例子：

圖6：基于Helm構建版本

得益于K8S資源的強大描述能力，形成一個“版本”的各種組成部分都可以很好的描述，比如：

系統的域名是什么？

不同的URL應該路由到哪個服務？

可以將Flyway和相關的SQL遷移腳本打包成一個Job，來做DDL。

可以將其他的需要對系統進行數據初始化的任務打包成一個Job。

在此之上，再加上helm提供的模板化能力，就可以清楚的將對一個環境的描述分為兩個部分：

不變的部分，也就是那些模板化的資源文件，不同的環境會共用這部分描述。

抽取出來的屬于某個環境的變量。

因此上圖中的藍色的框內的就是“測試環境”的一個版本。

helm chart作為版本，可以看到，本質上就是一堆描述文件。這些描述文件可以以目錄的形式存在，也可以以tgz包的形式存在。因為面向SaaS的交付的變更頻率會非常高，因此每次打一個tgz包就會顯得非常的臃腫。所以筆者會采取目錄的形式，那么什么是承載目錄，并且還能實現版本序列技能力的技術呢，很顯然就是Git啦。

我們把上面思路中的那個圍繞版本進行一系列研發活動那種圖翻譯到Helm和Git上，就是這樣：

圖7：圍繞helm chart構建日常構建發布等工作流

至此，利用現成的一些標準化工具，就實現了一套版本機制，及圍繞版本機制的開發流程。

在這套流程下：

面向SaaS的交付流程，仍然非常敏捷，且同時會自動的維護好各個環境的基線。

由于各個環境都通過helm chart中的模板文件“耦合”在了一起，當你修改一個環境時候，自然就需要考慮其他環境怎么辦，因此一致性也很好的得到了保證。任何時刻，我都可以使用某個環境的基線來重建這個環境。

也可以基于一個環境的基線，快速地創建出另一個環境的基線，只需要簡單的修改一下環境的變量文件即可。

一些小細節

在實際使用這套方案的時候，其實還是很多小細節，需要慢慢優化。這里就簡單列兩個：

所有的鏡像的tag包含日期和commitId，在后續定位問題時候，可以通過這些信息快速的找到對應的代碼，進行排查。

在上述的CD流水線中更新一個環境之前，確保基線與運行態的一致性，如果不一致，則不進行更新，避免有人修改了基線的代碼庫，意外的被你捎帶上了環境。

規模化的采納最佳實踐

上述方案最大的好處，就是采納的都是標準的組件，具有很大的靈活性，和可定制性。

但這同時也是這個方案的壞處，就是太靈活了，各種最佳實踐也需要慢慢摸索和調整。在調整的過程中可能會發現很多類似上面提到的“小細節”，需要進行規范或者封裝。如果進行規模化的推廣，那么就要求每個團隊都有一個很熟悉這些工具的同事。如果無法找到這么多熟悉工具的同是，那就可以考慮對上述的思路進行產品化，使得大部分的開發人員都可以低成本的follow最佳實踐。

云效的AppStack，就著眼解決這個問題，通過白屏化應用編排、版本管理、以及企業級應用編排模板等產品能力幫助降低開源工具使用門檻，提供了開箱即用的最佳實踐。

應用編排。即上述的基于helm來描述多環境配置的產品化實現。

版本和基線。有了版本和基線，就可以快速地進行回滾和基于某個版本一鍵拉起環境等操作。

集成發布流水線。將上文中提到的常見的日常工作流程和版本結合在一起，避免每個團隊分別配置。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的SaaS服务的私有化部署，这样做最高效｜云效工程师指北的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。