dubbo相关总结

1. Dubbo是什么？

 互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，Dubbo是一个分布式服务框架，在这种情况下诞生的。现在核心业务抽取出来，作为独立的服务，使前端应用能更快速和稳定的响应。

介绍Dubbo背景

    

大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。

(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。

并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。

(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。

(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。

其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
其核心部分包含:
1. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
2. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
3. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

2. Dubbo能做什么？

1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。      
2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

之前使用Web Service，我想测试接口可以通过模拟消息的方式通过soapui或LR进行功能测试或性能测试。但现在使用Dubbo，接口之间不能直接交互，我尝试通过模拟消费者地址测试，结果不堪入目，再而使用jmeter通过junit进行测试，但还是需要往dubbo上去注册，如果再不给提供源代码的前提下，这个测试用例不好写啊....

 

3. dubbo的架构

dubbo 架构图如下所示：

 

 

 1）  节点角色说明：

       Provider: 暴露服务的服务提供方。

       Consumer: 调用远程服务的服务消费方。

       Registry: 服务注册与发现的注册中心。推荐使用Zookeeper注册中心

       Monitor: 统计服务的调用次调和调用时间的监控中心。

       Container: 服务运行容器。

这点我觉得非常好，角色分明，可以根据每个节点角色的状态来确定该服务是否正常。

  2） 调用关系说明：

   0. 服务容器负责启动，加载，运行服务提供者。

1. 服务提供者在启动时，向注册中心注册自己提供的服务。

2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

dubbo的容错性显而易见，性能方面还没有还得及测，我们系统某页面需要掉5次接口，本来想建议做个缓存，但业务关系不能采纳，还需要研究下dubbo的性能调优问题...

  3） 连通性：

• 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
• 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
• 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
• 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
• 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
• 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
• 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
• 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

   4）健状性：

• 监控中心宕掉不影响使用，只是丢失部分采样数据
• 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
• 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
• 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
• 服务提供者无状态，任意一台宕掉后，不影响使用
• 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

   5）伸缩性：

• 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
• 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者

6）Dubbo集群容错和负载均衡
1、集群容错 
在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试。
   
   
Failover Cluster 
失败自动切换，当出现失败，重试其它服务器。(缺省) 
通常用于读操作，但重试会带来更长延迟。 
可通过retries=“2”来设置重试次数(不含第一次)。
Failfast Cluster 
快速失败，只发起一次调用，失败立即报错。 
通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster 
失败安全，出现异常时，直接忽略。 
通常用于写入审计日志等操作。
Failback Cluster 
失败自动恢复，后台记录失败请求，定时重发。 
通常用于消息通知操作。
Forking Cluster 
并行调用多个服务器，只要一个成功即返回。 
通常用于实时性要求较高的读操作，但需要浪费更多服务资源。 
可通过forks=“2”来设置最大并行数。
Broadcast Cluster 
广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持) 
通常用于通知所有提供者更新缓存或日志等本地资源信息。
2、负载均衡 
         Random LoadBalance随机，按权重设置随机概率。 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较匀                          有利于动态调整提供者权重。
   
   
RoundRobin LoadBalance 轮循，按公约后的权重设置轮循比率。 
存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。 
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance 一致性Hash，相同参数的请求总是发到同一提供者。 
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。





7）Dubbo缺省协议采用单一长连接和NIO异步通讯，
适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
分析源代码，基本原理如下：
   
   
client一个线程调用远程接口，生成一个唯一的ID（比如一段随机字符串，UUID等），Dubbo是使用AtomicLong从0开始累计数字的
将打包的方法调用信息（如调用的接口名称，方法名称，参数值列表等），和处理结果的回调对象callback，全部封装在一起，组成一个对象object
向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object)
将ID和打包的方法调用信息封装成一对象connRequest，使用IoSession.write(connRequest)异步发送出去
当前线程再使用callback的get()方法试图获取远程返回的结果，在get()内部，则使用synchronized获取回调对象callback的锁， 再先检测是否已经获取到结果，如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态。
服务端接收到请求并处理后，将结果（此结果中包含了前面的ID，即回传）发送给客户端，客户端socket连接上专门监听消息的线程收到消息，分析结果，取到ID，再从前面的ConcurrentHashMap里面get(ID)，从而找到callback，将方法调用结果设置到callback对象里。
监听线程接着使用synchronized获取回调对象callback的锁（因为前面调用过wait()，那个线程已释放callback的锁了），再notifyAll()，唤醒前面处于等待状态的线程继续执行（callback的get()方法继续执行就能拿到调用结果了），至此，整个过程结束。
   
   

    
    
    
    
8)dubbo底层实现
    
    
（1）协议支持
    
    
Dubbo支持多种协议，如下所示：
Dubbo协议 Hessian协议
HTTP协议 RMI协议
WebService协议
Thrift协议 Memcached协议 Redis协议
在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议。
    
    
（2）默认使用Dubbo协议
    
    
连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要使用dubbo协议传输大文件或超大字符串
使用场景：常规远程服务方法调用
从上面的适用范围总结，dubbo适合小数据量大并发的服务调用，以及消费者机器远大于生产者机器数的情况，不适合传输大数据量的服务比如文件、视频等，除非请求量很低。
    
    

   
   
   
   

    
    9）服务暴露和消费的详细过程
   
   
   
   

    
    
    
    


    
    

    
    
