RPC原理
一次完整的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）服务消费方得到最终结果。
RPC框架的目标就是要2~8这些步骤都封装起来，这些细节对用户来说是透明的，不可见的。
netty通信原理
Netty是一个异步事件驱动的网络应用程序框架， 用于快速开发可维护的高性能协议服务器和客户端。它极大地简化并简化了TCP和UDP套接字服务器等网络编程。
BIO：(Blocking IO)
NIO (Non-Blocking IO)
Selector 一般称 为选择器 ，也可以翻译为 多路复用器，
Connect（连接就绪）、Accept（接受就绪）、Read（读就绪）、Write（写就绪）
Netty基本原理
dubbo原理
dubbo原理-----框架设计
图例说明
- 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
- 图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
- 图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
- 图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。
各层说明
- config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 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
- exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
- transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
- serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool
dubbo原理-----启动解析、加载配置信息
启动过程
1、标签入口 ---- DubboNamespaceHandler
2、下面每个配置标签 ---- 对应一个ReferenceBean实例
2.1、把dubbo：referencce （dubbo：service同理）标签配置的属性，全读出来 ---- set进入ReferenceBean对象，对象实例由IOC容器管理
2.2、ReferenceBean（ServiceBean同理）实现了，initializingBean接口，因此初始化完成时，会调用其afterPropertiesSet方法
2.3、afterPropertiesSet方法内，进行dubbo服务配置（创建消费端的代理对象/服务端的中转对象/向zk注册信息/订阅信息等）
这里会对标签中设置的每个协议，进行一行处理
2.4、协议创建中转对象和消费代理
2.5、dubbo的初始化结构图：主线是ServiceBean和ReferenceBean的初始化
dubbo原理-----服务暴露
dubbo原理-----服务引用
dubbo原理-----服务调用
Dubbo的spi机制
概念
本质是解决同一个接口，有多种实现时，使用者如何能够方便选择实现的问题。
同一个接口，多个实现（类似设计模式--策略模式）
jdk中spi使用
jdk中，选择SpiService的实现，方法是在jar中放置一个META-INF/services目录，目录中存放一个文本文件（文件名----是SpiService接口的全路径名），文本中列入你选择的实现类（一行放一个------是实现类的全路径名）
有了上述配置，在java程序中，使用ServiceLoader.load(SpiService.class)，即可将配置中选择的实现类，实例化并放入一个集合中，供我们使用，如下图：
dubbo中spi
与jdk相比，dubbo将选择权下放到了配置文件中（你配置谁，它使为你实例化谁）。
dubbo的目标，以上图cluster为例，failsafe/failover/failfast都是cluster的一种实现，现在我们可以在标签配置时，方便地进行选择
使用流程
凡是dubbo中， 接口上有 @SPI标注的，都表明此接口支持扩展，如下图
单独建立jar工程，引入dubbo依赖（注意依赖scope设为provided）
在工程中，为要扩展的接口，编写实现类
在资源文件中，为每个实现类，定义分配一个key
在消费端，便可使用上面步骤中定的实现策略（以key指代）
原理
dubbo的Spi实现原理---解读其核心ExtensionLoader
疑问：dubbo中reference 使用的protocol --- 是静态类变量，而ReferenceConfig（ReferenceBean的父级）是每个标签一个实例对象（每个对象配置的protocol是不同的）
此时protocol的对应一定出问题
结论：上面步骤中，得到的protocol是个代理类，不是真实的协议实现
ExtensionLoader的加载步骤
- getExtensionLoader(Protocol.class)为protocol接口生成一个加载器
- getAdaptiveExtension()，使用加载器生成一个代理对象---- protocol接口对象
代理对象执行时，根据参数（扩展名extName）选择实际对象
最后的效果：每个接口扩展点----- 对应一个ExtensionLoader加载器，如：
protocol -------------- ExtensionLoader实例< protocol>
filter -------------- ExtensionLoader实例< filter >
loadbalance -------------- ExtensionLoader实例< loadbalance >
代理类的逻辑
代理类的创建，是通过动态代码，生成一个类源码，然后经过编译得到代理类的class，如上图
代理类生成源码的逻辑，只生接口中，标注了@Adaptive的方法，如下：
dubbo的spi整体执行逻辑
a、dubbo启动加载实现类时，以 key-实例 方式map缓存各个实现类
b、实际调用时，通过key --取实现需要那个实现
c、调用的发生，由生成的代理对象的来发起，最终是从URL总线中，找出extName值，
extName做为别说，在缓存map中取出正确的实现实现类