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异步通讯，

  适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
  

  分析源代码，基本原理如下：

  1. client一个线程调用远程接口，生成一个唯一的ID（比如一段随机字符串，UUID等），Dubbo是使用AtomicLong从0开始累计数字的
  2. 将打包的方法调用信息（如调用的接口名称，方法名称，参数值列表等），和处理结果的回调对象callback，全部封装在一起，组成一个对象object
  3. 向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object)
  4. 将ID和打包的方法调用信息封装成一对象connRequest，使用IoSession.write(connRequest)异步发送出去
  5. 当前线程再使用callback的get()方法试图获取远程返回的结果，在get()内部，则使用synchronized获取回调对象callback的锁， 再先检测是否已经获取到结果，如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态。
  6. 服务端接收到请求并处理后，将结果（此结果中包含了前面的ID，即回传）发送给客户端，客户端socket连接上专门监听消息的线程收到消息，分析结果，取到ID，再从前面的ConcurrentHashMap里面get(ID)，从而找到callback，将方法调用结果设置到callback对象里。
  7. 监听线程接着使用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容器组件

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

1、概述

在 Java 世界里，有一种技术可以实现“跨虚拟机”的调用，它就是 RMI（Remote Method Invocation，远程方法调用），通过RMI技术，某一个本地的JVM可以调用存在于另外一个JVM中的对象方法，就好像它仅仅是在调用本地JVM中某个对象方法一样。

RMI中，只要一个类extends了java.rmi.Remote接口，即可成为存在于服务器端的远程对象，供客户端访问并提供一定的服务。同时，远程对象必须实现java.rmi.server.UniCastRemoteObject类，这样才能保证客户端访问获得远程对象时，该远程对象将会把自身的一个拷贝以Socket的形式传输给客户端，此时客户端所获得的这个拷贝称为“存根”，而服务器端本身已存在的远程对象则称之为“骨架”。其实此时的存根是客户端的一个代理，用于与服务器端的通信，而骨架也可认为是服务器端的一个代理，用于接收客户端的请求之后调用远程方法来响应客户端的请求。 

RMI 框架的基本原理大概如下图，应用了代理模式来封装了本地存根与真实的远程对象进行通信的细节。

2，RMI使用场景

RMI是基于JAVA语言的，也就是说在RMI技术框架的描述中，只有Server端使用的是JAVA语言并且Client端也是用的JAVA语言，才能使用RMI技术

RMI适用于两个系统都主要使用JAVA语言进行构造，不需要考虑跨语言支持的情况。并且对两个JAVA系统的通讯速度有要求的情况。

RMI 是一个良好的、特殊的RPC实现：使用JRMP协议承载数据描述，可以使用BIO和NIO两种IO通信模型。RMI框架是可以在大规模集群系统中使用的，当然是不是使用RMI技术，还要看您的产品的技术背景、团队的技术背景、公司的业务背景甚至客户的非技术背景等。在分布式系统中，我们使用 RMI 技术可轻松将 服务提供者（Service Provider）与 服务消费者（Service Consumer）进行分离，充分体现组件之间的弱耦合，系统架构更易于扩展。其实它可以被看作是RPC的Java版本。但是传统RPC并不能很好地应用于分布式对象系统。而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用。RMI目前使用Java远程消息交换协议JRMP（Java Remote Messaging Protocol）进行通信。由于JRMP是专为Java对象制定的，Java RMI具有Java的"Write Once,Run Anywhere"的优点，是分布式应用系统的百分之百纯Java解决方案。用Java RMI开发的应用系统可以部署在任何支持JRE（Java Run Environment Java，运行环境）的平台上。但由于JRMP是专为Java对象制定的，因此，RMI对于用非Java语言开发的应用系统的支持不足。不能与用非Java语言书写的对象进行通信。

3，RMI框架的基本组成

虽然RMI早在JDK.1.1版本中就开放了。但是在JDK1.5的版本中RMI又进行改进。所以我们后续的代码示例和原理讲解都基于最新的RMI框架特性。

要定义和使用一套基于RMI框架工作的系统，您至少需要做一下几个工作：

1、定义RMI Remote接口 
2、实现这个RMI Remote接口 
3、生成Stub（桩）和 Skeleton（骨架）。这一步的具体操作视不同的JDK版本而有所不同（例如JDK1.5后，Skeleton不需要手动)；“RMI注册表”的工作方式也会影响“Stub是否需要命令行生成”这个问题。 
4、向“RMI注册表”注册在第2步我们实现的RMI Remote接口。 
5、创建一个Remote客户端，通过java“命名服务”在“RMI注册表”所在的IP:PORT寻找注册好的RMI服务。 
6、Remote客户端向调用存在于本地JVM中对象那样，调用存在于远程JVM上的RMI接口。

