[譯] 部署!=釋出（第二部分）

• 原文地址：Deploy != Release (Part 2)
• 原文作者：Art Gillespie
• 譯文出自：掘金翻譯計劃
• 本文永久連結：github.com/xitu/gold-m…
• 譯者：Starrier
• 校對者：jasonxia23

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

在這系列的第一部分，我解釋了我們在 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 閱讀本文的草稿。

另一個翻譯版本請見：juejin.im/post/5b03d4…

---

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