Dubbo工作流程

一、dubbo整体架构

 

• 其中Service 和 Config 层为 API，对应服务提供方来说是使用ServiceConfig来代表一个要发布的服务配置对象，对应服务消费方来说ReferenceConfig代表了一个要消费的服务的配置对象。可以直接初始化配置类，也可以通过 spring 解析配置生成配置类。
• proxy 服务代理层：扩展接口为 ProxyFactory，dubbo实现的SPI主要JavassistProxyFactory（默认使用）和JdkProxyFactory，用来对服务提供方和服务消费方的服务进行代理。
• registry 注册中心层：封装服务地址的注册与发现，扩展接口为 Registry , RegistryService,Dubbo提供的扩展接口实现为ZookeeperRegistry，RedisRegistry，MulticastRegistry，DubboRegistry。
• 扩展接口RegistryFactory，dubbo提供的扩展接口实现DubboRegistryFactory，DubboRegistryFactory，RedisRegistryFactory，ZookeeperRegistryFactory。
• cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，
• 扩展接口为 Cluster , Directory , Router ,LoadBalance。
• monitor 监控层：RPC 调用次数和调用时间监控，扩展接口为 MonitorFactory , Monitor , MonitorService。
• protocol 远程调用层：封将 RPC 调用，扩展接口为 Protocol , Invoker , Exporter。
• exchange 信息交换层：封装请求响应模式，同步转异步，扩展接口为 Exchanger , ExchangeChannel ,ExchangeClient , ExchangeServer
• transport 网络传输层：抽象 mina 和 netty 为统一接口扩展接口为 Channel , Transporter , Client , Server , Codec
• serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization ,ObjectInput , ObjectOutput , ThreadPool

二、dubbo服务发布原理

　　首先 ServiceConfig 类拿到对外提供服务的实际类 ref(如：UserServiceImpl),然后通过 ProxyFactory 类的 getInvoker 方法使用 ref 生成一个AbstractProxyInvoker 实例，到这一步就完成具体服务到 Invoker 的转化。

　　接下来就是 Invoker 转换到 Exporter 的过程。Dubbo 处理服务暴露的关键就在 Invoker 转换到 Exporter 的过程，上图中的红色部分。

　　Dubbo 协议的 Invoker 转为 Exporter 发生在 DubboProtocol 类的 export 方法，它主要是打开创建一个Netty Server 侦听服务，并接收客户端发来的各种请求，通讯细节由 Dubbo 自己实现，然后注册服务到服务注册中心

三、dubbo消费原理

　　首先 ReferenceConfig 类的 init 方法调用 Protocol 的 refer 方法生成 Invoker 实例(如上图中的红色部分)，这是服务消费的关键。接下来把Invoker 转换为客户端需要的接口。

　　dubbo协议的invoker转换为客户端需要的接口是发生在DubboProtocol的refer方法，他主要是创建一个netty client 链接服务提供者，通讯细节由 Dubbo 自己实现。

四、dubbo原理总结

节点角色说明：

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

调用关系说明：

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

registry(configServer)

　　注册中心，和每个Server/Client之间会作一个实时的心跳检测（因为它们都是建立的Socket长连接），比如几秒钟检测一次。收集每个Server提供的服务的信息，每个Client的信息，整理出一个服务列表

　　当某个Server不可用，那么就更新受影响的服务对应的serverAddressList，即把这个Server从serverAddressList中踢出去（从地址列表中删除），同时将推送serverAddressList给这些受影响的服务的clientAddressList里面的所有Client

　　新加一个Server时，由于它会主动与ConfigServer取得联系，而ConfigServer又会将这个信息主动发送给Client，所以新加一个Server时，只需要启动Server，然后几秒钟内，Client就会使用上它提供的服务

consumer(client)

　　调用服务的机器，每个Client启动时，主动与ConfigServer建立Socket长连接，并将自己的IP等相应信息发送给ConfigServer。
　　Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息（这样ConfigServer就知道某个服务是当前哪几个Client在使用），Client拿到这些服务提供者信息后，与它们都建立连接，后面就可以直接调用服务了，当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询，随机，按权重等。
　　一旦Client使用的服务它对应的服务提供者有变化（服务提供者有新增，删除的情况），ConfigServer就会把最新的服务提供者列表推送给Client，Client就会依据最新的服务提供者列表重新建立连接，新增的提供者建立连接，删除的提供者丢弃连接

provider(server)

　　真正提供服务的机器，每个Server启动时，主动与ConfigServer建立Scoket长连接，并将自己的IP，提供的服务名称，端口等信息直接发送给ConfigServer，ConfigServer就会收集到每个Server提供的服务的信息。

优点：

• 只要在Client和Server启动的时候，ConfigServer是好的，服务就可调用了，如果后面ConfigServer挂了，那只影响ConfigServer挂了以后服务提供者有变化，而Client还无法感知这一变化。
• Client每次调用服务是不经过ConfigServer的，Client只是与它建立联系，从它那里获取提供服务者列表而已
• 调用服务-负载均衡：Client调用服务时，可以根据规则在多个服务提供者之间轮流调用服务。
• 服务提供者-容灾：某一个Server挂了，Client依然是可以正确的调用服务的，当前提是这个服务有至少2个服务提供者，Client能很快的感知到服务提供者的变化，并作出相应反应。
• 服务提供者-扩展：添加一个服务提供者很容易，而且Client会很快的感知到它的存在并使用它。