如何統一服務呼叫框架？

轉載本文需註明出處：微信公眾號EAWorld，違者必究。

引言：

目前在Java 微服務領域Spring Cloud 和Dubbo體系都被廣泛使用。不同的使用者會根據專案的需要選擇合適的架構。但是在有些跨系統的場景下會涉及到兩種體系間的混合呼叫。怎麼做到較小修改就支援Spring Cloud和Dubbo兩種體系的混合呼叫？本文將介紹一下我們在較小修改情況下統一Spring CLoud和Dubbo服務呼叫框架。

目前Spring Cloud和Dubbo體系發展都比較成熟，不少客戶已有一些採用它們開發的系統。好的微服務開發平臺需要支援這兩種體系。統一開發體驗和降低開發複雜度的同時，保留兩種體系各自的優勢。

現有企業IT架構

服務呼叫場景

IT企業根據不同系統有不同的現狀和技術發展路線。針對新系統，採用優先常用的Spring Coud應用呼叫Spring Cloud應用或Dubbo應用呼叫Dubbo應用。

但是針對已有系統進行架構調整改造，即如有系統A是Spring Cloud體系，想新增或者改造一些服務為Dubbo形式，反之亦然，就會出現2、4的混合服務呼叫場景，這類場景主要是透過相容來保證平滑升級過度。

基於使用場景推論，原有系統可能是Spring Cloud或者是Dubbo，所以服務註冊中心需要支援Eureka和Zookeeper，呼叫協議需要支援Http（Restful）或RPC協議。

執行邏輯可以拆分以下幾段：

服務提供方可以根據配置項，將具體服務對外提供為Spring Cloud（Restful）和Dubbo（RPC）協議服務
服務提供方根據提供的服務協議型別，轉換為對應的服務契約，註冊到Eureka和Zookeeper
服務消費方從Eureka和Zookeeper中獲取服務註冊資訊，根據服務契約解析
服務消費方根據配置項、獲取的服務契約，呼叫服務提供方的服務

採用統一宣告式呼叫方式使得開發人員比較容易開發應用，呼叫實現透過服務型別區分，分別採用Feign，Dubbo採用自帶實現，這樣可以有效支援已有系統呼叫，降低學習成本。
獨立註解可以統一規範開發，控制平臺呼叫規則處理需要提供和消費的介面。
服務型別控制應用是服務提供方還是服務消費方，可以在同一應用中支援服務雙體系和消費雙體系。
靈活配置的服務體系規則，便於根據需要調整服務體系，如應用總體為Spring Cloud，新增提供和消費服務都是Dubbo，可以在原有的配置中，增加這些新服務為Dubbo體系規則即可。

定義期決定執行的過程

服務型別是針對具體的服務提供型別為Spring Cloud（Restful）服務還是Dubbo（RPC）服務，提供對應的服務契約（完整的服務描述Swagger）。

註冊中心型別就是基於啟動依賴和配置項，決定連線的註冊中心具體為Eureka還是Zookeeper，提供對應的服務釋出格式（註冊中心儲存的服務格式）。

服務型別決定應用、包、介面型別定義的優先順序依次遞增，即如果都有配置時，以介面配置為準。服務型別的切換，可以透過配置檔案的修改調整，無需調整程式碼。

服務提供和服務呼叫的關鍵邏輯：

1. 根據配置，掃描EOSService介面。

2. 判斷服務提供型別，包含多層級優先順序判斷，確定服務提供型別。

a ) Dubbo型別：仿照Dubbo本身服務釋出的形式，註冊Dubbo bean例項

b ) Spring Cloud型別：根據約定釋出對應Restful服務（因為為方便開發採用宣告式呼叫，所以需要平臺約定如url、type等規則）

3. 判斷服務呼叫型別，包含多層級優先順序判斷，確定服務呼叫方式。

a ) Dubbo型別：仿照Dubbo本身服務釋出的形式，註冊Dubbo bean例項

b ) Spring Cloud型別：根據約定註冊Feign bean。呼叫時，透過Feign呼叫服務。

註冊中心根據如上依賴項決定，啟動bean載入不同。不同的註冊中心保留的服務釋出時機和格式有不同。

同體系的註冊中心因為需要對接已有系統，所以服務釋出格式都延用同體系內容，如Spring Cloud服務釋出到Eureka，和Dubbo服務釋出到Zookeeper中的服務格式同原有系統其他服務，不做特殊處理。

服務釋出和服務獲取的關鍵邏輯：

1. 根據依賴項，啟動不同註冊中心初始化過程。

2. 判斷註冊中心型別，替換服務註冊例項。

a ) Zookeeper型別：啟動Zookeeper註冊和監聽例項，根據服務提供型別，組織服務釋出格式到Zookeeper節點（具體格式後面有示例）。

b ) Eureka型別：Spring Cloud同原有，Dubbo服務透過非同步掃描，放置到對應的擴充套件屬性。

3. 判斷註冊中心型別，替換服務例項獲取方式。

a ) Zookeeper型別：啟動Zookeeper註冊和監聽例項，根據服務提供型別，從 Zookeeper節點獲取並解析服務格式（具體格式後面有示例）。

b ) Eureka型別：Spring Cloud同原有，Dubbo服務透過監聽Eureka 擴充套件屬性。

Spring Cloud服務的釋出格式在Zookeeper中儲存如上圖，在Zookeeper中新增/spring-cloud-service目錄，記錄Spring Cloud服務訪問所需要的要素。

<metadata>
<providers>
["dubbo://172.20.10.7:20882/com.primeton.eos.demo.sdk.server.core.api.DubboService?anyhost=true&application=provider&bean.name=ServiceBean:dubboServiceController:com.primeton.eos.demo.sdk.server.core.api.DubboService&default.deprecated=false&default.dynamic=false&default.register=true&default.timeout=1000&deprecated=false&dubbo=2.0.2&dynamic=false&generic=false&interface=com.primeton.eos.demo.sdk.server.core.api.DubboService&methods=addUserPost,addUser&pid=46073&register=true&release=2.7.1&side=provider&timestamp=1573006719825"]
</providers>
<management.port>9002</management.port>
<jmx.port>61441</jmx.port>
</metadata>

Dubbo服務的釋出格式在Eureka中儲存如上圖，將完整的Dubbo服務所需要的要素全部儲存到metadata中。

開發使用示例

關鍵時序處理鏈路示例

實際執行過程，根據服務的具體配置項和註冊中心有相應的差異。

【小結】統一呼叫框架就是怎麼支援各種混合服務呼叫的場景，又能統一一種開發體驗，根據需要靈活調整實際服務型別。框架解決的問題是開發期統一簡單，執行期靈活多變，保證服務穩定。實現時需要約束服務型別規則和註冊中心依賴形式，同時定義配套提供和呼叫規則。如定義Spring Cloud的服務地址規則。

【後記】在方案實現中遇到以下幾類問題：

因具體問題與Spring Cloud、Dubbo和第三方具體jar版本有關，只能具體問題具體解決。

Jar版本衝突一般採用調整或鎖定jar版本。
Bean衝突一般修改Bean的配置或者名稱。
配置項衝突需要自定義配置項處理過程，透過引數或啟動指令碼設定。

如何統一服務呼叫框架？

相關文章