分散式服務框架學習筆記4 服務路由
透明化路由
很多開源的RPC 框架呼叫者需要配置服務提供者的地址資訊，儘管可以通過讀取資料庫的服務地址列表等方式避免硬編碼地址資訊，但是消費者依然要感知服務提供者的地址資訊，這違反了透明化路由原則。
基於服務註冊中心的訂閱釋出
在分散式服務框架中，服務註冊中心用於儲存服務提供者地址資訊、服務釋出相關的屬性資訊，消費者通過主動查詢和被動通知的方式獲取服務提供者的地址資訊，而不需要像之前那樣在程式碼中硬編碼服務提供者地址資訊。消費得只需要知道當前系統釋出了哪些服務，而不需要知道服務具體存在於什麼位置，這就是透明化路由。它的工作原理就是基於服務註冊中心（例如ZooKeeper）的訂閱釋出機制。
消費者需要快取服務提供者地址。
負載均衡
負載均衡策略：
1. 隨機
2. 輪循
3. 服務呼叫時延
4. 一致性雜湊
相同引數的請求總是發到同一個服務提供者，當某一臺提供者宕機時，原本發往該提供者的請求，基於虛擬節點，平攤到其他提供者，不會引起劇烈變動。平臺提供預設的虛擬節點數，可以通過配置引數進行修改。
5. 粘滯連線
用於連線用於有狀態服務，儘可能讓客戶端總是向同一提供者發起服務呼叫，除非該提供者宕機，再連線另一臺。由於服務通常被強烈建議設計成無狀態的，因此，粘滯連線在實際專案中很少使用。
本地路由優先策略
injvm 模式
在一些業務場景中，本地JVM內部也釋出了需要消費的服務。該場景下，從效能、可靠性等角度考慮，需要優先呼叫本JVM內部的服務提供者，這種本地優先的路由模式被稱為injvm模式。
injvm協議是一個偽協議，它不開啟埠，也不發起遠端服務呼叫，優先呼叫JVM內的服務提供者，相比於其它路由策略，它的執行流程相同，只不過將遠端服務呼叫替換成了內部呼叫。
innative 模式
如果物理機或者VM 配置比較好，多個應用程序往往會選擇合設。服務消費者和服務提供者可能會被部署到同一臺機器上（VM）。服務路由時優先選擇機本的服務提供者，如果找不到再重新發起遠端服務呼叫，該模式被稱為innative模式。
路由規則
負載均衡、本地路由優先等路由策略通常中以滿足大部分業務的線上需求，但是在一些場景中需要對路由策略設定一些過濾條件，比較常用的是基於表示式的條件路由和指令碼路由。
條件路由規則
- 通過IP條件表示式進行黑白名單訪問控制，
- 流量引導，只暴露部分服務提供者，防止整個叢集服務都被沖垮，導致其他服務也不可用
- 讀寫分離：method=find*,list*,get*,query*=>providerIP=192.168.1.*
- 前後臺分離：app=web*=>providerIP=192.168.1.,app=java=>provierIP=192.168.2.*
- 灰度升級，將Web前臺應用路由到新的服務版本上：app=web*=>providerIP=192.168.1.*
指令碼路由規則
指令碼路由規則的特別是通常都支援動態編譯，修改後可以實時生效，不需要重啟系統，這在線上動態調整路由規則時非常有效。
路由策略定製
主要應用場景如下：
- 灰度升級
- 服務故障、業務高峰期的導流
- 與業務領域相關的非通用路由定製需求
路由擴充套件策略如下：
- 平臺提供路由介面供使用者實現
- 平臺提供路由配置XML Schema定義，支援使用者擴充套件路由規則
- 業務釋出自定義路由策略，對於通過Spring Bean方式的服務釋出，使用者定義擴充套件路由bean，然後在服務提供者配置路由規則的時候，引用相關擴充套件的bean即可；如果是通過JDK的SPI方式擴充套件，則需要在jar包的META-INF/services目錄下的路由策略檔案中新增擴充套件的路由實現類和策略名。
配置化路由
路由配置策略設計如下：
1. 本地配置
2. 統一註冊管理
3. 動態下發
最佳實踐——多機房路由
多機房路由，不同機房會共用一個服務註冊中心叢集（異地容災機房除外）。
僅僅依靠隨機、輪詢等負載均衡策略，訊息將會被路由到兩個機房，達不到不跨機房呼叫的目標。利用條件路由規則，可以非常便捷地解決問題。
在原有的負載均衡策略基礎上，配置條件路由策略，由於不同機房的網段通常不同，可以根據網段條件匹配來實現地址過濾。具體配置策略如下：
app=web*,consumerIP=192.168.1.=>providerIP=192.168.1.。對於機房A中所有的Web前臺應用，只訪問本機房內部的服務提供者，不跨機房呼叫。
還有一種策略，就是虛擬分組，將整個集群系統的服務提供者（跨機房）邏輯分成若干個組，某個消費者只訪問一個虛擬分組的服務提供者，防止跨組服務呼叫。如果是多機房部署，虛擬分組可以對應1個機房；如果是單個機房，則虛擬分組可以對應1個機房。通過拆分和分組，防止某個消費者看到叢集中所有的服務提供者，既可以減少競爭提升效能，也可以增強故障隔離能力。
需要指出的是，當某個機房發生大面積宕機或者服務提供者無法正常工作時，需要跨機房訪問其它健康的服務提供者，防止某個機房故障導致業務中斷。