Node调用dubbo服务的探索及实践-创新互联

2.Dubbo简介

2.1 什么是dubbo

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

2.2 流程图

• Provider  : 暴露服务的服务提供方。
• Consumer  : 调用远程服务的服务消费方。
• Registry  : 服务注册与发现的注册中心。
• Monitor  : 统计服务的调用次调和调用时间的监控中心。
• Container  : 服务运行容器。

3. 具体实现

3.1 协议选择

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  ,这样就可以解决文件分散在不同工程导致的维护问题.