下图描述了上述几个概念名称间的关系，呈现了JDK.5中RMI框架其中一种运行方式（注意，是其中一种工作方式。也就是说RMI框架不一定都是这种运行方式，后文中我们还将描述另外一种RMI的工作方式）：

JDK中的RMI框架在JDK1.1、JDK1.2、JDK1.5、JDK1.6+几个版本中做了较大的调整。以下我们讨论的RMI工作原理都是基于JDK1.6+版本的。

4、JAVA RMI 工作原理

RMI（远程方法调用）原理示意图 

原理示意图 方法调用从客户对象经占位程序（Stub)、远程引用层(Remote Reference Layer)和传输层（Transport Layer）向下，传递给主机，然后再次经传 输层，向上穿过远程调用层和骨干网（Skeleton），到达服务器对象。 占位程序扮演着远程服务器对象的代理的角色，使该对象可被客户激活。 远程引用层处理语义、管理单一或多重对象的通信，决定调用是应发往一个服务器还是多个。传输层管理实际的连接，并且追踪可以接受方法调用的远程对象。服务器端的骨干网完成对服务器对象实际的方法调用，并获取返回值。返回值向下经远程引用层、服务器端的传输层传递回客户端，再向上经传输层和远程调用层返回。最后，占位程序获得返回值。 
要完成以上步骤需要有以下几个步骤： 
1、 生成一个远程接口 
2、 实现远程对象(服务器端程序)
3、 生成占位程序和骨干网(服务器端程序)
4、 编写服务器程序 
5、 编写客户程序 
6、 注册远程对象 
7、 启动远程对象

下面我们来讲解一下RMI的基本原理。本人翻阅网上的众多RMI资料基本上代码都是一大抄（甚至变量名、语法错误都一样），还有很多资料存在误导读者的情况。下图描述了整个RMI框架的几个核心概念：

五、RMI（远程方法调用）的优点 

从最基本的角度看，RMI是Java的远程过程调用(RPC)机制。与传统的RPC系统相比，RMI具有若干优点，因为它是Java面向对象方法的一部分。传统的RPC系统采用中性语言，所以是最普通的系统--它们不能提供所有可能的目标平台所具有的功能。 
RMI以Java为核心，可与采用本机方法与现有系统相连接。这就是说，RMI可采用自然、直接和功能全面的方式为您提供分布式计算技术，而这种技术可帮助您以不断递增和无缝的方式为整个系统添加Java功能。
RMI的主要优点如下： 
面向对象：RMI可将完整的对象作为参数和返回值进行传递，而不仅仅是预定义的数据类型。也就是说，您可以将类似Java哈希表这样的复杂类型作为一个参数进行传递。而在目前的RPC系统中，您只能依靠客户机将此类对象分解成基本数据类型，然后传递这些数据类型，最后在服务器端重新创建哈希表。RMI则不需额外的客户程序代码(将对象分解成基本数据类型)，直接跨网传递对象。 
可移动属性：RMI可将属性(类实现程序)从客户机移动到服务器，或者从服务器移到客户机。这样就能具备最大的灵活性，因为政策改变时只需要您编写一个新的Java类，并将其在服务器主机上安装一次即可。 
设计方式：对象传递功能使您可以在分布式计算中充分利用面向对象技术的强大功能，如二层和三层结构系统。如果您能够传递属性，那么您就可以在您的解决方案中使用面向对象的设计方式。所有面向对象的设计方式无不依靠不同的属性来发挥功能，如果不能传递完整的对象--包括实现和类型--就会失去设计方式上所提供的优点。 
安　　全：RMI使用Java内置的安全机制保证下载执行程序时用户系统的安全。RMI使用专门为保护系统免遭恶意小应用程序侵害而设计的安全管理程序，可保护您的系统和网络免遭潜在的恶意下载程序的破坏。在情况严重时，服务器可拒绝下载任何执行程序。 
便于编写和使用：RMI使得Java远程服务程序和访问这些服务程序的Java客户程序的编写工作变得轻松、简单。远程接口实际上就是Java接口。服务程序大约用三行指令宣布本身是服务程序，其它方面则与任何其它Java对象类似。这种简单方法便于快速编写完整的分布式对象系统的服务程序，并快速地制做软件的原型和早期版本，以便于进行测试和评估。因为RMI程序编写简单，所以维护也简单。 
可连接现有/原有的系统：RMI可通过Java的本机方法接口JNI与现有系统进行进行交互。利用RMI和JNI，您就能用Java语言编写客户端程序，还能使用现有的服务器端程序。在使用RMI/JNI与现有服务器连接时，您可以有选择地用Java重新编写服务程序的任何部分，并使新的程序充分发挥Java的功能。类似地，RMI可利用JDBC、在不修改使用数据库的现有非Java源代码的前提下与现有关系数据库进行交互。 
编写一次，到处运行：RMI是Java“编写一次，到处运行 ”方法的一部分。任何基于RMI的系统均可100%地移植到任何Java虚拟机上，RMI/JDBC系统也不例外。如果使用RMI/JNI与现有系统进行交互工作,则采用JNI编写的代码可与任何Java虚拟机进行编译、运行。 
分布式垃圾收集：RMI采用其分布式垃圾收集功能收集不再被网络中任何客户程序所引用的远程服务对象。与Java 虚拟机内部的垃圾收集类似，分布式垃圾收集功能允许用户根据自己的需要定义服务器对象，并且明确这些对象在不再被客户机引用时会被删除。 
并行计算：RMI采用多线程处理方法，可使您的服务器利用这些Java线程更好地并行处理客户端的请求。Java分布式计算解决方案：RMI从JDK 1.1开始就是Java平台的核心部分，因此，它存在于任何一台1.1 Java虚拟机中。所有RMI系统均采用相同的公开协议，所以，所有Java 系统均可直接相互对话，而不必事先对协议进行转换。

