開發

如何統一服務調用框架?

廣告
廣告

轉載本文需注明出處:微信公眾號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協議。

運行邏輯可以拆分以下幾段:

  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服務訪問所需要的要素。

<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的配置或者名稱。
  • 配置項沖突需要自定義配置項處理過程,通過參數或啟動腳本設置。
我還沒有學會寫個人說明!

美團BERT的探索和實踐

上一篇

遷移上云之前,要向云提供商提出三個安全問題!

下一篇

你也可能喜歡

如何統一服務調用框架?

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
重庆快乐10分苹果版本 这些做网游的如何赚钱 龙江麻将和和挂 在蚂蚁短租上面赚钱吗 一定牛彩票群 在家用电脑赚钱的职业 哪款走路赚钱软件好 下载宝 赚钱宝 区别 靠卖比赚钱 养殖业什么最赚钱农村养殖 手机兼职到底赚不赚钱 下载微信麻将外挂软件 合伙开奶茶店赚钱吗 天天捕鱼tv 手机加微信可以赚钱是真的吗 微信开赌场赚钱吗 写评论新闻能赚钱吗