Node 調(diào)用 dubbo 服務(wù)的探索及實(shí)踐

2.Dubbo簡介

2.1 什么是dubbo

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

2.2 流程圖

• Provider  : 暴露服務(wù)的服務(wù)提供方。
• Consumer  : 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
• Registry  : 服務(wù)注冊(cè)與發(fā)現(xiàn)的注冊(cè)中心。
• Monitor  : 統(tǒng)計(jì)服務(wù)的調(diào)用次調(diào)和調(diào)用時(shí)間的監(jiān)控中心。
• Container  : 服務(wù)運(yùn)行容器。

3. 具體實(shí)現(xiàn)

3.1 協(xié)議選擇

3.2 如何引用服務(wù)

目前引用服務(wù)有兩個(gè)方案，分別是

• 直接引用
• 通過注冊(cè)中心引用服務(wù)

3.2.1 直接引用服務(wù)

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

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

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

3.2.2 通過注冊(cè)中心引用服務(wù)

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

3.3 服務(wù)請(qǐng)求結(jié)構(gòu)的定義

服務(wù)請(qǐng)求體結(jié)構(gòu)，是在對(duì)dubbo在注冊(cè)中心上注冊(cè)信息的抽象之后的一層封裝，一方面可以提升開發(fā)人員的開發(fā)效率，另外降低開發(fā)人員自身手動(dòng)拼接請(qǐng)求的錯(cuò)誤率．

3.3.1 服務(wù)的構(gòu)成

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

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

我們對(duì)這兩個(gè)協(xié)議公共部分進(jìn)行提取一下

dubbo://
com.service.ProductService

3.3.2 請(qǐng)求體的定義

基于上述服務(wù)結(jié)構(gòu)構(gòu)成的分析，dubbo和rest服務(wù)請(qǐng)求結(jié)構(gòu)構(gòu)成大體類似，我們對(duì)不同的協(xié)議請(qǐng)求的可以做如下定義.

// 1. dubbo協(xié)議的請(qǐng)求體定義
services.ProductService = (dubbo) => dubbo.proxyService({
    dubboInterface: 'com.service.ProductService',
    methods: {
        getById(id) {
            return [java.Long(id)];
        },
        getByName(name) {
            return [java.String(name)];
        }
    },
});
復(fù)制代碼

// rest 請(qǐng)求體定義
services.ProductService = (dubbo) => dubbo.proxyService({
    dubboInterface: 'com.service.ProductService',
    methods: {
        getById(id) {
            return {
                method: 'get',
                query: [parseInt(id)]
            };
        },
        getByName(name) {
            return [String(name)];
        }
    },
});
復(fù)制代碼

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

3.4 服務(wù)定義的維護(hù)

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

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