dubbo3的基本概述2021-11-16

Dubbo3的简单学习

Apache Dubbo 是一款微服务开发框架，它提供了 RPC通信 与 微服务治理 两大关键能力。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力， 同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。

dubbo的基础功能：

• 服务发现
• 流式通信
• 负载均衡
• 流量治理
• …

使用dubbo的优势：

• 开箱即用
  • 易用性高，如 Java 版本的面向接口代理特性能实现本地透明调用
  • 功能丰富，基于原生库或轻量扩展即可实现绝大多数的微服务治理能力
• 超大规模微服务集群实战
  • 高性能的跨进程通信
  • 地址发现、流量治理层面，轻松支持百万规模集群实例
• 企业级微服务治理
  • 服务测试
  • 服务mock

dubbo中的stub和mock

dubbo服务中包含两个功能，一个stub（本地存根），一个是mock（本地伪装）。

1. 本地存根（stub）

• 作用

  • 控制是否调用服务端dubbo服务。比如：
    • 参数检查不通过，不发起调用
    • 缓存中有了，不发起调用
  • 控制调用完毕后的行为。比如：
    • 写缓存，发送信息之类
  • 控制接口异常时的行为（跟mock类似）

• 缺点

  类爆炸：消费端或者服务端需要为每个接口定义一个xxxServiceStub，而且这个类中还必须实现所有的方法。

• 使用场景：如果想控制是否真实调用dubbo服务，或者在调用前后做些事情的时候，可以考虑使用这个机制。可以给接口定义默认的Stub（定义在Provider），也可以各个Consumer自己定义。

• 补充说明

  有两种方式可以实现，一个是定义在Provider（ServiceConfig），一个是定义在Consumer（ReferenceConfig）。二者的区别就在于：

  1. 如果定义在ServiceConfig中，那么只要定义的XXXServiceStub类包含在了用户所暴露的dubbo服务接口的jar包中，那么客户端无需再定义，直接就可以使用，相当于定义了服务端的一个默认行为。当然，客户端也可以强制指定referenceConfig.setStub(false)来关闭这个默认行为。或者自己指定Stub类，比如：referenceConfig.setStub(“DubboServiceStub”)。DubboServiceStub是Consumer自己定义的Stub。
  2. 如果定义在了ReferenceConfig中，那么就不是全局的行为了，只是这个Consumer自己的行为。其他的消费者不可见。

2.本地伪装（mock）—感觉类似于Springcloud中hystrix的服务异常处理机制

• 作用

  调用dubbo接口异常（Provicer不可用、超时等抛出RpcException）后，可以指定默认的返回值。也可以强制指定返回mock值，此时不再调用到Provider，Consumer直接返回了。
  比如：用户认证服务的provider都死掉了，这里可以加上Mock，直接返回用户认证失败的消息即可，而不用再抛出异常。

• 使用场景

  想要定义接口异常时的默认返回值时可以考虑使用Mock。类似于软降级。

• 缺点

  使用Mock后，异常消息不再被打印，被吞掉了。

• 注意事项

  1. 与Stub不同，Mock只能使用在Consumer，不能定义在Provider。另外，可以不实现XXXServiceMock类，直接配置返回也是可以的。
  2. Mock的配置极其方便，而且支持配置到方法级别。详细参见参考文档。
  3. Stub中可以指定异常时的返回值，Mock也能指定。那么如果二者都指定了，那怎么办？以Mock为准。如果指定了Mock，其实Stub中的就自动失效了，因为指定Mock后，异常被它截获并处理掉了，不会在Stub中再走到RpcException中了。
  4. 如果想提供Provider对于RpcException的默认处理，可以使用Stub。Mock没法提供这样的功能，只能每个Consumer自己定义。而且由2可知，一旦Mock定义了，Stub的默认行为也被覆盖了。符合Consumer定义大于默认行为的原则。

服务发现

dubbo服务发现采用的是一种client-based的服务发现机制，通常还需要部署额外的第三种注册中心组件来协调服务发现过程，如常用的Nacos、Consul、Zookeeper等。

dubbo3的优势

• dubbo3应用级服务发现，以应用粒度组织地址数据
• dubbo3借口级服务发现，以接口粒度组织地址数据

dubbo3的服务发现模型：

采用上述的模型使dubbo在架构兼容性、可伸缩性都更具有优势。

Dubbo3 服务发现模型更适合构建可伸缩的服务体系，这点要如何理解？ 这里先举个简单的例子，来直观的对比 Dubbo2 与 Dubbo3 在地址发现流程上的数据流量变化：假设一个微服务应用定义了 100 个接口（Dubbo 中的服务）， 则需要往注册中心中注册 100 个服务，如果这个应用被部署在了 100 台机器上，那这 100 个服务总共会产生 100 * 100 = 10000 个虚拟节点；而同样的应用， 对于 Dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关）， 只注册和机器实例数相等的 1 * 100 = 100 个虚拟节点到注册中心。 在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是， 地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样， 因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。

rpc通信协议

dubbo3提供了triple、dubbo2协议，这是dubbo框架的原生协议，除此之外，Dubbo3 也对众多第三方协议进行了集成，并将它们纳入 Dubbo 的编程与服务治理体系， 包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。

• triple协议

容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。 客户端中使用的传统通信协议（ RESTFUL或其他基于 HTTP 的自定义协议）难以满足应用在性能、可维护性、扩展性、安全性等方便的需求。一个跨语言、模块化的协议会逐渐成为新的应用开发协议标准。自从 2017 年 gRPC 协议成为 CNCF 的项目后，包括 k8s、etcd 等越来越多的基础设施和业务都开始使用 gRPC 的生态，作为云原生的微服务化框架， Dubbo 的新协议也完美兼容了 gRPC。并且，对于 gRPC 协议中一些不完善的部分， Triple 也将进行增强和补充。

服务流量管理

通过dubbo定义的路有规则，实现对流量分布的控制

流量管理

流量管理的本质是将请求根据制定好的路由规则分发到应用服务上：

其中：

• 路由规则可以有多个，不同的路由规则之间存在优先级，如：Router（1）–>Router(2)—>Route(n)
• 一个路由规则可以路由到多个不同的应用服务。如：Router（2）即可以路由到Service（1）也可以路由到Service（2）
• 多个不同的路由规则可以路由到同一个应用服务。如：Router(1)和Router(2)都可以路由到Service(2)

路由规则

• 动态路由
• 权重路由
• 蓝绿部署
• 金丝雀部署

配置

描述dubbo支持的配置，dubbo的动态配置能力。

dubbo配置主要分为几大类：启动阶段配置项、服务治理规则、动态配置项。

启动阶段配置项

Dubbo启动时读取的配置项，用于初始化各个组件，不会监听这些配置项的变化。
启动阶段配置参考链接

服务治理规则

服务治理规则主要作用是改变运行时服务的行为和选址逻辑，达到限流，权重配置等目的，包括覆盖规则、标签路由、条件路由、条件路由。
服务治理规则的用法介绍请参考服务治理参考链接

动态配置项

动态配置项一般用于控制动态开关。
Dubbo启动后监听动态配置项，当配置发生变化时，会自动进行相应的处理。
动态配置参考链接

部署架构(注册中心、配置中心、元数据中心)

• 注册中心。协调Consumer与Provider之间的地址注册与发现

• 配置中心
  • 存储dubbo启动阶段的全局配置，保证配置的跨环境共享与全局一致性
  • 负责服务治理规则（路由规则、动态配置等）的存储与推送。
    
• 元数据中心
  • 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
  • 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展