1、RPC概述

 （1）什么是RPC

RPC（Remote Procedure Call Protocol）远程过程调用协议。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。比较正式的描述是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。那么我们至少从这样的描述中挖掘出几个要点：

• RPC是协议：既然是协议就只是一套规范，那么就需要有人遵循这套规范来进行实现。目前典型的RPC实现包括：Dubbo、Thrift、GRPC、Hetty等。这里要说明一下，目前技术的发展趋势来看，实现了RPC协议的应用工具往往都会附加其他重要功能，例如Dubbo还包括了服务管理、访问权限管理等功能。

• 网络协议和网络IO模型对其透明：既然RPC的客户端认为自己是在调用本地对象。那么传输层使用的是TCP/UDP还是HTTP协议，又或者是一些其他的网络协议它就不需要关心了。既然网络协议对其透明，那么调用过程中，使用的是哪一种网络IO模型调用者也不需要关心。

• 信息格式对其透明：我们知道在本地应用程序中，对于某个对象的调用需要传递一些参数，并且会返回一个调用结果。至于被调用的对象内部是如何使用这些参数，并计算出处理结果的，调用方是不需要关心的。那么对于远程调用来说，这些参数会以某种信息格式传递给网络上的另外一台计算机，这个信息格式是怎样构成的，调用方是不需要关心的。

• 应该有跨语言能力：为什么这样说呢？因为调用方实际上也不清楚远程服务器的应用程序是使用什么语言运行的。那么对于调用方来说，无论服务器方使用的是什么语言，本次调用都应该成功，并且返回值也应该按照调用方程序语言所能理解的形式进行描述。

那么上面的描述情况可以用下图表示：

（2）RPC要素

当然，上图是作为RPC的调用者所观察到的现象（而实际情况是客户端或多或少的还是需要知道一些调用RPC的细节）。但是我们是要讲解RPC的基本概念，所以RPC协议内部是怎么回事就要说清楚：

• Client：RPC协议的调用方。就像上文所描述的那样，最理想的情况是RPC Client在完全不知道有RPC框架存在的情况下发起对远程服务的调用。但实际情况来说Client或多或少的都需要指定RPC框架的一些细节。

• Server：在RPC规范中，这个Server并不是提供RPC服务器IP、端口监听的模块。而是远程服务方法的具体实现（在JAVA中就是RPC服务接口的具体实现）。其中的代码是最普通的和业务相关的代码，甚至其接口实现类本身都不知道将被某一个RPC远程客户端调用。

• Stub/Proxy：RPC代理存在于客户端，因为要实现客户端对RPC框架“透明”调用，那么客户端不可能自行去管理消息格式、不可能自己去管理网络传输协议，也不可能自己去判断调用过程是否有异常。这一切工作在客户端都是交给RPC框架中的“代理”层来处理的。

• Message Protocol：在上文我们已经说到，一次完整的client-server的交互肯定是携带某种两端都能识别的，共同约定的消息格式。RPC的消息管理层专门对网络传输所承载的消息信息进行编号和解码操作。目前流行的技术趋势是不同的RPC实现，为了加强自身框架的效率都有一套（或者几套）私有的消息格式。例如前文所讲到的RMI框架使用的消息协议为JRMP；后文我们将详细讲解的RPC框架Thrift也有私有的消息协议，“- Transfer/Network Protocol”（当然它还支持一些通用的消息格式，如JSON）。

• Transfer/Network Protocol：传输协议层负责管理RPC框架所使用的网络协议、网络IO模型。例如Hessian的传输协议基于HTTP（应用层协议）；而Thrift的传输协议基于TCP（传输层协议）。传输层还需要统一RPC客户端和RPC服务端所使用的IO模型；常用的IO模型在之前已经详细讲解过了（可参见我之前的博文《架构设计：系统间通信（3）——IO通信模型和JAVA实践 上篇》）

