創新互聯公司專業IDC數據服務器托管提供商，專業提供成都服務器托管，服務器租用，服務器托管，服務器托管，成都多線服務器托管等服務器托管服務。

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  ,這樣就可以解決文件分散在不同工程導致的維護問題.

文章標題：Node調用dubbo服務的探索及實踐-創新互聯
轉載來源：http://m.newbst.com/article12/dpeggc.html

成都網站建設公司_創新互聯，為您提供App設計、網站策劃、做網站、企業網站制作、ChatGPT、定制開發

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