Manuel Zapf Charles

與傳統(tǒng)架構(gòu)相比，開發(fā)人員使用微服務(wù)構(gòu)建應(yīng)用程序速度會更快、更靈活。但是，每一次修改代碼仍然會帶來風(fēng)險，如果沒有發(fā)現(xiàn)并解決代碼質(zhì)量問題，就為潛在的失敗埋下了伏筆。為了降低這類風(fēng)險，應(yīng)用程序開發(fā)團隊?wèi)?yīng)實施現(xiàn)代的云原生路由策略，以便更方便地測試危險因素，并確保應(yīng)用程序能真正準(zhǔn)備好部署到產(chǎn)品環(huán)境中。

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

金絲雀部署

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

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

A/B測試

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

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

藍-綠部署

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

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

數(shù)據(jù)流屏蔽

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

企業(yè)開發(fā)人員已經(jīng)利用了一系列旨在確保新應(yīng)用程序代碼能夠滿足某些要求的測試技術(shù)。例如，單元測試和功能測試仍然是清理代碼的基本措施。然而，基于微服務(wù)體系結(jié)構(gòu)的本質(zhì)使得端到端集成測試比以往任何時候都更為重要?？紤]到微服務(wù)體系結(jié)構(gòu)固有的相互依賴性和長期接口漂移的風(fēng)險，綜合測試仍然有價值，但最終無法準(zhǔn)確地表示產(chǎn)品環(huán)境中服務(wù)之間的所有交互。

4種策略，一個目標(biāo)

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

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

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

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

Manuel Zapf是從事開源項目Traefik和Maesh的云原生網(wǎng)絡(luò)公司Containous的產(chǎn)品OSS負(fù)責(zé)人。

原文網(wǎng)址

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