背景
微服務框架下服務個數多、調用鏈路較長,其中一個服務出問題會影響到整條鏈路。但QA提測每每須要該條鏈路上的多個服務配套測試,甚至是同時測試一個服務的多個演進版本。前端
提供穩定環境 和 多服務/多版本同時測試 看似相悖的需求,經過泳道「Swimlane」可以獲得解決。webpack
測試過程當中會遇到的問題web
關於一個服務上的多個需求的同時測試,存在服務搶佔分支測試的問題;後端
不一樣的業務組在測試時依賴的第三方服務有改動或正在進行新需求測試影響本業務測試。服務器
微服務框架下服務個數多、調用鏈路較長,其中一個服務出問題會影響到整條鏈路。但QA提測每每須要該條鏈路上的多個服務配套測試,甚至是同時測試一個服務的多個演進版本。提供穩定環境 和 多服務/多版本同時測試 看似相悖的需求,經過泳道「Swimlane」可以獲得解決。微信
什麼是泳道
對服務鏈按需求進行分組複製,並實現邏輯、物理的隔離,使得不一樣需求的服務鏈運行在相隔的物理機器上,邏輯上如同游泳場中的泳道。app
一個環境內會有一條骨幹鏈路(該環境的默認鏈路)和多條泳道。如圖所示,泳道隔離出了一條調用邊界:處於[泳道-1]內的服務B要調用服務C,若在[泳道-1]內部署了C服務,則B只能調用泳道內的C服務,而不能調用骨幹鏈路或其餘泳道的C服務;若在[泳道-1]內沒有部署C服務,則流量會調回骨幹鏈路。框架
優點:編輯器
並行測試。(所以能夠根據測試須要,部署不一樣分支的服務分組,多個泳道並行,多個服務/多個版本可同時提測)微服務
提供穩定的骨幹鏈路。(保證整個測試流程始終能正常運行)
錯誤隔離。(泳道內的服務發生異常 不會影響其餘泳道)
泳道的特性
泳道至關於提供了多條「請求的跑道」,理解泳道主要在於理解「流量跑到哪去了」:
泳道內若是沒有部署被調用服務,流量會fallback到骨幹
– 好比上圖[泳道-2]中的B服務節點 調用了 [骨幹鏈路]中的C服務節點
泳道內若存在被調用節點,那麼流量是必定不會fallback的 (包括不可用的和禁用的)
– 好比上圖[泳道-2]中的A服務節點 只會調用 [泳道-2]中的B服務節點,即便[泳道-2]中的B不可用,也是不會fallback的
骨幹環境是必定不會調用到泳道內的
– 好比上圖中絕逼不會有 從[骨幹鏈路]到[泳道-2]的調用
泳道之間是必定不會互相調用的
– 好比上圖中絕逼不會有 [泳道-1]與[泳道-2]之間的調用
泳道的實現
泳道實現的重點在於服務的註冊、發現和服務導流。
後端服務的註冊和發現的流程以下:
服務B啓動,上報ip、port、appkey、swimlane等信息
骨幹鏈路上的服務A節點要調用B,先去取B的服務列表,並進行過濾:A不帶有泳道標識,因此只會調用不帶泳道標識的B服務節點
泳道1上的服務A節點要調用B,也會先去取B的服務列表,並進行過濾:A帶有泳道=泳道1 標識,因此只會調用一樣帶有泳道=泳道1 標識的B服務節點
服務導流
經過域名劃分泳道:爲各個泳道申請單獨的域名,根據域名進行分流
經過header攜帶泳道信息:請求的header字段增長「swimlane=xxxx」,標識請求要打到名爲xxxx的泳道里,分流系統會根據該字段作分流。
前端靜態資源,基於泳道名進行隔離,在資源編譯和打包的時候,指定發佈的泳道名,而後資源會上傳到該泳道對應的靜態服務器中:
1 |
const swimName = process.env.SWIM_ENV; |
點個『在看』支持下
本文分享自微信公衆號 - 前端技術江湖(bigerfe)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。