大家好，我是架構擺渡人。這是實踐經驗系列的第二篇文章，這個系列會給大家分享很多在實際工作中有用的經驗，如果有收獲，還請分享給更多的朋友。
上篇文章給大家分享了開關的應用技巧，通過開關去保證上線時的穩定性。但是開關還是屬于一刀切的那種，如果流量特别大的情況下，影響面還是挺大的，是以今天就給大家再補充一種方式，灰階放量。
舉個例子說明下：比如你在重構訂單詳情接口，這個接口之前是在A服務裡面，由于後續服務拆分更精細化，新拆了一個服務，需要将這個接口遷移到新服務裡面去。此時最簡單的做法就是把代碼複制過去，然後讓用戶端用新的詳情接口。
但是這樣老版本的APP怎麼辦？這個方案隻能新版本的APP可以使用。是以對外的接口是不能變的，内部需要去做路由動作，那麼最友善的肯定是在網關做了，是以網關是特别适合做灰階邏輯的地方，下面我們先來看網關如何做灰階。
網關預設是路由的/v1/order/detail接口，現在新加了/v2/order/detail接口，如果全部切過去，萬一有問題，所有使用者都會受到影響，是以需要灰階放量來将風險降到最低。
網關内部可以對指定的使用者路由到v2版本的接口，也可以根據地區路由，方式有很多種，常用的路由方式有哪些我會在下面進行講解。
除了在網關進行灰階，另一種方案就是應用内部自己灰階。也就是說APP請求到網關，網關到具體的服務，這個服務此時還是之前的老服務，需要在這個老服務調用新服務的接口，然後傳回，這就是應用内部自己灰階的方式。
一旦灰階完成，老服務内部的代碼就可以删除，當請求過來的時候隻需要路由到請服務即可。然後可以将網關路由的位址直接改成新服務的位址，此時老服務内的接口可以直接删除，完成遷移動作。
此方式較為簡單，就是建構一個使用者的白名單，可以用手機号或者使用者ID，白名單可以放在資料表裡面，也可以放在配置中心。從性能角度考慮放配置中心更合适，更新後也能實時生效。
也就是目前請求的使用者在你配置的白名單裡面，就讓他通路新版本的接口，不在就預設還是舊接口。通過這種方式觀察一段時間，如果沒有問題，就可以加大灰階人數或者全量放開。
提取使用者ID的後兩位，然後産生一個随機數，如果比對上了，這個使用者就灰階中了。
百分比灰階也是一種常用的灰階方式，此方式不會固定使用者，而是采用随機的方式進行。如果設定了10%的灰階比例，也就是100次請求中有10次請求會被灰階中，會通路新的接口。
當然為了影響降到最低，也可以實作千分比，萬分比，慢慢調高比例，一點點往上灰階，這種方式非常穩妥。
僞代碼如下：