服务器注册与发现的流程

1. 服务容器Container负责启动,加载,运行服务提供者
2. 服务提供者Provider在启动时,向注册中心注册自己提供的服务
3. 服务消费者Consumer在启动时,向注册中心订阅自己所需的服务
4. 注册中心Registry返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者
5. 服务消费者Consumer,从提供者地址列表,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用
6. 服务消费者Consumer和提供者Provider,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心Monitor

Dubbo的架构层次

接口服务层(Service) : 该层与业务逻辑相关,根据provider和consumer的业务设计对应的接口和实现

配置层(Config) : 对外配置接口,以ServiceConfig和ReferenceConfig为中心

服务代理层(Proxy) : 服务接口透明代理,生成服务的客户端Stub和服务端的Skeleton,以ServiceProxy为中心,扩展接口为ProxyFactory

服务注册层(Registry) : 封装服务地址的注册和发现,以服务URL为中心,扩展接口为RegistryFactory,Registry,RegistryService

路由层(Cluster) : 封装多个提供者的路由和负载均衡,并桥接注册中心,以Invoker为中心,扩展接口为Cluster,Directory,Router和LoadBlance

监控层(Monitor) : RPC调用次数和调用时间监控,以Statistics为中心,扩展接口为MonitorFactory,Monitor和MonitorService

远程调用层(Protocal) : 封装RPC调用,以Invocation和Result为中心,扩展接口为Protocal,Invoker和Exporter

信息交换层(Exchange) : 封装请求响应,同步转异步,以Request和Response为中心,扩展接口为Exchanger,ExchangeChannel,ExchangeClient和ExchangeServer

网络传输层(Transport) : 抽象mina和netty为统一接口,以Message为中心,扩展接口为Channel,Transporter,Client,Server和Codec

数据序列层(Serialize) : 可复用的一些工具,扩展接口为Serialization,ObjectInput,ObjectOutput和ThreadPool

Monitor实现原理

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

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

Dubbo负载均衡策略

• Random LoadBalance(默认) : 随机选取提供者策略,有利于动态调整提供者权重.碰撞率高,调用次数越多,分布越均匀.
• RoundRobin LoadBalance : 轮询选取提供者策略,平均分布,但是存在请求累计的问题.
• LeastActive LoadBalance : 最少活跃调用策略,解决慢提供者接受更少的问题
• ConstantHash LoadBalance : 一致性Hash策略,使相同参数请求总是发到同一提供者,一台机器宕机,可以基于虚拟节点,分摊至其他提供者,避免引起提供者的剧烈变动.

Dubbo容错方案

• Failover Cluster(默认) : 失败自动切换,当出现失败,重试其他服务器,通常用于读操作,但重试会带来更长延迟
• Failfast Cluster : 快速失败,只发起一次调用,失败立即报错.通常用于非幂等性的写操作
• Failsafe Cluster : 失败安全,出现异常时直接忽略,通常用于写入审计日志等
• Failback Cluster : 失败自动恢复,后台记录失败请求,定时重发.通常用于消息通知等操作
• Forking Cluster : 并行调用多个服务器,只要有一个成功即返回.通常用于实时性要求较高的操作
• Broadcast Cluster : 广播所有提供者,逐个调用,任意一台报错则报错,通常用于通知所有提供者更新缓存或本地资源信息

Dubbo通信协议

• Dubbo : 单一长连接和NIO异步通讯,适合大并发小数据量的服务调用,以及消费者远大于提供者.传输协议TCP,异步Hessian序列化.Dubbo推荐使用该协议
• RMI : 采用JDK标准的RMI协议实现,传输参数和返回参数对象都需要实现Serializable接口,使用Java标准序列化机制,使用阻塞时短链接,传输数据包大小混合,消费者和提供者个数差不多,可传文件,传输协议TCP. 多个短连接 TCP 协议传输，同步传输，适用常规的远程服务调用和 RMI 互操作。在依赖低版本的 Common-Collections 包，Java 序列化存在安全漏洞。
• WebService : 基于WebService的远程调用协议,集成CXF实现,提供和原生webService的互操作.多个短链接,基于HTTP传输,同步传输,适用系统集成和跨语言调用.
• HTTP : 基于Http表单提交的远程调用协议,使用Spring的HttpInvoke实现.多个短连接,传输协议HTTP,传入参数大小混合,提供者个数多于消费者,需要给应用程序和浏览器JS调用.
• Hessian : 集成Hessian服务,基于HTTP通讯,采用servlet暴露服务,Dubbo内嵌Jetty作为服务器时默认实现,提供与Hession服务互操作.多个短链接,同步HTTP传输,hessian序列化,传入参数较大,提供者大于消费者,提供者压力较大,可传文件.
• Memcache : 基于Memcache实现的RPC协议.
• Redis : 基于Redis实现的RPC协议.

Dubbo序列化支持java、compactedjava、nativejava、fastjson、fst、hessian2、kryo，其中默认hessian2。其中java、compactedjava、nativejava属于原生java的序列化。

RPC调用过程

1、服务消费者（client客户端）通过调用本地服务的方式调用需要消费的服务；

2、客户端存根（client stub）接收到调用请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息体；

3、客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端；

4、服务端存根（server stub）收到消息后进行解码（反序列化操作）；

5、服务端存根（server stub）根据解码结果调用本地的服务进行相关处理；

6、本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）；

7、服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消费方；

8、客户端存根（client stub）接收到消息，并进行解码（反序列化）；

9、服务消费方得到最终结果；