当前位置: 首页>编程语言>正文

dubbo如何调用amall接口 dubbo接口本地调用

分布式集群模式下,如何使用dubbo远程调用本地第三方服务

使用直接模式

例如:

第三方服务的service实现类的@DubboService改成@DubboService(register = false)

@DubboService(register = false)
public class WihPeriodServiceImpl implements WihPeriodService{

    .......
}

调用方服务的@DubboReference(check = false,timeout = 50000,retries = 0)改成@DubboReference(check = false,timeout = 50000,retries = 0, url = "dubbo://127.0.0.1:21883")

@RestController
public class PeriodController {

    @DubboReference(check = false,timeout = 50000,retries = 0, url = "dubbo://127.0.0.1:21883")
    WihPeriodService periodService;

     ......
}

dubbo的配置解析

#增加应用共享配置
dubbo:
  application:                                   #应用配置
    name: hssc-ess-service                       #dubbo应用名     
    owner: heilan-group                          #服务的所有者 
  protocol:                                      #指定通信规则(通信协议&通信端口)
    name: dubbo                                  #dubbo协议
    port: 21882                                  #dubbo协议端口号
  registry:                                      #注册中心配置
    address: zookeeper://192.168.207.152:2181    #注册中心的地址
    check: false                                 #关闭注册中心启动时检查(注册订阅失败时报错)
    group: hssc-group                            #设置zookeeper的分组
    simplified: true                             #减少注册中心的配置信息               
    timeout: 30000                               #timeout的超时时间
  metadata-report:                               #元数据中心
    address: zookeeper://192.168.207.152:2181
    retry-times: 30                              #重试时间
    cycle-report: false
    group: hssc-group
    timeout: 30000
  config-center:                                 #配置中心
    address: zookeeper://192.168..207.152:2181
    check: false
    group: hssc-group
    timeout: 30000

本地的hssc-wih服务可以启动成功,hssc-wih服务远程调用了hssc-perm服务。但本地没有启动hssc-perm服务注册到注册中心。

dubbo的配置加了check=false就不会启动失败

注意区别:

  • dubbo.reference.check=false,强制改变所有reference的check值,就算配置中有声明,也会被覆盖。
  • dubbo.consumer.check=false,是设置check的缺省值,如果配置中有显式的声明,如:<dubbo:reference check="true" />,不会受影响。
  • dubbo.registry.check=false,前面两个都是指订阅成功,但提供者列表是否为空是否报错,如果注册订阅失败时,也允许启动,需使用此选项,将在后台定时重试。

 

元数据中心介绍

dubbo如何调用amall接口 dubbo接口本地调用,dubbo如何调用amall接口 dubbo接口本地调用_dubbo如何调用amall接口,第1张

服务治理中的元数据(Metadata)指的是服务分组、服务版本、服务名、方法列表、方法参数列表、超时时间等,这些信息将会存储在元数据中心之中。与元数据平起平坐的一个概念是服务的注册信息,即:服务分组、服务版本、服务名、地址列表等,这些信息将会存储在注册中心中。稍微一对比可以发现,元数据中心和注册中心存储了一部分共同的服务信息,例如服务名。两者也有差异性,元数据中心还会存储方法列表即参数列表,注册中心存储了服务地址。上述的概述,体现出了元数据中心和注册中心在服务治理过程中,担任着不同的角色。为了有一个直观的对比,我整理出了下面的表格:

 

元数据

注册信息

职责

描述服务,定义服务的基本属性

存储地址列表

变化频繁度

基本不变

随着服务上下线而不断变更

数据量



数据交互/存储模型

消费者/提供者上报,控制台查询

PubSub 模型,提供者上报,消费者订阅

主要使用场景

服务测试、服务 MOCK

服务调用

可用性要求

元数据中心可用性要求不高,不影响主流程

注册中心可用性要求高,影响到服务调用的主流程

下面我会对每个对比点进行单独分析,以加深对元数据中心的理解。

职责

在 Dubbo 2.7 版本之前,并没有元数据中心的概念,那时候注册信息和元数据都耦合在一起。Dubbo Provider 的服务配置有接近 30 个配置项,排除一部分注册中心服务治理需要的参数,很大一部分配置项仅仅是 Provider 自己使用,不需要透传给消费者;Dubbo Consumer 也有 20 多个配置项。在注册中心之中,服务消费者列表中只需要关注 application,version,group,ip,dubbo 版本等少量配置。这部分数据不需要进入注册中心,而只需要以 key-value 形式持久化存储在元数据中心即可。从职责来看,将不同职责的数据存储在对应的组件中,会使得逻辑更加清晰。

