微服務路由_ZenDei技術網路在線

服務路由的應用場景分組調用。一般來講，為了保證服務的高可用性，實現異地多活的需求，一個服務往往不止部署在一個數據中心，而且出於節省成本等考慮，有些業務可能不僅在私有機房部署，還會採用公有雲部署，甚至採用多家公有雲部署。服務節點也會按照不同的數據中心分成不同的分組，這時對於服務消費者來說，選擇哪一個 ...

服務路由的應用場景

分組調用。一般來講，為了保證服務的高可用性，實現異地多活的需求，一個服務往往不止部署在一個數據中心，而且出於節省成本等考慮，有些業務可能不僅在私有機房部署，還會採用公有雲部署，甚至採用多家公有雲部署。服務節點也會按照不同的數據中心分成不同的分組，這時對於服務消費者來說，選擇哪一個分組調用，就必須有相應的路由規則。
灰度發佈。在服務上線發佈的過程中，一般需要先在一小部分規模的服務節點上先發佈服務，然後驗證功能是否正常。如果正常的話就繼續擴大發佈範圍；如果不正常的話，就需要排查問題，解決問題後繼續發佈。這個過程就叫作灰度發佈，也叫金絲雀部署。
流量切換。在業務線上運行過程中，經常會遇到一些不可抗力因素導致業務故障，比如某個機房的光纜被挖斷，或者發生著火等事故導致整個機房的服務都不可用。這個時候就需要按照某個指令，能夠把原來調用這個機房服務的流量切換到其他正常的機房。
讀寫分離。對於大多數互聯網業務來說都是讀多寫少，所以在進行服務部署的時候，可以把讀寫分開部署，所有寫介面可以部署在一起，而讀介面部署在另外的節點上。

服務路由的規則

根據我的實踐經驗，服務路由主要有兩種規則：一種是條件路由，一種是腳本路由。

1. 條件路由

條件路由是基於條件表達式的路由規則，以下麵的條件路由為例，我來給你詳細講解下它的用法。

condition://0.0.0.0/dubbo.test.interfaces.TestService?category=routers&dynamic=true&priority=2&enabled=true&rule=" + URL.encode(" host = 10.20.153.10=> host = 10.20.153.11")

這裡面“condition://”代表了這是一段用條件表達式編寫的路由規則，具體的規則是

host = 10.20.153.10 => host = 10.20.153.11

分隔符“=>”前面是服務消費者的匹配條件，後面是服務提供者的過濾條件。當服務消費者節點滿足匹配條件時，就對該服務消費者執行後面的過濾規則。那麼上面這段表達式表達的意義就是IP為“10.20.153.10”的服務消費者都調用IP為“10.20.153.11”的服務提供者節點。

如果服務消費者的匹配條件為空，就表示對所有的服務消費者應用，就像下麵的表達式一樣。

=> host ！= 10.20.153.11

如果服務提供者的過濾條件為空，就表示禁止服務消費者訪問，就像下麵的表達式一樣。

host = 10.20.153.10=>

下麵我舉一些Dubbo框架中的條件路由，來給你講解下條件路由的具體應用場景。

排除某個服務節點

=> host != 172.22.3.91

一旦這條路由規則被應用到線上，所有的服務消費者都不會訪問IP為172.22.3.91的服務節點，這種路由規則一般應用線上上流量排除預發佈機以及摘除某個故障節點的場景。

白名單和黑名單功能

host != 10.20.153.10,10.20.153.11 =>

這條路由規則意思是除了IP為10.20.153.10和10.20.153.11的服務消費者可以發起服務調用以外，其他服務消費者都不可以，主要用於白名單訪問邏輯，比如某個後臺服務只允許特定的幾台機器才可以訪問，這樣的話可以機器控制訪問許可權。

host = 10.20.153.10,10.20.153.11 =>

