開發十年，就只剩下這套架構體系了！ >>>   

 

2.Dubbo簡介

2.1 什麼是dubbo

Dubbo是一款高效能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向介面的遠端方法呼叫，智慧容錯和負載均衡，以及服務自動註冊和發現。

2.2 流程圖

• Provider : 暴露服務的服務提供方。
• Consumer : 呼叫遠端服務的服務消費方。
• Registry : 服務註冊與發現的註冊中心。
• Monitor : 統計服務的呼叫次調和呼叫時間的監控中心。
• Container : 服務執行容器。

3. 具體實現

3.1 協議選擇

	連線個數	連線方式	傳輸協議	傳輸方式	序列化	適用範圍	適用場景
dubbo	單連線	長連線	TCP	NIO 非同步傳輸	Hessian 二進位制序列化	傳入傳出引數資料包較小，消費者比提供者個數多，單一消費者無法壓滿提供者	常規遠端服務方法呼叫
rmi	多連線	短連線	TCP	同步傳輸	Java 標準二進位制序列化	傳入傳出引數資料包大小混合，消費者與提供者個數差不多，可傳檔案。	常規遠端服務方法呼叫，與原生RMI服務互操作
hessian	多連線	短連線	HTTP	同步傳輸	Hessian二進位制序列化	傳入傳出引數資料包較大，提供者比消費者個數多，提供者壓力較大，可傳檔案。 頁面傳輸，檔案傳輸，或與原生hessian服務互操作
http	多連線	短連線	HTTP	同步傳輸	表單序列化	傳入傳出引數資料包大小混合，提供者比消費者個數多，可用瀏覽器檢視，可用表單或URL傳入引數 需同時給應用程式和瀏覽器 JS 使用的服務。
rest	多連線	短連線	HTTP	同步傳輸	表單序列化	同http，適用於更加符合rest規範的服務	同http

3.2 如何引用服務

目前引用服務有兩個方案，分別是

• 直接引用
• 通過註冊中心引用服務

3.2.1 直接引用服務

直接引用服務，顧名思義就是繞開註冊中心獲取我們所想要的服務提供者，由於繞開了註冊中心，自然也無法做到服務發現，而且由於單點問題，無法做到負載均衡以及高可用， 所以生產環境不推薦使用此模式的 ．

但是由於其開發上的便利性，在開發環境/測試環境仍可以嘗試使用此模式．

由上圖所示，開發同學聯調過程中，需要在專案工程中對指定服務開發同學的機器進行直連，而其他沒有指定的服務將會預設走註冊中心．為了避免對工程程式碼的侵入性，我們會在工程中建立應對不同環境的dubbo.properies，而dubbo.properies不會加入到工程的版本控制當中，主要用於解決不同環境下的服務直連問題．其中服務的控制粒度可以精確到具體的服務．

3.2.2 通過註冊中心引用服務

通過註冊中心發現引用服務，Dubbo常用的引用服務方式，可以做到服務自動發現，負載均衡．正式環境呼叫基本基於此模式．其中註冊中心實現有很多種，例如Zookeeper/Redis/Multicast．官方推薦Zookeeper．

3.3 服務請求結構的定義

服務請求體結構，是在對dubbo在註冊中心上註冊資訊的抽象之後的一層封裝，一方面可以提升開發人員的開發效率，另外降低開發人員自身手動拼接請求的錯誤率．

3.3.1 服務的構成

基於上述基於協議所分析，我們目前協議將只會鎖定在dubbo/rest，那麼我們先看來這兩個協議在註冊中心註冊的資訊是什麼樣子的.

dubbo://192.168.1.2:10880/com.service.ProductService?dubbo=2.8&methods=getById,getByName
rest://192.168.1.2:10081/service/com.service.ProductService?dubbo=2.8&methods=getById,getByName

我們對這兩個協議公共部分進行提取一下

dubbo://
com.service.ProductService

3.3.2 請求體的定義

基於上述服務結構構成的分析，dubbo和rest服務請求結構構成大體類似，我們對不同的協議請求的可以做如下定義.

// 1. dubbo協議的請求體定義
services.ProductService = (dubbo) => dubbo.proxyService({
    dubboInterface: 'com.service.ProductService',
    methods: {
        getById(id) {
            return [java.Long(id)];
        },
        getByName(name) {
            return [java.String(name)];
        }
    },
});
複製程式碼

// rest 請求體定義
services.ProductService = (dubbo) => dubbo.proxyService({
    dubboInterface: 'com.service.ProductService',
    methods: {
        getById(id) {
            return {
                method: 'get',
                query: [parseInt(id)]
            };
        },
        getByName(name) {
            return [String(name)];
        }
    },
});
複製程式碼

兩者最大不同點在於引數定義上的不同，dubbo需要強制轉換為強型別，而rest不需要.

3.4 服務定義的維護

我們在對服務定義完成之後，接下來就會面臨一個使用上的問題，最直接的方法就是為每個工程每個服務新建一個服務檔案，但是一用就會發現一個問題請求定義的檔案分散在不同工程，無法進行統一維護升級，維護成本較高.

我們第一個反應是每個服務抽象出來，各自成為一個獨立的NPM包，譬如MemberService我們可以抽象成為 @dubbo-service/member-service ,這樣就可以解決檔案分散在不同工程導致的維護問題.

相關推薦