創(chuàng)新互聯(lián)公司專業(yè)IDC數(shù)據(jù)服務器托管提供商，專業(yè)提供成都服務器托管，服務器租用，服務器托管，服務器托管，成都多線服務器托管等服務器托管服務。

2.Dubbo簡介

2.1 什么是dubbo

Dubbo是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動注冊和發(fā)現(xiàn)。

2.2 流程圖

• Provider  : 暴露服務的服務提供方。
• Consumer  : 調用遠程服務的服務消費方。
• Registry  : 服務注冊與發(fā)現(xiàn)的注冊中心。
• Monitor  : 統(tǒng)計服務的調用次調和調用時間的監(jiān)控中心。
• Container  : 服務運行容器。

3. 具體實現(xiàn)

3.1 協(xié)議選擇

	連接個數(shù)	連接方式	傳輸協(xié)議	傳輸方式	序列化	適用范圍	適用場景
dubbo	單連接	長連接	TCP	NIO 異步傳輸	Hessian 二進制序列化	傳入傳出參數(shù)數(shù)據(jù)包較小，消費者比提供者個數(shù)多，單一消費者無法壓滿提供者	常規(guī)遠程服務方法調用
rmi	多連接	短連接	TCP	同步傳輸	Java 標準二進制序列化	傳入傳出參數(shù)數(shù)據(jù)包大小混合，消費者與提供者個數(shù)差不多，可傳文件。	常規(guī)遠程服務方法調用，與原生RMI服務互操作
hessian	多連接	短連接	HTTP	同步傳輸	Hessian二進制序列化	傳入傳出參數(shù)數(shù)據(jù)包較大，提供者比消費者個數(shù)多，提供者壓力較大，可傳文件。 頁面?zhèn)鬏?，文件傳輸，或與原生hessian服務互操作
http	多連接	短連接	HTTP	同步傳輸	表單序列化	傳入傳出參數(shù)數(shù)據(jù)包大小混合，提供者比消費者個數(shù)多，可用瀏覽器查看，可用表單或URL傳入?yún)?shù) 需同時給應用程序和瀏覽器 JS 使用的服務。
rest	多連接	短連接	HTTP	同步傳輸	表單序列化	同http，適用于更加符合rest規(guī)范的服務	同http

3.2 如何引用服務

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

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

3.2.1 直接引用服務

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

但是由于其開發(fā)上的便利性，在開發(fā)環(huán)境/測試環(huán)境仍可以嘗試使用此模式．

由上圖所示，開發(fā)同學聯(lián)調過程中，需要在項目工程中對指定服務開發(fā)同學的機器進行直連，而其他沒有指定的服務將會默認走注冊中心．為了避免對工程代碼的侵入性，我們會在工程中建立應對不同環(huán)境的dubbo.properies，而dubbo.properies不會加入到工程的版本控制當中，主要用于解決不同環(huán)境下的服務直連問題．其中服務的控制粒度可以精確到具體的服務．

3.2.2 通過注冊中心引用服務

通過注冊中心發(fā)現(xiàn)引用服務，Dubbo常用的引用服務方式，可以做到服務自動發(fā)現(xiàn)，負載均衡．正式環(huán)境調用基本基于此模式．其中注冊中心實現(xiàn)有很多種，例如Zookeeper/Redis/Multicast．官方推薦Zookeeper．

3.3 服務請求結構的定義

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

3.3.1 服務的構成

基于上述基于協(xié)議所分析，我們目前協(xié)議將只會鎖定在dubbo/rest，那么我們先看來這兩個協(xié)議在注冊中心注冊的信息是什么樣子的.

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

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

dubbo://
com.service.ProductService

3.3.2 請求體的定義

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

// 1. dubbo協(xié)議的請求體定義
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)];
        }
    },
});
復制代碼

兩者大不同點在于參數(shù)定義上的不同，dubbo需要強制轉換為強類型，而rest不需要.

3.4 服務定義的維護

我們在對服務定義完成之后，接下來就會面臨一個使用上的問題，最直接的方法就是為每個工程每個服務新建一個服務文件，但是一用就會發(fā)現(xiàn)一個問題請求定義的文件分散在不同工程，無法進行統(tǒng)一維護升級，維護成本較高.

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

本文題目：Node調用dubbo服務的探索及實踐-創(chuàng)新互聯(lián)
本文來源：http://weahome.cn/article/dpeggc.html