专栏首页捉虫大师小白也能看懂的dubbo3应用级服务发现详解
原创

小白也能看懂的dubbo3应用级服务发现详解

搜索关注微信公众号"捉虫大师",后端技术分享,架构设计、性能优化、源码阅读、问题排查、踩坑实践。

本文已收录 https://github.com/lkxiaolou/lkxiaolou 欢迎star。

dubbo 是一款开源的 RPC 框架,主要有3个角色: 提供者(provider)消费者(consumer)注册中心(registry)

img1.png

提供者启动时向注册中心注册服务地址,消费者启动时订阅服务,并通过获取到的提供者地址发起调用,当提供者地址变更时,通过注册中心向消费者推送变更。这就是 dubbo 主要的工作流程。

在2.7.5之前,dubbo 只支持接口级服务发现模型,>=2.7.5的版本提供了接口级与应用级两种服务发现模型,3.0之后的版本应用级服务发现更是非常重要的一个功能。

本文将从为什么需要引入应用级服务发现,dubbo 实现应用级服务发现的难点以及dubbo3 是如何解决这些问题这三个部分进行讲解。

开始前,我们先了解下 dubbo 最初提供的接口级服务发现是怎样的。

接口级服务发现长啥样?

dubbo 服务的注册发现是以接口为最小粒度的,在 dubbo 中将其抽象为一个URL,大概长这样:

dubbo://10.1.1.123:20880/org.newboo.basic.api.MyDemoService?anyhost=true&application=ddog-my-demo&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.newboo.basic.api.MyDemoService&methods=setUser,getUser&owner=roshilikang&release=2.7.6&side=provider&threads=500

看着很乱?捋一捋:

img2.png
  • 协议代表提供服务的协议,如果注册了 grpc 服务,这里就是 grpc://
  • ipport 代表是哪台机器的哪个端口提供服务
  • interface 代表了注册的接口名,它直接对应到代码中需要暴露服务的 interface,如下:
package org.newboo.basic.api;

import org.newboo.basic.model.User;

public interface MyDemoService {
    void setUser(User user);
    User getUser(String uid);
}
  • 参数代表了服务的一些参数,可能是元数据,也可能是配置信息

细心的你一定发现了,一个 interface 可以包含多个 dubbo 接口,所以把它称为接口级服务发现有些不妥,应该是服务级服务发现,但服务的定义比较模糊,可能会被误认为是应用,甚至后面介绍的 dubbo 应用级服务发现使用的关键字也是 service,所以我们用接口级这个更加易懂的概念来代替。

接口级服务发现有什么问题?

数据太多

无论是存储还是变更推送压力都可能遇到瓶颈,数据多表现在这两个方面:

  • 注册的单条数据太大

这个问题好解决:拆!

dubbo 在 2.7 之后的版本支持了元数据中心配置中心,对于URL的参数进行分类存储。持久不变的(如application、method等)参数存储到元数据中心中,可能在运行时变化(timeout、tag)的存储到配置中心中

img3.png
  • 注册数据条数太多
img4.png

无论是增加一台机器还是增加一个接口,其增长都是线性的,这个问题比单条数据大更严重。

当抹去注册信息中的 interface 信息,这样数据量就大大减少

img5.png

非主流

只用过 dubbo 的同学可能觉得这很主流。

但从服务发现的角度来看:

无论是用的最多的服务注册发现系统 DNS,又或者是 SpringCloud 体系、K8S 体系,都是以应用为维度进行服务注册发现的,只有和这些体系对齐,才能更好地与之进行打通。

在我了解的范围里,目前只有 dubboSOFARPCHSF 三个阿里系的 RPC 框架支持了接口级的服务发现。

接口级服务发现如何使用

provider端暴露服务:

<dubbo:registry address="zookeeper://127.0.0.1:2181"/>

<dubbo:service interface="org.newboo.basic.api.MyDemoService" ref="myNewbooDemoService"/>

consumer端引用服务:

<dubbo:registry address="zookeeper://127.0.0.1:2181"/>

