在雲原生的浪潮下，我們公司的研發模式、代碼釋出模式都發生了更新變化，今天和大家聊聊我們代碼釋出模式的轉變吧。早期使用的是藍綠方式，我們的存證管理系統一共有兩套系統：一套是正在提供服務系統（舊版），标記為綠；另一套是準備釋出的系統（新版），标記為藍。我們可以看到兩套系統都是功能完善的，并且正在運作的系統，隻是系統版本和對外服務情況有差異。正在對外提供服務，接入使用者流量的舊系統是綠色系統，新版本的系統是藍色系統。藍色系統用來做釋出前測試，測試過程中發現任何問題，直接在藍色系統上修改疊代，這個過程不幹擾使用者正在使用的系統。
藍色系統經過反複的測試、修改、驗證，經過多輪的測試和靈活疊代，達到上線标準之後，直接通過SLB将使用者切換到藍色系統, 切換後的一周内，藍綠兩套系統并存，但是使用者通路的已經是藍色系統。這段時間内觀察藍色系統（新系統）工作狀态，如果出現問題，直接切換回綠色系統。經過驗證周期後對外提供服務的藍色系統工作正常，不對外提供服務的綠色系統已經不再需要的時候，藍色系統正式成為對外提供服務系統，成為新的綠色系統。原先的綠色系統可以銷毀，将資源釋放出來，用于部署下一個藍色系統。
随着我們積極擁抱雲原生，我們發現了雖然綠部署能夠簡單快捷實施的前提假設是目标系統是非常内聚的，如果目标系統相當複雜，那麼如何切換、兩套系統的資料是否需要以及如何同步等，都給我們帶來了挑戰。
從上圖中，我們可以看到金絲雀部相比藍綠而言它更加規避風險。你可以階段性的進行，而不用一次性從藍色版本切換到綠色色版本。采用金絲雀部署，你可以在生産環境的基礎設施中小範圍的部署新的應用代碼。一旦應用簽署釋出，隻有少數使用者被路由到它。最大限度的降低影響。
在K8S下，通過k8s service label标簽來實作藍綠釋出、通過Ingress 控制器來實作藍綠釋出、通過Istio來實作藍綠釋出，或者像Istio類似的服務都是可以實作藍綠的。方法很多。現在我們公司主要使用Istio ，因為Istio 有助于降低這些部署的複雜性，并減輕開發團隊的壓力。它是一個完全開源的服務網格，可以透明地分層到現有的分布式應用程式上。它也是一個平台，包括允許它內建到任何日志記錄平台、政策系統的 API。Istio 的多樣化功能集使您能夠成功高效地運作分布式微服務架構，并提供保護、連接配接和監控微服務的統一方法。支援金絲雀部署的智能路由隻是 Istio 的衆多功能之一。
剛才看到了前面小夥伴分享的AppStack。也是一個非常不錯的方式，我們準備攬入我們架構疊代計劃中。給大家安利一下KubeVela 是一個簡單易用且高度可擴充的應用管理平台與核心引擎。KubeVela 是基于 Kubernetes 與 OAM 技術建構的。基于這樣一個引擎，平台團隊可以快速、高效地以 Kubernetes 原生的方式在 KubeVela 中植入任何來自雲原生社群的應用管理能力，進而基于 KubeVela 打造出自己需要的雲原生平台，比如：雲原生資料庫 PaaS、雲原生 AI 平台、甚至 Serverless 服務。當然其中也完美的解決了我們的釋出問題。KubeVela 既是一個端到端、面向全量場景的 OAM Kubernetes 完整實作推薦大家關注喲！