Dubbo基础

1.RPC场景和过程

1.1PRC使用场景
在微服务环境下，存在大量的跨JVM进行方法调用的场景。
分布式服务结构

具体到某个调用来说，希望A机器能通过网络，调用B机器内的某个服务的具体方法，并得到返回值。

1.2RPC的实现切入口
从本质上来讲，某个JVM内的对象方法，是无法在JVM外部被调用的。

1.3网络通信传递反射信息
1.3.1 定义一个继承remote接口的类

1.3.2 RMI开放服务到指定URL
将实例绑定注册到指定的URL和port上，远程即可调用此实例。

1.3.3RMI远程通过url连接并调用

1.4远程调用的融合
前两步已经实现了跨机器的反射信息收发和调用。现在只需要在InfoService的实现上，对传递的isfo信息，直接发起反射调用即可。

远程机器只要通过infoService传递过来的信息，就自动将目标服务器反射调用，并返回结果值回去，整个RPC过程完成。

1.5对客户端友好的透明化封装
虽然整个RPC链条已经拉通，但是客户端封装反射的地方功能不够内聚，容易出现错误，代码可读性也很差。
其实对象/方法/参数 可以做一个静态代理。

像调用本地正常服务就可以。

1.6dubbo使命

服务方是集群时，如何挑选一台机器响应客户端？
网络抖动引起的失败，如何重试弥补？
服务方机器的动态增减，如何能够让客户端及时了解并做调整？
。。。
解决服务节点间的RPC调用错综复杂的问题。

2.Dubbo简介

Dubbo是一个带有服务治理功能的RPC框架,提供了一套较为完整的服务治理方案，底层直接实现RPC调用的全过程。

核心部分:
远程通讯：提供对于多种基于长连接的NIO框架的抽象封装，包括多线程模型，序列化以及"请求-相应"模式的信息交换。
集群容错：提供基于接口的透明远程过程调用，包括多协议支持，负载均衡，失败容错，地址路由，动态配置等集群支持。
自动发现:基于注册中心目录服务，是服务消费方可以动态查找提供方，使地址透明，使服务提供方可平滑增加或减少服务。

2.1架构及特点

服务接口层(service):与实际业务有关，根据服务提供方和消费方的业务设计对应的实现和接口。
配置层（config）:对外配置接口，以serviceConfig和referenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。
服务代理层(Proxy):服务接口透明代理，生成服务的客户端stub和服务器端skeleton，以serviceProxy为中心，扩展接口为proxyFactory。
服务注册层（registry):封装服务地址的注册与发现，以服务url为中心，扩展接口为RegistryFactory，registry和registryService。
集群层(cluster):封装多个提供者的路由及负载均衡，并桥接注册中心，以invoker为中心，扩展接口为cluster，directory，router，和loadbalance。
将多个提供方组合为一个服务方，实现对服务消费方透明，只需要与一个服务提供方交互。
监控层(monitor):RPC调用次数和调用时间监控，以statistics为中心拓展接口为monitorFactory，monitor和monitorService。
远程调用层(protocol):封装RPC调用，以invocation和result为中心，扩展接口protocol，invoker和exporter。protocol是服务域，它是invoker暴露和引用的主功能入口。它负责invoker的生命周期管理，invoker是实体域，它是dubbo的核心模型，其他模型都向他靠优或转换为他，它代表一个可执行实体，可像它发出invoker调用，它有可能是一个本地实现，也有可能是一个远程实现或集群实现。
信息交换层(exchange):封装请求响应模式，同步转异步，以request和response为中心，扩展接口为exchanger，exchangchannel，exchangeClient，exchangService。
网络传输层(transport):抽象mina和netty为统一接口，以message为中心，扩展接口为channel，transporter，client，server和codec。
数据序列化层(serialize):可复用的一些工具，拓展接口为serialization，objectinput，objectoutput，threadpool。

2.2 dubbo角色关系
服务提供方和服务调用方调用的关系：

节点角色说明：
provider：暴露服务的服务提供方。
consumer:调用远程服务的服务消费方。
registry：服务注册与发现的注册中心。
monitor：统计服务调用次数和调用时间的监控中心。
container:服务运行容器。
调用关系说明:
0: 服务容器负责运行加载服务提供者。
1: 服务提供者在启动时，向注册中心注册自己提供的服务。
2: 服务消费者在启动时，向注册中心订阅自己所需服务。
3: 注册中心返回服务提供者地址列表给服务消费者，如果有变更，注册中心会基于长连接推送变更数据给消费者。
4: 消费者从服务提供者地址列表中，基于负载均衡算法，选择一台提供者进行调用，如果调用失败则在选另一台。
5: 服务消费者和提供者在内存中累计调用次数和调用时间定时每分钟发送一次统计数据给监控中心。