服务提供者暴露一个服务的详细过程
    
    


 
    
    
 上图是服务提供者暴露服务的主过程：
    
    
首先ServiceConfig类拿到对外提供服务的实际类ref(如：HelloWorldImpl),然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例，到这一步就完成具体服务到Invoker的转化。接下来就是Invoker转换到Exporter的过程。
    
    
Dubbo处理服务暴露的关键就在Invoker转换到Exporter的过程(如上图中的红色部分)，下面我们以Dubbo和RMI这两种典型协议的实现来进行说明：
    
    
 
    
    
＃Dubbo的实现
    
    
Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法，它主要是打开socket侦听服务，并接收客户端发来的各种请求，通讯细节由Dubbo自己实现。
    
    
 
    
    
＃RMI的实现
    
    
RMI协议的Invoker转为Exporter发生在RmiProtocol类的export方法，它通过Spring或Dubbo或JDK来实现RMI服务，通讯细节这一块由JDK底层来实现，这就省了不少工作量。
    
    
 
    
    
3. 服务消费者消费一个服务的详细过程
    
    


 
    
    
 
    
    
上图是服务消费的主过程：
    
    
首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例(如上图中的红色部分)，这是服务消费的关键。接下来把Invoker转换为客户端需要的接口(如：HelloWorld)。
    
    
关于每种协议如RMI/Dubbo/Web service等它们在调用refer方法生成Invoker实例的细节和上一章节所描述的类似。
    
    
 
    
    
4. 满眼都是Invoker
    
    
 
    
    
由于Invoker是Dubbo领域模型中非常重要的一个概念，很多设计思路都是向它靠拢。这就使得Invoker渗透在整个实现代码里，对于刚开始接触Dubbo的人，确实容易给搞混了。
    
    
     下面我们用一个精简的图来说明最重要的两种Invoker：服务提供Invoker和服务消费Invoker：
    
    
 
    
    


 

   
   

