天天看點

分布式服務之Dubbo

Dubbo是一款高性能、輕量級的開源 Java 服務架構。

提供了六大核心能力:面向接口代理的高性能RPC調用,智能容錯和負載均衡,服務自動注冊和發現,高度可擴充能力,運作期流量排程,可視化的服務治理與運維。

分布式服務之Dubbo

Dubbo的主要功能

RPC調用

支援多協定(序列化、傳輸)

服務注冊發現

配置、中繼資料管理

分布式服務之Dubbo

叢集、高可用、管控

叢集、負載均衡

治理、路由

控制台、管理與監控

整體架構圖:

分布式服務之Dubbo

Config配置層:對外配置接口,以ServiceConfig,ReferenceConfig為中心,可以直接初始化配置類,也可以通過Spring解析配置生成配置類

Proxy 服務代理層:服務接口透明代理,生成服務的用戶端Stub和伺服器端Skeleton,以ServiceProxy為中心,擴充接口為ProxyFactory

Registry 注冊中心層:封裝服務位址的注冊與發現,以服務URL為中心,擴充接口為RegistryFactory,Registry,RegistryService

Cluster 路由層:封裝多個提供者的路由及負載均衡,并橋接注冊中心,以Invoker為中心,擴充接口為Cluster,Directory,Router,LoadBalace

Monitor 監控層:RPC調用次數和調用時間的監控,以Statistics為中心,擴充接口為MonitorFactory,Monitor,MonitorService

Protocol 遠端調用層:封裝RPC調用,以Invocation,Result為中心,擴充接口為Protocol,Invoker,Exporter

Exchange 資訊交換層:封裝請求響應模式,同步轉異步,以Request,Response為中心,擴充接口為Exchanger,ExchangeChannel,ExchangeClient,ExchangeServer

Transport 網絡傳輸層:抽象mina和netty為統一接口,以Message為中心,擴充接口為Channel,Transporter,Client,Server,Codec

Serialize 資料序列化層:可複用的一些工具,擴充接口為Serialization,ObjectInput,ObjectOutput,ThreadPool

SPI的應用

SPI與API

ServiceLoader機制

META-INF/dubbo/接口全限定名,檔案内容為實作類

其他兩個類似的機制:Callback和EventBus

服務如何暴露

分布式服務之Dubbo

服務如何引用

分布式服務之Dubbo

叢集與路由

Router :選取此次調用可以提供服務的Invoker集合

LoadBalance :從上述集合中選取一個作為最終調用者

泛化引用

GenericService

當我們知道接口、方法和參數時,可以使用反射調用服務。

方法1:

方法2:

隐式傳參

Context模式

RpcContext.getContext().setAttachment("index","1");

此參數可以傳播到RPC調用的整個過程

Mock

将mock設為true,在實作一個對應的Mock實作類即可。如HelloService的Mock類為HelloServiceMock

開發分包

建議将服務接口、服務模型、服務異常等均放在API包中,因為服務模型和異常也是API的一部分,這樣做也服務分包原則。

服務接口盡可能大粒度,每個服務方法代表一個功能,否則将面臨分布式事務問題

服務接口建議以業務場景為機關劃分

不建議使用過于抽象的通用接口,如Map query(Map map),沒有明确的語義,會給後期維護帶來不便

環境隔離與分組

如何做到多環境隔離呢?

隔離性的部署多套

多注冊中心機制

Dubbo提供的group機制

Dubbo提供的版本機制

參數配置

通用參數以consumer端為準,如果consumer端沒有設定,則用provider數值

建議在Provider端配置的Consumer端屬性有:

timeout: 方法調用逾時時間

retries:失敗重試次數

loadbalance:負載均衡算法

actives:消費者端的最大并發調用限制。

建議在Provider端配置的Provider端屬性有:

threads:服務線程池大小

executes:一個服務提供者并行執行請求上限。

容器化部署

注冊的ip問題,解決方法:

方法1: docker使用主控端網絡

docker參數指定注冊的ip和端口

運維和監控

Admin裡面功能比較簡單,可以整合自己公司的監控系統:

Promethus + Grafana

重試和幂等

服務調用失敗會預設重試,是以接口需要幂等性

設計幂等接口方法:

去重。 可以通過redis、bitMap等

類似樂觀鎖機制判斷

帶着問題去看

如何代理服務的?

如何發送遠端請求的?

配置如何生效的?

異常處理?

逾時機制?

優雅停機?

書山有路勤為徑,學海無涯苦作舟