• Selector/Processor：存在于RPC服务端，由于服务器端某一个RPC接口的实现的特性（它并不知道自己是一个将要被RPC提供给第三方系统调用的服务）。所以在RPC框架中应该有一种“负责执行RPC接口实现”的角色。它负责了包括：管理RPC接口的注册、判断客户端的请求权限、控制接口实现类的执行在内的各种工作。

• IDL：实际上IDL（接口定义语言）并不是RPC实现中所必须的。但是需要跨语言的RPC框架一定会有IDL部分的存在。这是因为要找到一个各种语言能够理解的消息结构、接口定义的描述形式。如果您的RPC实现没有考虑跨语言性，那么IDL部分就不需要包括，例如JAVA RMI因为就是为了在JAVA语言间进行使用，所以JAVA RMI就没有相应的IDL。

• 一定要说明一点，不同的RPC框架实现都有一定设计差异。例如生成Stub的方式不一样，IDL描述语言不一样、服务注册的管理方式不一样、运行服务实现的方式不一样、采用的消息格式封装不一样、采用的网络协议不一样。但是基本的思路都是一样的，上图中的所列出的要素也都是具有的。

（3）典型的RPC框架介绍

• JAVA RMI：是不是觉得前文中我们介绍RMI所提到几个关键概念在RPC中都找得到一些影子。是的，RPC最早就是由SUN提出，并在后来由IETF ONC修订。RMI就是一个典型的RPC实现，只不过RMI不支持跨语言性，所以RMI中也没有IDL存在的必要。但是RMI真心快，并且由于没有IDL的存在，在构建一套完整的RPC实现时要比其他RPC框架少了一些步骤，所以使用起来也比较简单。如果您的业务需求中并不存在跨语言的考虑，并且基本上主要系统都是用JAVA实现，那么RMI绝对是您一个可以考虑的方案。

• GRPC：GRPC是一个高性能、通用的开源RPC框架，由Google主要面向移动应用开发并基于HTTP/2协议（注意是HTTP/2协议，不是我们常使用的HTTP 1_1。HTTP/2协议详细的介绍可以参见官方地址：https://http2.github.io/）标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。为了支持GRPC的跨语言性，GRPC有一套独立存在IDL语言。不过由于GRPC是Google的开源产品，在信息格式封装方面Google主要还是推广的自己的ProtoBuf，所以GPRC是不支持其他信息格式的（至少ProtoBuf效率是大家有目共睹的）。关于GRPC详细的使用介绍，可以参见官方地址：https://github.com/grpc/grpc

• Thrift：Thrift是Facebook的一个开源项目，后来进入Apache进行孵化。Thrift也是支持跨语言的，所以它有自己的一套IDL。目前它支持几乎所有主流的编程语言：C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages。Thrift可以支持多种信息格式，除了Thrift私有的二进制编码规则和一种LVQ（类似于TLV消息格式）的消息格式，还有常规的JSON格式。Thrift的网络协议建立在TCP协议基础上，并且支持阻塞式IO模型和多路IO复用模型。我们将在后文详细讲解Apache Thrift的使用。Thrift也是目前最流行的RPC框架之一，从网络上各种性能测试情况开，Thrift的性能都是领先的。Thrift的官网地址为：http://thrift.apache.org/

• Hetty：Hetty是一款构建于Netty和Hessian基础上的高性能的RPC框架。在前几篇文章中，我已经详细讲述了使用Netty进行网络处理和直接使用JAVA原生的IO模型进行网络处理所带来的好处（请参见我的另一篇博文《http://blog.csdn.net/yinwenjie/article/details/48969853》）。Hetty的网络协议基于HTTP，由于采用了Netty，所以Hetty支持阻塞式IO模型和多路IO复用模型。Hetty的消息格式采用私有的二进制流格式。

• Dubbo：Dubbo是Alibaba开源的分布式服务框架。注意我说的是分布式服务框架，不是RPC框架（用比较严谨的词语概括，应该是“服务治理框架”）。除了集成RPC的规范外，Dubbo还在RPC的上层搭建服务层功能、配置层功能、服务路由功能（加上真正的RPC规范实现总共有10层）。在后文讲解“服务治理”时会重点讲解Dubbo的原理和使用。

• 其他的RPC框架：除了上诉的RPC协议的实现外，还有：Wildfly、Hprose等等。Hprose是一款国人主导的RPC实现，感兴趣的读者可以去看看（http://www.hprose.com/）。另外基于RPC的定义，Xfire，CXF这些Web Service框架也属于RPC：WSDL描述文件就是他们的IDL，通过WSDL为不同的编程语言生成Stub、通过不同的Web服务器管理具体服务实现的运行过程、HTTP是它们的通信协议、XML是它们的消息格式。