长连接与短连接

        所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持。 
        短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接，一般银行都使用短连接。  
        比如http的，只是连接、请求、关闭，过程时间较短,服务器若是一段时间内没有收到请求即可关闭连接。 
        其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。

        长连接与短连接的操作过程: 

        通常的短连接操作步骤是： 
        连接→数据传输→关闭连接；

        而长连接通常就是： 
        连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接； 

        这就要求长连接在没有数据通信时，定时发送数据包(心跳)，以维持连接状态，短连接在没有数据传输时直接关闭就行了.

        

        什么时候用长连接，短连接

        长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
 
        发送接收方式
        1、异步 
        报文发送和接收是分开的，相互独立的，互不影响。这种方式又分两种情况： 
        (1)异步双工：接收和发送在同一个程序中，由两个不同的子进程分别负责发送和接收 
        (2)异步单工：接收和发送是用两个不同的程序来完成。 
        2、同步 
        报文发送和接收是同步进行，既报文发送后等待接收返回报文。 同步方式一般需要考虑超时问题，即报文发出去后不能无限等待，需要设定超时时间，超过该时间发送方不再等待读返回报文，直接通知超时返回。
 
        在长连接中一般是没有条件能够判断读写什么时候结束，所以必须要加长度报文头。读函数先是读取报文头的长度，再根据这个长度去读相应长度的报文。 
 
        单工、半双工和全双工

        根据通信双方的分工和信号传输方向可将通信分为三种方式：单工、半双工与全双工。在计算机网络中主要采用双工方式，其中：局域网采用半双工方式，城域网和广域网采用全双年方式。   

        1. 单工(Simplex)方式：通信双方设备中发送器与接收器分工明确，只能在由发送器向接收器的单一固定方向上传送数据。采用单工通信的典型发送设备如早期计算机的读卡器，典型的接收设备如打印机。   

        2. 半双工(Half Duplex)方式：通信双方设备既是发送器，也是接收器，两台设备可以相互传送数据，但某一时刻则只能向一个方向传送数据。例如，步话机是半双工设备，因为在一个时刻只能有一方说话。   

        3. 全双工(Full Duplex)方式：通信双方设备既是发送器，也是接收器，两台设备可以同时在两个方向上传送数据。例如，电话是全双工设备，因为双方可同时说话。

        而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。
 

        所以,长连接和短连接的选择要视情况而定。

        长连接中心跳包及其作用:

         一：内网机器如果不主动向外发起连接，外网机没法直连内网的，这也是内网机安全的原因之一吧，又因为路由器会把这个关系记录下来，但是过一段时间这个记录可能会丢失 ，所有每一个客户端每隔一定时间就会向服务器发送消息，以保证服务器可以随时找到你，这东西被称为心跳包。

         二：理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。

         三：如果不主动关闭socket的话，系统不会自动关闭的，除非当前进程挂掉了，操作系统把占用的socket回收了才会关闭。为什么需要心跳连接主要是判断当前连接是否是有效的、可被使用的。在实际应用中假设一段时间没有数据传输时候理论上说应该连接是没有问题的，但是网络复杂，中途出现问题也是常见的，网线被掐断了、对方进程挂掉了、频繁丢包等，这时候TCP连接是不可使用的，但是对于应用层并不知道，如果需知道网络情况则要很复杂的超时进行了解，TCP从底层就实现了这样的功能。心跳机制是TCP在一段时间间隔后发送确定连接端是否还存在，如果存在的话就会回传一个包确定网络有效，如果心跳包有问题，则通知上层应用当前网络有问题了。
这取决于你的server端的超时配置， 每个socket连接都是长连接，它是一个相当占用系统资源的通信管道， 如果这个长连接什么事也没干硬是要占着资源，则server端可以选择关闭这个连接，以省下资源让更多的用户连接进来。
所以，即便客户端的是采用死循环while(true)方式连到服务端，对于特定的客户端和服务端类型来说也需要一定时间间隔的心跳（告诉服务端，我还活着，虽然我没干活也没说话，但别把我关了）。

IO的两个重要步骤：发起IO请求，和实际的IO操作。在unix网络编程的定义里异步和非异步概念的区别就是实际的IO操作是否阻塞。如果不是就是异步，如果是就是同步。
而阻塞和非阻塞的区别在于发起IO请求的时候是否会阻塞，如果会就是阻塞，不会就是非阻塞。

1,同步和异步是针对应用程序和内核的交互而言的。 

2,阻塞和非阻塞是针对于进程在访问数据的时候，根据IO操作的就绪状态来采取的不同方式，说白了是一种读取或者写入操作函数的实现方式，阻塞方式下读取或者写入函数将一直等待，而非阻塞方式下，读取或者写入函数会立即返回一个状态值。  

由上描述基本可以总结一句简短的话，同步和异步是目的，阻塞和非阻塞是实现方式。