<dubbo:reference id="myNewbooDemoService" interface="org.newboo.basic.api.MyDemoService"/>
img6.png

本地调用远程的方法时,只需要配置一个 reference,然后直接使用 interface 来调用,我们不必去实现这个 interaface,dubbo 自动帮我们生成了一个代理进行 RPC 调用,屏蔽了通信的细节,让我们有种像调用本地方法一样调用远程方法的感觉,这也是 dubbo 的优势。

从这里我们能看出为什么 dubbo 要设计成接口级服务发现,因为要为每一个 interface 生成一个代理,就必须定位到该 interface 对应服务暴露的服务地址,为了方便,dubbo 就这么设计了。

如果要实现应用级服务发现你会怎么做?

如果让我来设计应用级服务发现,注册不必多说,按应用名注册即可。

但这里有个隐藏问题是应用名的唯一性,应用名必须得很好的管理起来,否则重复、随意改动都可能导致服务发现失效

至于订阅,在目前 dubbo 机制下,必须得告诉消费者消费的每个接口是属于哪个应用,这样才能定位到接口部署在哪里。

难点是什么

实现 dubbo 应用级服务发现,难点在于

  • 兼容性,除了服务发现,其他改动点尽量少,且能兼容接口级到应用级的过渡
  • 接口到应用的部署关系,在接口级服务发现中,是不需要关心接口部署在哪个应用上的,但换做应用级,必须得知道这点,但这点就增加了开发者的使用难度,有没有方案尽量屏蔽细节?
img7.png

dubbo3 是如何解决这些问题的?

兼容性

保留接口级服务发现,且默认采取双注册方式,可配置使用哪种服务发现模型,如下配置使用应用级服务发现

<dubbo:registry address="zookeeper://127.0.0.1:2181?registry-type=service"/>

居然使用了service这个关键字?

如何查找接口对应的应用

  • 方案1:手动配置,实现简单,架构简单,但用户使用成本高,这种方式 dubbo3 已支持
<dubbo:service services="ddog-my-demo-p0" interface="org.newboo.basic.api.MyDemoService" ref="myNewbooDemoService"/>
  • 方案2:服务自省

名词有点高大上,但道理很简单,让 dubbo 自己去匹配,提供者注册的时候把接口和应用名的映射关系存储起来,消费者消费时根据接口名获取到部署的应用名,再去做服务发现。

数据存储在哪里?显然元数据中心非常合适。该方案用户使用起来和之前接口级没有任何不同,但需要增加一个元数据中心,架构变得复杂。

且有一个问题是,如果接口在多个应用下部署了,dubbo 查找的策略是都去订阅,这可能在某些场景下不太合适。

img8.png

最后

