[譯] 部署!=發佈（第二部分）

• 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。