在項目開發完成經過測試並且Uat環境預發布成功后，再到實際生產環境部署還是會可能產生問題。為了減少正式環境發布后的影響，所以我們需要使用灰度發布，灰度驗證，而這都要依賴我們有一套完整的流量分配規則。下面來談談微服務架構中的灰度發布實現：
先看圖：
一、服務網關的流量分配
以Ocelot為例，具體怎么分配流量規則這是由業務決定的，我們只能設計通用規則去適用具體的業務。比如根據userid、clientip、storeid、app-version等等。
首先需要設計一個規則表，我們把服務器的新老版本分為A、B組
{
"rules": [
{ "serviceName":"OrderService","userId": [ 1, 2, 3 ],"tag": "B" }
]
}
serviceName：服務名稱，匹配具體的微服務；userId：用戶ID，匹配請求的用戶ID；tag：服務器組。
在Ocelot負載均衡的時候通過拿到tag信息並設置到http的header信息中，並過濾下游服務器列表。很遺憾，Ocelot沒有為我們實現tags過濾，只能自己拓展這個邏輯，貌似Zuul有根據Meta過濾的功能，具體待我分析了Zuul才清楚。通過分析源碼只有在負載均衡時做才能根據不同請求分配下游服務器。
這樣所有的微服務啟動時在往Consul注冊信息的時候需要添加tag信息。
通過上述這樣的配置，我們userid為1，2，3，4的用戶請求都只會請求新上線的B組機器。
到這里還沒完，我們只實現了請求從網關來的流量分配，並沒有實現服務之間調用的流量分配，所以我們還有下一步工作要做：
二、微服務出戰請求的流量分配：
在.net core中我們在使用http調用時可以選用IHttpClientFactory，據說IHttpClientFactory創建的HttpClient做了很大的改進，以前在使用HttpClient時高並發情況下很坑的哦，所以.net core在2.1版本推薦使用IHttpClientFactory
在IHttpClientFactory創建的HttpClient使用時有了一個出戰請求中間件的概念，這樣我們可以在中間件這里做服務的發現、負載均衡、容錯等等。同時我們可以在這里根據網關設置在header中的tag拿到我們的服務器組，這樣我們一樣可以過濾服務器了，這個流量分配過程就算是源碼完成，還沒有開始代碼的實現，有空后面再貼代碼。