彈性微服務的4種部署策略

Manuel Zapf Charles

與傳統架構相比，開發人員使用微服務構建應用程序速度會更快、更靈活。但是，每一次修改代碼仍然會帶來風險，如果沒有發現并解決代碼質量問題，就為潛在的失敗埋下了伏筆。為了降低這類風險，應用程序開發團隊應實施現代的云原生路由策略，以便更方便地測試危險因素，并確保應用程序能真正準備好部署到產品環境中。

以下4種部署策略使用路由技術安全地引入新的服務和特性、測試功能、改進迭代、發現并消除漏洞等等。這些方法共同構成了一個虛擬工具箱，應用程序開發團隊可以使用它們來降低開發和部署微服務應用程序時的風險。

金絲雀部署

“金絲雀”的命名源于一種歷史上的習慣做法，人們把實際的鳥類放到煤礦里，目的是查看空氣質量對人類是否安全，金絲雀部署是以最小影響和最小風險測試實際產品部署的一種方式。所謂的金絲雀是一個服務的候選版本，它按照一定百分比來采集輸入請求的子集（比如1%），嘗試一下新的特性或者構建方法。然后，開發團隊可以檢查結果，如果進展順利，可逐步將部署增加到100%的服務器或者節點。如果不順利，則在檢查和調試有問題的代碼時，可以利用金絲雀部署快速重定向數據流。

金絲雀部署可以通過與負責處理流入用戶數據流的邊緣路由組件集成來實現。以這種方式路由數據流可以確保在正式推出新服務之前驗證新服務是否可行。如果不可行，就會被退回以解決問題，在準備好后再進行新一輪金絲雀部署測試。

A/B測試

A/B測試與金絲雀部署類似，但有一個重要的區別。金絲雀部署偏重于發現漏洞和性能瓶頸，而A/B測試則偏重于衡量用戶對新應用程序特性的接受程度。例如，開發人員可能想知道新特性是否受用戶歡迎，是否容易被發現，或者UI功能是否正常等等。

這種模式使用軟件路由來激活并測試不同數據流區段的某些特性，把新特性呈現給指定百分比的數據流，或者有限的組。A和B路由區段可能會將數據流發送到軟件的不同內部開發版本，服務實例甚至能使用相同的軟件內部開發版本，但具有不同的配置屬性（就像在編排器或者其他地方指定的那樣）。

藍-綠部署

藍-綠部署模式涉及到并行操作兩個產品環境：一個用于當前穩定版本（藍色），另一個用于在下一版本上準備和執行測試（綠色）。這種策略使更新后的軟件版本能夠以一種易于重復的方式來發布。DevOps團隊可以使用這一方法，通過CI/CD（Continuous Integration and Delivery）管道自動執行新版本的發布。

采用藍-綠策略，現有實例在處理產品數據流時，開發人員可以同時部署新的服務版本。一旦新服務通過了最后的測試，就可以使用軟件路由無縫地管理從藍到綠的數據流切換，數據流就可以安全地自動重定向到新服務。同樣重要的是，如果在最后一刻出現了關鍵問題，可以簡單地將部署回退到藍色版本。

數據流屏蔽

數據流屏蔽與藍-綠部署類似，但路由技術不是使用綜合測試來驗證“綠色”環境，而是復制所有輸入的產品數據流，并將其鏡像到尚未公開的單獨的測試部署中。這樣，數據流屏蔽部署基于真實的數據流，能夠清楚地展現新版本部署后會出現什么情況。同時，數據流屏蔽部署保證了測試不會影響實際產品。

企業開發人員已經利用了一系列旨在確保新應用程序代碼能夠滿足某些要求的測試技術。例如，單元測試和功能測試仍然是清理代碼的基本措施。然而，基于微服務體系結構的本質使得端到端集成測試比以往任何時候都更為重要。考慮到微服務體系結構固有的相互依賴性和長期接口漂移的風險，綜合測試仍然有價值，但最終無法準確地表示產品環境中服務之間的所有交互。

4種策略，一個目標

這些路由技術都提供了獨特但又相關的方法來幫助發現、緩解和測試基于微服務的應用程序中的缺陷。它們是解決漏洞、性能問題和安全薄弱點的有力工具，尤其是作為端到端持續集成和交付（CI/CD）管道的一部分進行部署時。

這些方法中哪一種最適合你自己的情況，很大程度上取決于最關鍵的問題所在。例如，對UI進行重大調整非常適合采用A/B測試，而藍-綠部署則適用于了解新特性怎樣影響現有數據存儲的性能。

通常，把這些方法組合起來使用，覆蓋范圍會更好。但是，重要的是要考慮每一種部署與現有開發模型的集成程度。例如，側重單個特性的金絲雀部署比完整版本的藍-綠部署更適合敏捷開發方法。雖然數據流屏蔽部署能夠在部署前很好地了解應用程序的性能，但其實現起來很困難而且非常耗時，計算資源也很昂貴。

通過應用這些方法中的一種、一些或者全部，同時注意它們的具體優勢，應用程序開發團隊能夠更好地保證項目的完整性和項目的成功，更有信心地投入生產。

Manuel Zapf是從事開源項目Traefik和Maesh的云原生網絡公司Containous的產品OSS負責人。

原文網址

https：//www.infoworld.com/article/3565750/4-deployment-strategies-for-resilient-microservices.html