[譯] 部署 != 釋出 (第二部分)

海龍獨仙發表於2019-02-28

將部署和釋出解耦以降低風險，並解鎖功能強大的工作流

在這系列的第一部分，我解釋了我們在 Turbine Labs 上用於上線、部署、釋出和回滾的定義。我解釋了部署風險和釋出風險之間的差異。而且我還談到了本地釋出 —— 一種常用的用於將生產請求暴露給部署風險的部署/釋出策略。本文中，我將討論解耦部署風險與釋出風險的方法，並簡單介紹一些功能強大的工作流來管理髮布風險。

藍/綠部署（或部署!=釋出）

藍/綠部署涉及到在生產環境已有釋出版本的同時部署新版本。你可以為每種“顏色”使用專用硬體或虛擬機器，並在它們之間交替進行後續部署，也可以使用容器或像 Kubernetes 這樣的容器叢集來管理臨時程式。無論如何，關鍵在於一旦部署了新的（綠色）版本，它不會立即就被髮布 —— 也不會響應生產請求。這些服務仍由目前執行良好的（藍色）版本處理。

在藍/綠部署體系中，釋出通常會涉及到更改負載均衡，在新增新版本的主機之後，移除掉以前執行良好的舊版本。儘管這種方式要比本地部署好的多，它也會有一些侷限性，尤其是在釋出風險方面。回到正題。首先，我們可以看到你可以做到很多非常強大的事情，通過不同的步驟在部署和釋出的時候

什麼都沒有

如果你的部署在迴圈崩潰回退中掛起，或這因為資料庫金鑰錯誤且新部署的服務無法連線，你也不用承受必須要做些什麼事情來挽救的壓力。你的團隊可以在沒有任何壓力的情況下診斷問題或構建另一個新版本，然後進行部署這個新版本。你可以很輕鬆的重複嘗試，直到你部署的版本不再出現問題。與此同時,線上的已釋出 版本還在照常響應生產環境的請求,並且你不必再公司部落格上釋出這次部署失敗了的通知,換句話說,*你的部署風險基本都被掩蓋了

健康檢查和整合測試

當部署與釋出被拆分時，你可以在任何生產環境流量暴露給它之前，針對新部署的版本執行自動化健康檢查和整合測試。我參與過許多事後分析，其中最重要的一點是，在部署好後或者預釋出的時候進行健康檢查等簡單的事情可以有效避免問題暴露在使用者面前。

[譯] 部署 != 釋出 (第二部分)

藍/綠部署在健康檢查和整合測試的時候。如果 v1.2 出現問題，客戶將不會發現這些問題。

更細粒度的暴露釋出風險

由於在引入新的“綠色”主機時，你不一定需要替換現有的“藍色”主機，所以你可以有一些方法來控制新版本生成流量的百分比。例如，如果你有三臺執行已知良好的服務版本，你可以在負載均衡器中再混入一臺“綠色”主機。現在新版本只有 25% 的流量，而不是33%，只要你不是採用替換原有“藍色”主機的情況下。雖然這仍然是相當粗放的版本風險管理，但總比沒有好。

[譯] 部署 != 釋出 (第二部分)

當你使一個“綠色”主機可用時，暴露該版本中任何錯誤流量的百分比則取決於主機的總數。這裡是 33%。

持續釋出

正如我以上的討論，從部署風險角度看，藍/綠部署更好。但當我們考慮釋出風險時，典型的藍/綠設定處理版本的方式並不能為我們提供我們正在尋找的細粒度控制。如果我們同意生產中的每個釋出都是測試（不管同意與否，它一直如此），而我們真正想要的是使用模式匹配規則來分割我們的生產請求，並動態分配任意百分比的流量到我們服務的任何版本。這是一個強大的概念，它是構成複雜釋出工作流的基礎，如內部測試、增量釋出、版本回退和黑暗流量。每篇文章都分為上下兩部分（即將推出！），但我在這裡會大概的介紹一下他們。

內部測試是僅向員工釋出新版本服務的流行技術。通過強大的釋出服務，你可以編寫諸如“將內部員工流量的 50% 傳送到版本為 x.x 例項”的規則。在我的職業生涯中，生產中的內部測試捕獲到了許多我羞於承認的令人尷尬的錯誤。

增量釋出是一個過程，從傳送一些小百分比生產請求到新版本服務開始，同時監視這些請求的效能 —— 錯誤、延遲、成功率等 —— 與之前的產品版本相比而言。當你確信新版本不會出現任何相對上一版本意外行為的時候，你可以增加百分比並重複此過程，直至到達 100%。

回滾是在使用持續性發布系統的時候，將生產中的請求轉發到最後一個執行良好的例項。它速度快、風險低，並且像釋出本身一樣，可以通過細粒度方式有針對地完成。

黑暗流量是一種功能強大的技術。你釋出的系統會複製生產請求，並將一個副本傳送到你的服務執行良好的“明面”上的版本，另一個傳送到新的“暗處”的版本。暴露在“明面”的版本負責實際響應使用者請求。“暗處”的版本也會處理請求，但其響應會被忽略。當您需要在生產環境下測試新軟體時，這非常有效。

在 Turbine Labs 中，我們使用自己的產品 Houston 來完成內部測試，增量釋出、回滾，並很快進行黑暗流量。對我來說，像 Houston 這樣先進的釋出系統對我的日常工作來說是一種革命性改變。如此輕量級、低風險的釋出，使得我可以經常這樣做。作為一個團隊，它以我沒有預料到的方式提高了我們的功能釋出速度和產品質量。我們將在以後的文章中更詳細地介紹我們在 Turbine Labs 的內部發布流程。

結論

在過去的五年中，軟體釋出領域的大部分技術和流程進展 —— 雲端計算、容器、編排框架、持續交付等 —— 都集中在部署上。有了這些進步，為你的服務設計和實現一個健壯的部署流程變得輕而易舉，但設計和實現一個可以支援你服務需求的可靠釋出流程仍然十分困難。Facebook、Twitter 和 Google 致力於設計、實現和持續維護像 Gatekeeper、TFE 和 GFE 這樣成熟的釋出系統。這些系統不僅在服務可靠性方面多次證明了它們的價值，還包括開發者生產、產品速度和使用者體驗方面。

一個先進的釋出系統不僅可以降低部署風險，還可以直接提高產品速度和使用者體驗。

我們開始關注為各種規模的公司提供的便利的產品（Houston、LaunchDarkly）和開源工具（Envoy、Linkerd、Traefik、Istio），以及最近才向大型公司提供的釋出單元和工作流。這些產品和工具使得人們可以更快速地釋出功能，並且使我們有信心不會對使用者體驗產生負面影響。

我是 Turbine Labs 的一名工程師，我們正在構建 Houston —— 一項使構建和監控複雜的實時釋出工作流程變得非常簡單的服務。如果你希望交付更多產品並且花更少的心思，那麼你絕對應該聯絡我們！我們很樂意與你交流。

感謝 Glen Sanford、Mark McBride、Emily Pinkerton、Brook Shelley、Sara 和 Jenn Gillespie 閱讀本文的初稿並提出修改意見。

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章