如何統一服務調用框架？

轉載本文需註明出處：微信公衆號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形式，反之亦然，就會出現二、4的混合服務調用場景，這類場景主要是經過兼容來保證平滑升級過分。



基於使用場景推論，原有系統多是Spring Cloud或者是Dubbo，因此服務註冊中心須要支持Eureka和Zookeeper，調用協議須要支持Http（Restful）或RPC協議。

運行邏輯能夠拆分如下幾段：
 

1. 服務提供方能夠根據配置項，將具體服務對外提供爲Spring Cloud（Restful）和Dubbo（RPC）協議服務
2. 服務提供方根據提供的服務協議類型，轉換爲對應的服務契約，註冊到Eureka和Zookeeper
3. 服務消費方從Eureka和Zookeeper中獲取服務註冊信息，根據服務契約解析
4. 服務消費方根據配置項、獲取的服務契約，調用服務提供方的服務

 

• 採用統一聲明式調用方式使得開發人員比較容易開發應用，調用實現經過服務類型區分，分別採用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服務訪問所須要的要素。



["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®ister=true&release=2.7.1&side=provider×tamp=1573006719825"]

9002
61441


Dubbo服務的發佈格式在Eureka中存儲如上圖，將完整的Dubbo服務所須要的要素所有存儲到metadata中。

開發使用示例

關鍵時序處理鏈路示例

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



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

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



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

• Jar版本衝突通常採用調整或鎖定jar版本。
• Bean衝突通常修改Bean的配置或者名稱。
• 配置項衝突須要自定義配置項處理過程，經過參數或啓動腳本設置。

關於做者：零零九，現任普元金融資深工程師，主要負責微服務平臺和流程平臺設計與開發，前後參與公司EOS、BPS的產品開發和客戶定製。持續關注應用安全和NLP。

關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！