本文从接口级服务发现讲到应用级服务发现,包含了为什么 dubbo 设计成接口级服务发现,接口级服务发现有什么痛点?基于 dubbo 现状如何设计应用级服务发现,应用级服务发现实现有什么难点等等问题进行解答,相信看完的小伙伴一定有所收获。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 最近面试小心被问 Dubbo3.0!

    最近不是 Dubbo3.0 正式发布了嘛,我也推了阿里巴巴中间件发的那篇文章,但是私下还是有小伙伴让我用大白话说说和之前版本到底有哪些不同。

    Guide哥
  • 小白都能看得懂的服务调用链路追踪设计与实现

    系统服务调用链路是指从用户或是机器发起服务请求到结束,按顺序记录整个请求链路的相关数据,以备后续查询分析、定位系统 bug 或性能优化所用。

    IT技术小咖
  • Nacos 2.0 正式发布| 性能测试报告已出,请注意查收

    Nacos 项目从 2008 年开始,开始在阿里巴巴内部孵化。近年来受 Eureka、Consul 等项目的影响,Nacos 越来越受欢迎。

    kirito-moe
  • 干货 | 携程酒店RSocket实践

    刘诚,携程酒店研发性能架构师。2014年加入携程,致力于通过架构的演进,控制企业硬件成本。

    携程技术
  • 云原生|dubbogo 3.0

    自从 2011 年 Dubbo 开源之后,被大量中小公司采用,一直是国内最受欢迎的 RPC 框架。2014 年,由于阿里内部组织架构调整,Dubbo 暂停维护了...

    heidsoft
  • 长连接网关技术专题(五):喜马拉雅自研亿级API网关技术实践

    网关是一个比较成熟的产品,基本上各大互联网公司都会有网关这个中间件,来解决一些公有业务的上浮,而且能快速的更新迭代。如果没有网关,要更新一个公有特性,就要推动所...

    JackJiang
  • 给你一个理由放弃dubbo和spring cloud,拥抱华为全栈微服务解决方案servicecomb

    Martin Flower定义的微服务是基于REST,Spring cloud就是其标准的实现,通用但HTTP协议比较冗余,短连接建立也较耗时,消息体一般基于J...

    Zeal
  • 解读,有微信关系链数据的小游戏开测了

    先明确一点:小游戏是小程序的一个子集,它只是用了不同的技术框架,账号体系还是小程序体系,今天的文章是给不懂技术的同学看的,当然,懂技术不大了解流程的同学也可以看...

    花叔
  • 实战视频01丨Web云开发快速开始

    云开发(CloudBase)是云端一体化的云服务平台,是国内 Serverless 理念的领先实践,使用云开发,开发者无须关心服务器搭建和管理,只需编写业务代码...

    腾讯云开发TCB
  • 校招| C++ 后台开发学习路线

    之前一直没写的原因在于自己觉得自己懂得太少,还没成为一个大佬,还没成为一个精通某个领域的专家,怎么能教别人如何学习呢?

    C语言与CPP编程
  • 聊聊阿秀过去三年间做的最正确的一件事 | 快来薅羊毛

    我买的大部分是技术书,也有一些非技术书,比如《明朝那些事儿》、《平凡的世界》之类的。

    拓跋阿秀
  • 浅谈偏向锁、轻量级锁、重量级锁

    为了换取性能,JVM在内置锁上做了非常多的优化,膨胀式的锁分配策略就是其一。理解偏向锁、轻量级锁、重量级锁的要解决的基本问题,几种锁的分配和膨胀过程,有助于编写...

    搜云库技术团队
  • 一个人的网站开发

    写在前面的话: 前段时间,一个朋友准备做一个教育相关的事情,其人在深圳,大城市嘛,总是想利用业余时间考个证了,听个培训课程了等等来给自己充充电,自己经常去的一...

    小小科
  • 网络协议之:WebSocket的消息格式

    我们知道WebSocket是建立在TCP协议基础上的一种网络协议,用来进行客户端和服务器端的实时通信。非常的好用。最简单的使用WebSocket的办法就是直接使...

    程序那些事
  • Java程序员需要突破的技术要点

    海仔
  • 小灯灯实战系列《一》记一次小程序开发过程

    写在前面 前后两天花了大约四五个小时制作完了自己第一个小程序,当然是没法发布的,小程序的发布要求还是挺严格的:企业资质、HTTPS、审核。 先大概介绍下自己,我...

    极乐君
  • RESTFul服务开发必备的一款IDEA插件!用了就离不开了

    我们经常谈 RESTful Web 服务开发,但是我发现很多人实际就根本不懂这个概念。只是听着大家都这么说,也就跟着一起说了,当代迷惑性为之一!

    Guide哥
  • Java后端工程师必备书单(含大后端方向相关书籍)

    作者黄小斜,斜杠青年,某985硕士,阿里研发工程师,于2018 年秋招拿到 BAT 头条、网易、滴滴等 8 个大厂 offer

    黄小斜学Java
  • 【程序源代码】非常棒的java学习面试指南

    最近好多同学想学习java,我在网上找了找终于找到这个指南。这一个非常不错的java学习指南。内容包含的比较全面,知识点也比较完整。

    程序源代码

扫码关注云+社区

领取腾讯云代金券