变化频繁度

注册信息和元数据耦合在一起会导致注册中心数据量的膨胀,进而增大注册中心的网络开销,直接造成了服务地址推送慢等负面影响。服务上下线会随时发生,变化的其实是注册信息,元数据是相对不变的。

数据量

由于元数据包含了服务的方法列表以及参数列表,这部分数据会导致元数据要比注册信息大很多。注册信息被设计得精简会直接直接影响到服务推送的 SLA。

数据交互/存储模型

注册中心采用的是 PubSub 模型,这属于大家的共识,所以注册中心组件的选型一般都会要求其有 notify 的机制。而元数据中心并没有 notify 的诉求,一般只需要组件能够提供 key-value 的存储结构即可。

主要使用场景

在服务治理中,注册中心充当了通讯录的职责,在复杂的分布式场景下,让消费者能找到提供者。而元数据中心存储的元数据,主要适用于服务测试、服务 MOCK 等场景,这些场景都对方法列表、参数列表有所诉求。在下面的小节中,我也会对使用场景进行更加详细的介绍。

可用性要求

注册中心宕机或者网络不通会直接影响到服务的可用性,它影响了服务调用的主路径。但一般而言,元数据中心出现问题,不会影响到服务调用,它提供的能力是可被降级的。这也阐释了一点,为什么很多用户在 Dubbo 2.7 中没有配置元数据中心,也没有影响到正常的使用。元数据中心在服务治理中扮演的是锦上添花的一个角色。在组件选型时,我们一般也会对注册中心的可用性要求比较高,元数据中心则可以放宽要求。

元数据中心的价值

小孩子才分对错,成年人只看利弊。额外引入一个元数据中心,必然带来运维成本、理解成本、迁移成本等问题,那么它具备怎样的价值,来说服大家选择它呢?上面我们介绍元数据中心时已经提到了服务测试、服务 MOCK 等场景,这一节我们重点探讨一下元数据中心的价值。

降低地址推送的时延

由于注册中心采用的是 PubSub 模型,数据量的大小会直接影响到服务地址推送时间,不知道你有没有遇到过 No provider available 的报错呢?明明提供者已经启动了,但由于注册中心推送慢会导致很多问题,一方面会影响到服务的可用性,一方面也会增加排查问题的难度。

在一次杭州 Dubbo Meetup 中,网易考拉分享了他们对 Zookeeper 的改造,根源就是

推送量大 -> 存储数据量大 -> 网络传输量大 -> 延迟严重

这一实际案例佐证了元数据改造并不是凭空产生的需求,而是切实解决了一个痛点。

服务测试 & 服务 MOCK

在 Dubbo 2.7 之前,虽然注册中心耦合存储了不少本应属于元数据的数据,但也漏掉了一部分元数据,例如服务的方法列表,参数列表。这些是服务测试和服务 MOCK 必备的数据,想要使用这些能力,就必须引入元数据中心。例如开源的 Dubbo Admin 就实现了服务测试功能,用户可以在控制台上对已经发布的服务提供者进行功能测试。可能你之前有过这样的疑惑:为什么只有 Dubbo 2.7 才支持了服务测试呢?啊哈,原因就是 Dubbo 2.7 才有了元数据中心的概念。当然,服务 MOCK 也是如此。

dubbo如何调用amall接口 dubbo接口本地调用,dubbo如何调用amall接口 dubbo接口本地调用_推送_02,第2张

其他场景

可以这么理解,任何依赖元数据的功能,都需要元数据中心的支持。其他场景还包括了网关应用获取元数据来进行泛化调用、服务自动化测试等等。再描述一个可能的场景,抛砖引玉。在一次南京 Dubbo Meetup 上,dubbo.js 的作者提及的一个场景,希望根据元数据自动生成 NodeJs 代码,以简化前端的开发量,也是元数据的作用之一。这里就需要发挥各位的想象力了

Dubbo 配置元数据中心

目前 Dubbo 最新的版本为 2.7.4,目前支持的几种元数据中心可以从源码中得知(官方文档尚未更新):

dubbo如何调用amall接口 dubbo接口本地调用,dubbo如何调用amall接口 dubbo接口本地调用_zookeeper_03,第3张

支持 consul、etcd、nacos、redis、zookeeper 这五种组件。

 


https://www.xamrdz.com/lan/5zc1944417.html

相关文章: