Dubbo 一些基础知识

Dubbo 核心组件

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

Dubbo服务注册与发现流程

• 服务容器 Container 负责启动，加载，运行服务提供者。
• 服务提供者 Provider 在启动时，向注册中心注册自己提供的服务
• 服务消费者 Consumer 在启动时，向注册中心订阅自己所需的服务。
• 注册中心 Registry返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
• 服务消费者 Consumer，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

Dubbo Monitor实现原理

Consumer端在发起调用之前会先走filter链； provider端在接收到请求时也是先走 filter链，然后才进行真正的业务逻辑处理。默认情况下，在 consumer和provider的 filter链中都会有 Monitorfilter

1. Monitor filter向 DubboMonitor发送数据
2. DubboMonitor将数据进行聚合后（默认聚合1min中的统计数据）暂存到ConcurrentMap< Statistics, AtomicReference> statisticsMap，然后使用一个含有3线程（线程名字：DubboMonitor Send Timer）的线程池每隔1min钟，调用SimpleMonitorService遍历发迭 statisticsMap中的统计数据，每发送完毕就重置当前的 Statistics的 AtomicReference
3. SimpleMonitor Service将这些聚合数据塞入 Blocking Queue queue中（队列大小为10000）
4. SimpleMonitor Service使用一个后台线程（线程名为DubboMonitor AsyncWriteLog Thread）将 queue中的数据写入文件（该线程以死循环的形式来写
5. SimpleMonitorService还会使用一个含有1个线程（线程名字：DubboMonitor Timer）的线程池每隔5min钟，将文件中的统计数据画成图表

分布式框架

Dubbo 与 Spring Cloud区别

Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。
Spring Cloud是基于Http协议Rest接口调用远程过程的通信，相对来说Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。

Dubbo有哪些注册中心

• Multicast注册中心：Multicast注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现基于网络中组播传输实现。
• Zookeeper注册中心：基于分布式协调系统 Zookeeper实现，采用 Zookeeper的watch机制实现数据变更。
• Reds注册中心：基于Reds实现，采用 key/map存储，keγ存储服务名和类型， map中key存储服务url,vaue服务过期时间。基于Reds的发布汀阅模式通知数据变更。
  ps: 推荐使用ZK作为注册中心
  Dubbo注册中心集群挂了，发布者与订阅者还能通吗？
  可以通讯。启动Dubo时，消费者会从 Zookeeper拉取注册的生产者的地址接口等数据，緩存在本地。每次调用时，按照本地存储的地址进行调用。

Dubbo 容错方案

• Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。
• Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
• Failsafe Cluster：失败安全，出现昇常时，直接忽略。通常用于写入审计日志等操作。
• Failback cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
• Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2″来设置最大并行数。
• Broadcast Cluster：广擂调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

核心配置

异步调用

<dubbo:reference id="helloService" interface="com.gray.service.HelloService"> 
<dubbo:method name="sayHello" async="true" />
 </dubbo:reference>

可以用 RpcContext.getContext().getFuture() 来进行获取Future对象来进行后续的结果等待操作

Dubbo2.0.6+的异步调用

consumer端配置

<dubbo:reference id="fooService" interface="com.alibaba.foo.FooService">
      <dubbo:method name="findFoo" async="true" />
</dubbo:reference>
<dubbo:reference id="barService" interface="com.alibaba.bar.BarService">
      <dubbo:method name="findBar" async="true" />
</dubbo:reference>

方法异步调用后，Consumer端的代码写法：

// 此方法应该返回Foo，但异步后会立刻返回NULL
fooService.findFoo(fooId);
// 立刻得到当前调用的Future实例，当发生新的调用时这个东西将会被覆盖
Future<Foo> fooFuture = RpcContext.getContext().getFuture();
 
// 调用另一个服务的方法
barService.findBar(barId);
// 立刻得到当前调用的Future
Future<Bar> barFuture = RpcContext.getContext().getFuture();
 
// 此时，两个服务的方法在并发执行
// 等待第一个调用完成，线程会进入Sleep状态，当调用完成后被唤醒。
Foo foo = fooFuture.get();
// 同上
Bar bar = barFuture.get();
// 假如第一个调用需要等待5秒，第二个等待6秒，则整个调用过程完成的时间是6秒。

dubbo 2.7之后使用的是CompletableFuture

// 此调用会立即返回null
asyncService.sayHello("world");
// 拿到调用的Future引用，当结果返回后，会被通知和设置到此Future
CompletableFuture<String> helloFuture = RpcContext.getContext().getCompletableFuture();
// 为Future添加回调
helloFuture.whenComplete((retValue, exception) -> {
    if (exception == null) {
        System.out.println(retValue);
    } else {
        exception.printStackTrace();
    }
});

服务降级

<dubbo:reference id="xxService" check="false" interface="com.xx.XxService" timeout="3000" mock="return null" /> 
<dubbo:reference id="xxService2" check="false" interface="com.xx.XxService2" timeout="3000" mock="return 1234" />

• mock=force return+null表示消费方对该服务的方法调用都直接返回nu|值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
• mock= fail:return+nul表示消费方对该服务的方法调用在失败后，再返回nu值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

过滤器

使用

为什么RPC会比HTTP快

• 序列化方式
  RPC服务序列化是针对二进制协议（0/1）来做序列化和反序列化。
  HTTP服务是基于文本的序列化和反序列化，需要读一行一行的文本（比如json格式的），进行序列化和反序列化。
• 报文长度
  RPC服务是自定义的传输协议，一般只传入有效内容
  HTTP服务里面包括很多没用的报文内容，比如Http Header里面的accept，referer等等
• 连接的复用
  RPC服务是基于TCP/IP协议的，是长连接。
  HTTP服务大都是短连接，虽然HTTP1.1支持长连接，但是这个也是要取决于服务端是否支持长连接，不太可控。