在日常軟體建設中，我們有時會遇到乙個新舊邏輯、新舊元件灰度切流的過程。如何能夠平滑的切流，相信會是每個開發者面臨的問題。
好的，我們進入正題。
灰度切流的用例圖很簡單。
根據這個用例最直觀的設計就是:
在乙個gateway中包含乙個router，通過讀取配置去選擇究竟是實現a還是實現b。
使用的是策略模式最直接的解決問題。
但是現在gateway的直接和router的職責繫結到了一起，帶來維護成本的提高，所以為了更加明確就變成了如下的設計:
gateway包含了乙個包含所有實現的router，由router進行根據配置進行呼叫。
這樣的設計對於功能易用性已經ok。假如還需要一些結果合併邏輯怎麼辦?
從現在結構裡，需要在router裡增加除了開關之後額外的合併邏輯。
從現在看，整個切流過程是沒問題。不論是如何切流都是能夠支援的。
在這種情況下，我們如何增加乙個新的切流邏輯或者將清理舊邏輯或者舊元件?
或者我們說一下這種設計的缺點在**。
違反srp原則。router的功能不純粹，除了切流還參與了業務邏輯，在切流完成後需要將部分邏輯移到實現中。
重複。有多少切流就需要多少的router
好吧。那如果針對上述問題，可以有更好的設計嗎？
首先我們可以將router有關於業務部分的抽離出來, 將router設計成為:
基於配置實現切流邏輯。
有了核心物件，我們就可以設計基於spring***去實現動態反射呼叫了。
基於這種方案，我們實現了基於註解配置的路由開關配置。在整合預設雲配置的時候，通過spel解析的方式實現，保留擴充套件自定義路由實現能力。
現在增加乙個切流或者去掉切流，只需要將註解增加或者移除，不需要改動其他**。
世界上肯定沒有完美的東西，那這種方案缺點有沒有呢?
答案是肯定的。
複雜度上公升，在考慮的時候需要考慮可能帶來的風險。
對效能會有影響。
基於這種方案，我們在生產系統上實現了乙個路由元件，來靈活支撐我們的切流。這裡也總結下遇到的坑
需要考慮***的順序，來保證其他已有註解的正常工作
對於批量介面，因為走多次***，造成效能下降了10ms左右
路由元件各個過程中使用的外部呼叫結果多次使用，只能通過快取解決
異常處理粗糙。對於反射呼叫異常invocationtargetexception直接wrap成了元件的異常，造成應用裡的監控***捕獲異常失敗。沒有針對各種情況去設定異常型別，方便應用程式去處理。
將一些基礎之外的能力變更可選，避免違反isp原則
灰度分流方案
serviceport 80在annotations.nginx.ingress.kubernetes.io service match中 其代表的是分流規則配置,一條path 分流規則配置內 其oldrules 與 newrules 只能存在其中乙個 不能共存 oldrules oldrule o...
git灰度發布版本 一種前端灰度發布方案
本文介紹一種前端灰度發布方案，主要解決的是傳統的灰度發布只能以機器維度進行分組的問題。提供一種使用者維度分組的灰度發布機制。傳統灰度發布，因為是以機器分組，所以要求服務是無狀態的。所謂無狀態就是對請求的處理是上下文無關的。有長連線 讀寫檔案 快取等場景，就是所謂 有狀態 的。有狀態的服務，如果使用者...
git灰度發布版本 一種前端灰度發布方案
本文介紹一種前端灰度發布方案，主要解決的是傳統的灰度發布只能以機器維度進行分組的問題。提供一種使用者維度分組的灰度發布機制。傳統灰度發布，因為是以機器分組，所以要求服務是無狀態的。所謂無狀態就是對請求的處理是上下文無關的。有長連線 讀寫檔案 快取等場景，就是所謂 有狀態 的。有狀態的服務，如果使用者...