同理，這條路由規則意思是除了IP為10.20.153.10和10.20.153.11的服務消費者不能發起服務調用以外，其他服務消費者都可以，也就是實現了黑名單功能，比如線上經常會遇到某些調用方不管是出於有意還是無意的不合理調用，影響了服務的穩定性，這時候可以通過黑名單功能暫時予以封殺。

機房隔離

host = 172.22.3.* => host = 172.22.3.*

這條路由規則意思是IP網段為172.22.3.*的服務消費者，才可以訪問同網段的服務節點，這種規則一般應用於服務部署在多個IDC，理論上同一個IDC內的調用性能要比跨IDC調用性能要好，應用這個規則是為了實現同IDC就近訪問。

讀寫分離

method = find*,list*,get*,is* => host =172.22.3.94,172.22.3.95
method != find*,list*,get*,is* => host = 172.22.3.97,172.22.3.98

這條路由規則意思是find*、get*、is*等讀方法調用IP為172.22.3.94和172.22.3.95的節點，除此以外的寫方法調用IP為172.22.3.97和172.22.3.98的節點。對於大部分互聯網業務來說，往往讀請求要遠遠大於寫請求，而寫請求的重要性往往要遠遠高於讀請求，所以需要把讀寫請求進行分離，以避免讀請求異常影響到寫請求，這時候就可以應用這種規則。

2. 腳本路由

腳本路由是基於腳本語言的路由規則，常用的腳本語言比如JavaScript、Groovy、JRuby等。以下麵的腳本路由規則為例，我來給你詳細講解它的用法。

"script://0.0.0.0/com.foo.BarService?category=routers&dynamic=false&rule=" + URL.encode("（function route(invokers) { ... } (invokers)）")

這裡面“script://”就代表了這是一段腳本語言編寫的路由規則，具體規則定義在腳本語言的route方法實現里，比如下麵這段用JavaScript編寫的route()方法表達的意思是，只有IP為10.20.153.10的服務消費者可以發起服務調用。

function route(invokers){
  var result = new java.util.ArrayList(invokers.size());
  for(i =0; i < invokers.size(); i ++){
    if("10.20.153.10".equals(invokers.get(i).getUrl().getHost())){ 
       result.add(invokers.get(i));
    } 
  }
  return result; 
 } (invokers)）;

既然服務路由是通過路由規則來實現的，那麼服務消費者該如何獲取路由規則呢？

服務路由的獲取方式

根據我的實踐經驗，服務路由的獲取方式主要有三種：

本地配置

顧名思義就是路由規則存儲在服務消費者本地上。服務消費者發起調用時，從本地固定位置讀取路由規則，然後按照路由規則選取一個服務節點發起調用。

配置中心管理

這種方式下，所有的服務消費者都從配置中心獲取路由規則，由配置中心來統一管理。

動態下發

通過服務治理平臺修改路由規則，服務治理平臺調用配置中心介面，把修改後的路由規則持久化到配置中心。因為服務消費者訂閱了路由規則的變更，於是就會從配置中心獲取最新的路由規則，按照最新的路由規則來執行。

一般來講，服務路由最好是存儲在配置中心中，由配置中心來統一管理。這樣的話，所有的服務消費者就不需要在本地管理服務路由，因為大部分的服務消費者並不關心服務路由的問題，或者說也不需要去瞭解其中的細節。通過配置中心，統一給各個服務消費者下發統一的服務路由，節省了溝通和管理成本。

但也不排除某些服務消費者有特定的需求，需要定製自己的路由規則，這個時候就適合通過本地配置來定製。

而動態下發可以理解為一種高級功能，它能夠動態地修改路由規則，在某些業務場景下十分有用。比如某個數據中心存在問題，需要把調用這個數據中心的服務消費者都切換到其他數據中心，這時就可以通過動態下發的方式，向配置中心下發一條路由規則，將所有調用這個數據中心的請求都遷移到別的地方。

當然，這三種方式也可以一起使用，這個時候服務消費者的判斷優先順序是本地配置>動態下發>配置中心管理。