编号	名词	解释	举例
1	同步	指的是用户进程触发IO操作并等待或者轮询的去查看IO操作是否就绪	自己上街买衣服，自己亲自干这件事，别的事干不了。
2	异步	异步是指用户进程触发IO操作以后便开始做自己的事情，而当IO操作已经完成的时候会得到IO完成的通知（异步的特点就是通知）	告诉朋友自己合适衣服的尺寸，大小，颜色，让朋友委托去卖，然后自己可以去干别的事。（使用异步IO时，Java将IO读写委托给OS处理，需要将数据缓冲区地址和大小传给OS）
3	阻塞	所谓阻塞方式的意思是指, 当试图对该文件描述符进行读写时, 如果当时没有东西可读,或者暂时不可写, 程序就进入等待 状态, 直到有东西可读或者可写为止	去公交站充值，发现这个时候，充值员不在（可能上厕所去了），然后我们就在这里等待，一直等到充值员回来为止。（当然现实社会，可不是这样，但是在计算机里确实如此。）
4	非阻塞	非阻塞状态下, 如果没有东西可读, 或者不可写, 读写函数马上返回, 而不会等待，	银行里取款办业务时，领取一张小票，领取完后我们自己可以玩玩手机，或者与别人聊聊天，当轮我们时，银行的喇叭会通知，这时候我们就可以去了。

下面我们再来理解组合方式的IO类型，就好理解多了。 

同步阻塞IO（JAVA BIO）： 
    同步并阻塞，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，当然可以通过线程池机制改善。 

同步非阻塞IO(Java NIO) ： 同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。用户进程也需要时不时的询问IO操作是否就绪，这就要求用户进程不停的去询问。 

异步阻塞IO（Java NIO）：  
   此种方式下是指应用发起一个IO操作以后，不等待内核IO操作的完成，等内核完成IO操作以后会通知应用程序，这其实就是同步和异步最关键的区别，同步必须等待或者主动的去询问IO是否完成，那么为什么说是阻塞的呢？因为此时是通过select系统调用来完成的，而select函数本身的实现方式是阻塞的，而采用select函数有个好处就是它可以同时监听多个文件句柄（如果从UNP的角度看，select属于同步操作。因为select之后，进程还需要读写数据），从而提高系统的并发性！  


（Java AIO(NIO.2)）异步非阻塞IO:  
   在此种模式下，用户进程只需要发起一个IO操作然后立即返回，等IO操作真正的完成以后，应用程序会得到IO操作完成的通知，此时用户进程只需要对数据进行处理就好了，不需要进行实际的IO读写操作，因为真正的IO读取或者写入操作已经由内核完成了。    


BIO、NIO、AIO适用场景分析: 

    BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解。 

    NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持。 

    AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。 
  
  
（其实阻塞与非阻塞都可以理解为同步范畴下才有的概念，对于异步，就不会再去分阻塞非阻塞。对于用户进程，接到异步通知后，就直接操作进程用户态空间里的数据好了。）  
  

   

“一个IO操作其实分成了两个步骤：发起IO请求和实际的IO操作。 
同步IO和异步IO的区别就在于第二个步骤是否阻塞，如果实际的IO读写阻塞请求进程，那么就是同步IO。 
阻塞IO和非阻塞IO的区别在于第一步，发起IO请求是否会被阻塞，如果阻塞直到完成那么就是传统的阻塞IO，如果不阻塞，那么就是非阻塞IO。 

同步和异步是针对应用程序和内核的交互而言的，同步指的是用户进程触发IO操作并等待或者轮询的去查看IO操作是否就绪，而异步是指用户进程触发IO操作以后便开始做自己的事情，而当IO操作已经完成的时候会得到IO完成的通知。而阻塞和非阻塞是针对于进程在访问数据的时候，根据IO操作的就绪状态来采取的不同方式，说白了是一种读取或者写入操作函数的实现方式，阻塞方式下读取或者写入函数将一直等待，而非阻塞方式下，读取或者写入函数会立即返回一个状态值。 
所以,IO操作可以分为3类：同步阻塞（即早期的IO操作）、同步非阻塞（NIO）、异步（AIO）。 
同步阻塞： 
在此种方式下，用户进程在发起一个IO操作以后，必须等待IO操作的完成，只有当真正完成了IO操作以后，用户进程才能运行。JAVA传统的IO模型属于此种方式。 
同步非阻塞： 
在此种方式下，用户进程发起一个IO操作以后边可返回做其它事情，但是用户进程需要时不时的询问IO操作是否就绪，这就要求用户进程不停的去询问，从而引入不必要的CPU资源浪费。其中目前JAVA的NIO就属于同步非阻塞IO。 

