Dubbo分布式服务框架介绍

随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。而Dubbo则是SOA服务化治理方案的一个核心框架。

Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。

Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。

作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：

Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出 服务提供方（Provider） 和 服务消费方（Consumer） 两个角色。

Dubbo包含 远程通讯、服务集群和服务发现与注册 三个核心部分。提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo服务组件调用关秕说明 ：

Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。

下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：

从上图可以看出， Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的） 。

根据官方提供的，对于上述各层之间关系的描述，如下所示：

dubbo自带的运维工具dubbo-admin，主要面向开发人员去管理服务，携带很多管理、控制等功能，然后在dubbo新版本又推出了qos（Quality of Service），主要面向运维管理。我在之前公司有用到次功能，在和k8s结合时，通过http发送主动下线功能（下线注册，但不下线服务），等到流量完全停止，在下线pod，实现平滑发布。

怎么样去管理？

dubbo通过 QosProtocolWrapper 这个包装器实现qos发布，QosProtocolWrapper 是Protocol 三大包装器(filter,listener,qos)其中之一，默认会开启qos功能，可以配置关闭

qos 主要提供了ls,online,offline,help 功能，具体说，只有三种，上下线服务和查看服务

我们跟读一下源码，看看qos 服务的启动，请求处理，上下线等。

在dubbo 生产者服务暴露和消费者消费引用的过程中都会启动qos，并且qos 通过cas来保证一个jvm只启动一次。

同样qos 功能也是通过netty启动server，处理类指定为 QosProcessHandler，这个handler实现了netty的 ByteToMessageDecoder 可以将网络流中的字节解码为对象

channelActive() 方法含有为连接建立的时候回调，这里有个定时任务500ms，会刷一个美体的dubbo给客户端，我们验证下。

我们看看 QosProcessHandler#decode 是怎么处理请求的。

上面方法讲究，先读取第一个字节判断请求是http 还是 tcp，为什么用第一个字节呢，我们知道http信息头开始为 GET /xx 或者 POST /xx，第一个字符要么G要么P，判断为http 则用http编解码，如果为tcp 则用 LineBasedFrameDecoder 编解码，这是一个换行分割读取的解码方式遇到(\n,\r)[就是telnet时候的回车]时，就截断，如果为tcp 还会添加一个 IdleStateHandler 作为心跳检测，最后处理指令的handler 为 TelnetProcessHandler。

先演示下效果

为了便于观察我们这里看http的处理指令的方式 HttpProcessHandler。

HttpCommandDecoder decode (msg)会将get或者post请求携带的路径等返回给 commandContext , BaseCommandclass 为指令扩展点会根据uri 传入的指令，来指定要处理的类，优点类似策略模式。我们看看offline 是怎么处理的

可以传入服务，默认所有服务，18行中从注册工厂中获取服务对应的注册中心，然后调用注册中心的unregister() 最后层层调用到zk客户端的delete()方法来，删除zk临时节点。

qos 的功能和简单，之所以单独拿出来讲是因为这里涵盖了我们web开发中常提到的“http服务器”概念，通过netty 启动服务，然后处理请求。

目前来看jni反而是一个比较通用的方法，

c++的服务端使用jni对服务进行包装，通过服务总线(dubbo)发布服务，最终打包成一个jar包，启动服务。

c++客户端也使用jni方式通过服务总线(dubbo)调用服务。

我简单研究了githup中的dubbo-python、dubbo-node-client、dubbo-php-client。

基本都是这样做的：

问题，这些各个语言的dubbo库，都只是客户端的，对于服务端没有支持。

dubbo 是一款开源的 RPC 框架，主要有3个角色： 提供者（provider） 、 消费者（consumer） 、 注册中心（registry）

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

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

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

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

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

看着很乱？捋一捋：

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

这个问题好解决： 拆！

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

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

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

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

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

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

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

provider端暴露服务：

consumer端引用服务：

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

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

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

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

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

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

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

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

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

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