與傳統架構相比，使用微服務構建應用程式可為開發人員提供更高的速度和敏捷性。但是，每次**更改仍會招致風險，如果未發現和解決**質量問題，則為潛在的失敗奠定了基礎。為了減輕這些風險，應用程式團隊應實施現代的雲原生路由策略，以使其更易於測試危險並確保應用程式已真正準備好在生產環境中部署。
以下四種部署策略使用路由技術來安全地引入新服務和功能，測試功能並進行迭代改進，識別和消除漏洞等等。這些方法共同構成了乙個虛擬工具箱，應用程式團隊可以使用這些工具來降低在開發和部署微服務驅動的應用程式期間的風險。了解它們的異同是了解如何在自己的環境中充分利用它們的關鍵。
金絲雀部署是根據將實際鳥類送入煤礦以檢視空氣質素是否對人類安全而言的歷史慣例而命名的，它是一種以最小的影響或風險來測試實際生產部署的方法。所謂的canary是服務的候選版本，它捕獲傳入請求的某些子集百分比（例如1％）以嘗試新功能或構建。然後，團隊可以檢查結果，如果一切順利，請逐漸將部署增加到100％的伺服器或節點。如果不？在檢查和除錯有問題的**時，可以從金絲雀部署中快速重定向流量。
canary部署可以通過與負責處理入站使用者流量的邊緣路由元件的整合來實現。例如，在kubernetes環境中，金絲雀部署可以利用入口控制器配置為穩定和金絲雀部署分配指定百分比的流量請求。通過這種方式路由流量，可以確保新服務在收到完整的部署之前有機會證明自己。如果沒有，他們將被送回以解決問題，然後在準備好時進行另一輪的canary部署測試。
a / b測試類似於金絲雀部署，但有乙個重要區別。雖然金絲雀的部署往往側重於發現錯誤和效能瓶頸，但a / b測試側重於衡量使用者對新應用程式功能的接受程度。例如，開發人員可能想知道新功能是否在使用者中流行，它們是否易於發現或ui是否正常執行。
此模式使用軟體路由來啟用和測試具有不同流量細分的特定功能，從而將新功能暴露於指定百分比的流量或有限的組。a和b路由段可能會將流量傳送到軟體的不同版本，或者服務例項甚至可能使用相同的軟體版本，但具有不同的配置屬性（在協調器或其他地方指定）。
藍綠色部署模式涉及並行操作兩個生產環境：乙個用於當前穩定發行版（藍色），乙個用於上乙個版本並在下乙個發行版上執行測試（綠色）。這種策略使更新的軟體版本能夠以易於重複的方式發布。devops團隊可以使用此技術通過ci / cd管道自動執行新版本的發布。
使用藍綠色策略，開發人員可以在當前處理生產流量的現有例項的旁邊部署新的服務版本。ci / cd管道應設定為執行自動煙霧測試，以驗證新版本的關鍵功能是否成功。一旦新服務通過了最後的測試，就可以使用軟體路由無縫地管理從藍色到綠色的流量切換，從而安全，自動地將流量重定向到它。同樣重要的是，對於關鍵的，最新的問題，如果出現關鍵問題，則很容易將部署回退到藍色版本。
流量陰影類似於藍綠色部署，但是路由技術沒有使用綜合測試來驗證「綠色」環境，而是複製了所有傳入的生產流量並將其映象到尚未公開的單獨測試部署。因此，流量遮蔽可以根據真實流量準確地描述如果部署新版本會發生什麼情況。同時，流量遮蔽確保測試不會影響實際生產。實際上，開發人員可以選擇將一定百分比的請求複製到測試服務，然後他們可以在其中執行整合測試和效能基準測試（手動或在自動ci / cd管道的框架內）。
企業開發人員已經利用了一系列旨在確保新的應用程式**滿足某些要求的測試技術。例如，單元測試和功能測試仍然是**必須清除的基本措施。但是，基於微服務的體系結構的性質使端到端整合測試比以往任何時候都更加重要。考慮到微服務體系結構固有的相互依賴關係和長期介面漂移的風險，綜合測試仍然有價值，但最終將無法準確表示生產環境中服務之間的所有互動。
這些路由技術都提供了獨特但又相關的方法來幫助發現，緩解和測試基於微服務的應用程式中的缺陷。它們是解決錯誤，效能問題和安全漏洞的有效工具，尤其是在作為端對端連續整合和交付（ci / cd）管道的一部分進行部署時。
哪種方法最適合您自己的情況，在很大程度上取決於最關鍵的問題。例如，主要的ui檢修可以從a / b測試中大大受益，而藍綠色部署對於檢視新功能可能如何影響現有資料儲存的效能可能是無價的。
通常，這些技術的組合可能會提供最佳的覆蓋範圍。但是，重要的是要考慮每個元件與您現有的開發模型的整合程度。例如，單個功能的canary部署比完整版本的藍綠色部署更適合於敏捷開發方法。而且，儘管流量影子可以很好地了解應用程式效能的預部署，但實現起來既困難又耗時，而且在計算資源方面也很昂貴。
無論您採用哪種技術，諸如此類的路由技術都可能是軟體開發過程中不可估量的一部分，尤其是在該行業從傳統的單片應用程式向基於微服務的雲原生系統轉移的過程中。通過應用一種，部分或全部這些技術，同時牢記它們的特定優勢，應用程式團隊可以更好地確保其專案的完整性和成功性，並更有信心地投入生產。
龍測，模型驅動的自動化測試平台。畫流程圖、積木圖自動生成測試**的自動化測試專家！
測試體驗官網：
4種微服務系統認證策略
譯者 牛小腩 在傳統的單體架構中，單個服務儲存所有的使用者資料，可以校驗使用者，並在認證成功後建立http會話。在微服務架構中，使用者是在和服務集合互動，每個服務都有可能需要知道請求的使用者是誰。一種樸素的解決方案是在微服務系統中應用與單體系統中相同的模式，但是問題就在於如何讓所有的服務訪問使用者的...
微服務系統中的認證策略
在傳統的單體架構中，單個服務儲存所有的使用者資料，可以校驗使用者，並在認證成功後建立http會話。在微服務架構中，使用者是在和服務集合互動，每個服務都有可能需要知道請求的使用者是誰。一種樸素的解決方案是在微服務系統中應用與單體系統中相同的模式，但是問題就在於如何讓所有的服務訪問使用者的資料。解決這個...
微服務系統中的認證策略
在傳統的單體架構中，單個服務儲存所有的使用者資料，可以校驗使用者，並在認證成功後建立http會話。在微服務架構中，使用者是在和服務集合互動，每個服務都有可能需要知道請求的使用者是誰。一種樸素的解決方案是在微服務系統中應用與單體系統中相同的模式，但是問題就在於如何讓所有的服務訪問使用者的資料。解決這個...