异步： 

此种方式下是指应用发起一个IO操作以后，不等待内核IO操作的完成，等内核完成IO操作以后会通知应用程序。

 RPC是远程调用过程的简写，是一个协议，处于网络通信协议的第五层：会话层，其下就是TCP/IP协议，在建立在其基础上的通信会话协议。RPC定义了交互的模式，而应用程序使用这些模式，来访问其他服务器的方法，并不需要关系具体的网络上的细节。     

     一、RPC基础知识   

     1.RPC模式

     RPC采用C/S模式，客户端发送请求，服务端响应。

     基于底层的协议，比如TCP/IP模式。

     2.设计目的

     ①通过固定的协议，调用非本机的方法

     ②实现不同程序语言之间的通信

     ③不需要了解底层协议，像本地方法一样调。它完全封装了网络传输，以及其他细节。

     二、RPC过程详解

          

                                                图一   RPC调用过程

     从RPC的角度看，应该有服务的提供方，即生产者；还有服务的调用方，即消费者。

     对消费者来时，在RPC调用过程中，使用第1步、第2步、第3步、第4步是透明的，其他的都是使用RPC框架去封装这些事情。当应用开始调用PRC的方式时，就会去容器中去取Bean对象，所以我们应该首先注册Bean对象到容器中，我们通过Java的动态代理，将代理过程封装到代理对象中，代理对象实现接口，创建实例到容器中。相应的，在调用远程对象的对象方法时，就会调用动态代理中的方法，这就是代理层的作用。

     代理对象在获取到请求方法、接口和参数时，就会用序列化层，将这些信息封装成一个请求报文，再让通信层向服务端传送报文的内容，然后就到了生产者这块。

     相应的服务必须有个监听器，来监听来自其他服务的请求，一般都会用容器做消息的监听，就会调用对应的Bean对象的方法，去处理响应的请求。当然，RPC框架不会让容器中的每一个框架都会被调用，所以只有注册了的Bean才会被RPC的请求调用到。然后，通过请求中的类、方法、参数，反射调用对应的Bean，拿到结果之后，通过序列化层，封装好结果报文，服务端的通信层将报文反馈给调用方，调用方解析到返回值，动态代理类返回结果，调用结束。

     这样，一个完整的RPC调用反馈链条就完成了。

     1.消费者设计

               

                                               图二  消费者设计

     ①代理层：

     消费者将对应的接口，通过RPC框架的代理来生成一个对象到Spring容器中。代理层将代理接口生成该接口的对象，该对象处理调用时传过来的对象、方法、参数，通过序列化层封装好，调用网络层。

     ②序列化层：

     将请求的参数序列化成报文；将返回的报文反序列化成对象；

     ③网络层：

     将报文与服务端通信；接收返回结果。

     2.生产者设计

            

                                              图三  生产者设计 

     ①代理层：

     一个应用提供服务，必须由一个网络监听的模块，这个模块大多有开源的容器来处理网络上的监听；服务需要注册，只有注册了的服务才可以被调用；注册的服务需要被我们发射调用到，来进行相应的处理。

     ②序列化层：

     就是相应的做请求的反序列化和结果的序列化。

     ③网络层：

     接收客户端报文；将序列化的结果返回给客户端。

     三、RPC模式总结

                     

                                                 图三  RPC模式总结

     1.Proxy代理层

     用于对象的代理；对象的反射调用；RPC流程的控制。

     2.Serialize序列化层

     将请求序列化和结果反序列化。

     3.Invoke网络模块

     主要用于网络通信的相关处理。

     4.Container容器组件

     这层主要用于代理层监听网络请求。