爲什麼需要灰度發佈？
我們的產品是個比較典型的互聯網產品，產品升級採用“小步快跑”的方式，一般採用保持每週或每兩週一次的發佈頻率，同時，每週會有數次bug上線。系統上線總是伴隨着風險，系統重大bug的風險，新舊版本兼容的風險，用戶使用習慣突然改變而造成用戶流失的風險等等，因爲這些風險的存在，很多次上線都是通宵達旦、小心翼翼，RD和QA都搞提很疲憊。爲了不再如此疲憊，同時避免重大事故的發生，我們決定採用灰度發佈的策略，其主要思想就是化大爲小，逐漸發佈，將風險引起的影響控制在最小範圍。
如何進行灰度發佈？
1, 首先，我們將系統分成兩個集羣，集羣A和集羣B，每個集羣有一個nginx,在兩個集羣之上，有一個大的集羣C，也有一個nginx。
2, 在發佈時，挑選在線用戶比較小的時間點（如深夜），將小的集羣B下線
3, 將在PL環境測試通過的程序包部署到下線的小集羣B，使用獨立的賬套在線進行關鍵流程的測試（以避免污染真實用戶的線上數據）。
4, 小集羣測試通過之後，將小集羣B上線，即，將小集羣的nginx掛到大集羣C的nginx下，上線試運行。
5-1，如果新上線的小集羣B運行穩定，則將新程序包發到集羣A，從而完成整個集羣的發佈。
5-2，如果新上線的小集羣B有重大bug，則進行回滾。
以上步驟看起來很簡單，但在實際落地過程中需要注意以下問題:
1，集羣A與B在應用層完全隔離，dubbo註冊中心zk與mq是非共享的，但在數據層是共享的。即db,redis,mongodb,redis這些資源是由集羣A&B共享的。因此，數據的schema對於新舊版本需要兼容。
2，以上方案中，新舊版本是並行的，用戶請求被隨機分配到新舊版本的兩個集羣中。如果需要限定只有特定的用戶纔可以訪問新系統（一般是鐵粉用戶），則需要增加路由規則。
對於簡單的路由規則，可以通過nginx+lua腳本的方式實現, 可參考：
https://pingan.im/201503/nginx-lua-redis
對於複雜路由規則相關的方案請參考：
http://blog.csdn.net/hunter_1990s/article/details/43733349
