我們的產品是個比較典型的網際網路產品，產品公升級採用「小步快跑」的方式，一般採用保持每週或每兩周一次的發布頻率，同時，每週會有數次bug上線。系統上線總是伴隨著風險，系統重大bug的風險，新舊版本相容的風險，使用者使用習慣突然改變而造成使用者流失的風險等等，因為這些風險的存在，很多次上線都是通宵達旦、小心翼翼，rd和qa都搞提很疲憊。為了不再如此疲憊，同時避免重大事故的發生，我們決定採用灰度發布的策略，其主要思想就是化大為小，逐漸發布，將風險引起的影響控制在最小範圍。
以上步驟看起來很簡單，但在實際落地過程中需要注意以下問題:
1，集群a與b在應用層完全隔離，dubbo註冊中心zk與mq是非共享的，但在資料層是共享的。即db,redis,mongodb,redis這些資源是由集群a&b共享的。因此，資料的schema對於新舊版本需要相容。
2，以上方案中，新舊版本是並行的，使用者請求被隨機分配到新舊版本的兩個集群中。如果需要限定只有特定的使用者才可以訪問新系統（一般是鐵粉使用者），則需要增加路由規則。
對於簡單的路由規則，可以通過nginx+lua指令碼的方式實現, 可參考：
對於複雜路由規則相關的方案請參考：
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
nginx灰度發布
灰度發布策略 基於使用者標識，基於ip等 灰度發布實現方式 nginx lua根據來訪者ip位址區分 nginx根據cookie分流 nginx根據權重分配 nginx基於使用者標識灰度發布 upstream g1 upstream g2 server localhost nginx伺服器監聽80，...