1.將你的新版本號在每個請求中帶給負載均衡伺服器，或者閘道器伺服器；
2.負載均衡伺服器或者閘道器伺服器根據你的這個版本號做負載均衡和路由**，找到發布了新服務的伺服器進行呼叫。
概括一下就是：所謂灰度發布，就是根據使用者、版本、所處的地理位置、是否vip等一系列的加持屬性，伺服器對客戶端的請求執行不同的路由**規則。所以其核心還是請求**。
搞清楚灰度發布的本質是請求**，那麼我們就很好實現了。說到請求**，我們可能有很多種方案：
1）nginx的upstream；2）springcloud的zuul；3）dubbo的spi；4）redis做**過濾；5）zookeeper的臨時節點；6）cookie輔助等等。
甚至，我們還可以把使用者、版本、所處的地理位置、是否vip等一系列的加持屬性和需要**的uri存到資料庫裡，然後做自定義的請求**。
但是這些的本質還是請求**，即可以根據乙個簡單的資料，對應到乙個uri的字串，並且這個uri對應的服務活的，可用的。
完善需要考慮些什麼問題呢？
1）如何維護請求**關係的問題
2）高可用的問題
3）uri的重複性問題
4）對匹配規則的更高階的支援問題，比如正規表示式的支援
5）失效的問題
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布入門
我們的產品是個比較典型的網際網路產品，產品公升級採用 小步快跑 的方式，一般採用保持每週或每兩周一次的發布頻率，同時，每週會有數次bug上線。系統上線總是伴隨著風險，系統重大bug的風險，新舊版本相容的風險，使用者使用習慣突然改變而造成使用者流失的風險等等，因為這些風險的存在，很多次上線都是通宵達旦...