大家好，我是架構擺渡人。這是實踐經驗系列的第二篇文章，這個系列會給大家分享很多在實際工作中有用的經驗，如果有收穫，還請分享給更多的朋友。
上篇文章給大家分享了開關的應用技巧，通過開關去保證上線時的穩定性。但是開關還是屬於一刀切的那種，如果流量特別大的情況下，影響面還是挺大的，所以今天就給大家再補充一種方式，灰度放量。
舉個例子說明下：比如你在重構訂單詳情介面，這個介面之前是在A服務裡面，由於後續服務拆分更精細化，新拆了一個服務，需要將這個介面遷移到新服務裡面去。此時最簡單的做法就是把程式碼複製過去，然後讓客戶端用新的詳情介面。
但是這樣老版本的APP怎麼辦？這個方案只能新版本的APP可以使用。所以對外的介面是不能變的，內部需要去做路由動作，那麼最方便的肯定是在閘道器做了，所以閘道器是特別適合做灰度邏輯的地方，下面我們先來看閘道器如何做灰度。
閘道器統一灰度
閘道器預設是路由的/v1/order/detail介面，現在新加了/v2/order/detail介面，如果全部切過去，萬一有問題，所有使用者都會受到影響，所以需要灰度放量來將風險降到最低。
閘道器內部可以對指定的使用者路由到v2版本的介面，也可以根據地區路由，方式有很多種，常用的路由方式有哪些我會在下面進行講解。
應用內部自己灰度
除了在閘道器進行灰度，另一種方案就是應用內部自己灰度。也就是說APP請求到閘道器，閘道器到具體的服務，這個服務此時還是之前的老服務，需要在這個老服務呼叫新服務的介面，然後返回，這就是應用內部自己灰度的方式。
一旦灰度完成，老服務內部的程式碼就可以刪除，當請求過來的時候只需要路由到請服務即可。然後可以將閘道器路由的地址直接改成新服務的地址，此時老服務內的介面可以直接刪除，完成遷移動作。
灰度方式介紹
使用者白名單灰度
此方式較為簡單，就是構建一個使用者的白名單，可以用手機號或者使用者ID，白名單可以放在資料表裡面，也可以放在配置中心。從效能角度考慮放配置中心更合適，更新後也能實時生效。
也就是當前請求的使用者在你配置的白名單裡面，就讓他訪問新版本的介面，不在就預設還是舊介面。通過這種方式觀察一段時間，如果沒有問題，就可以加大灰度人數或者全量放開。
使用者百分比灰度
提取使用者ID的後兩位，然後產生一個隨機數，如果匹配上了，這個使用者就灰度中了。
百分比灰度
百分比灰度也是一種常用的灰度方式，此方式不會固定使用者，而是採用隨機的方式進行。如果設定了10%的灰度比例，也就是100次請求中有10次請求會被灰度中，會訪問新的介面。
當然為了影響降到最低，也可以實現千分比，萬分比，慢慢調高比例，一點點往上灰度，這種方式非常穩妥。
虛擬碼如下：
public static void main(String[] args) {
// 灰度比例，配在配置中心
int grayScale = 10;
int probability = new Random().nextInt(100);
if (probability < grayScale) {
// 呼叫 /v2/order/detail
} else {
// 走本地老邏輯
}
}