迦南地
所有文章 标签 分类 实验室 关于
迦南地

目录

rmi、rpc、netty

 收录于 技术
   约 9343 字   预计阅读 19 分钟    次阅读  

RMI

介绍

远程方法调用（RMI）顾名思义是一台机器上的程序调用另一台机器上的方法。这样可以大致知道RMI是用来干什么的，但是这种理解还不太确切。RMI是Java支撑分布式系统的基石，例如著名的EJB组件。RMI是远程过程调用（RPC）的一种面向对象实现，RMI底层是通过socket通信和对象序列化工作来实现的。

RMI基本原理

RMI的目的就是要使运行在不同的计算机中的对象之间的调用表现得像本地调用一样。RMI应用程序通常包括两个独立的程序:服务器程序和客户机程序。RMI 需要将行为的定义与行为的实现分别定义, 并允许将行为定义代码与行为实现代码存放并运行在不同的 JVM 上。在 RMI 中, 远程服务的定义是存放在继承了 Remote的接口中。远程服务的实现代码存放在实现该定义接口的类中。

RMI 支持两个类实现一个相同的远程服务接口: 一个类实现行为并运行在服务器上, 而另一个类作为一个远程服务的代理运行在客户机上。客户程序发出关于代理对象的调用方法, RMI 将该调用请求发送到远程 JVM 上, 并且进一步发送到实现的方法中。实现方法将结果发送给代理, 再通过代理将结果返回给调用者。

RMI 构建三个抽象层, 高层覆盖低层, 分别负责Socket通信, 参数和结果的序列化和反序列化等工作。存根( Stub) 和骨架( Skeleton) 合在一起形成了 RMI 构架协议。下面的引用层被用来寻找各自的通信伙伴,在这一层还有一个提供名字服务的部分, 称为注册表( registry) 。最下一层是传输层, 是依赖于 TCP/IP 协议实现客户机与服务器的互联。

https://gitee.com/lienhui68/picStore/raw/master/null/20200828031515.png

当客户端调用远程对象方法时, 存根负责把要调用的远程对象方法的方法名及其参数编组打包,并将该包向下经远程引用层、传输层转发给远程对象所在的服务器。通过 RMI 系统的 RMI 注册表实现的简单服务器名字服务, 可定位远程对象所在的服务器。

该包到达服务器后, 向上经远程引用层, 被远程对象的 Skeleton 接收, 此 Skeleton 解析客户包中的方法名及编组的参数后, 在服务器端执行客户要调用的远程对象方法, 然后将该方法的返回值( 或产生的异常) 打包后通过相反路线返回给客户端, 客户端的 Stub 将返回结果解析后传递给客户程序。事实上, 不仅客户端程序可以通过存根调用服务器端的远程对象的方法, 而服务器端的程序亦可通过由客户端传递的远程接口回调客户端的远程对象方法。在分布式系统中, 所有的计算机可以是服务器, 同时又可以是客户机。

https://gitee.com/lienhui68/picStore/raw/master/null/20200828031828.png

RMI示例

Remote接口用于标识其方法可以从非本地虚拟机上调用的接口。任何远程对象都必须直接或间接实现此接口。只有在“远程接口”（扩展 java.rmi.Remote 的接口）中指定的这些方法才可远程使用。 也就是说需要远程调用的方法必须在扩展Remote接口的接口中声名并且要抛出RemoteException异常才能被远程调用。

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

package com.eh.eden.pattern;


import java.rmi.Naming;
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.server.UnicastRemoteObject;

interface IService extends Remote {
    //声明服务器端必须提供的服务
    String service(String content) throws RemoteException;
}

// UnicastRemoteObject用于导出的远程对象和获得与该远程对象通信的存根。
class ServiceImpl extends UnicastRemoteObject implements IService {

    private String name;

    public ServiceImpl(String name) throws RemoteException {
        this.name = name;
    }

    public String service(String content) {
        return "server >> " + content;
    }
}

class Server {
    public static void main(String[] args) {
        try {
            // 实例化实现了IService接口的远程服务ServiceImpl对象
            IService service02 = new ServiceImpl("service02");

            // 本地主机上的远程对象注册表Registry的实例，并指定端口为8888，这一步必不可少（Java默认端口是1099），必不可缺的一步，缺少注册表创建，则无法绑定对象到远程注册表上
            LocateRegistry.createRegistry(8888);

            // 把远程对象注册到RMI注册服务器上，并命名为service02
            //绑定的URL标准格式为：rmi://host:port/name(其中协议名可以省略，下面两种写法都是正确的）
            Naming.bind("rmi://localhost:8888/service02", service02);
        } catch (Exception e) {
            e.printStackTrace();
        }
        System.out.println("服务器向命名表注册了1个远程服务对象！");
    }
}

class Client {
    public static void main(String[] args) {
        String url = "rmi://localhost:8888/";
        try {
            // 在RMI服务注册表中查找名称为service02的对象，并调用其上的方法
            IService service02 = (IService) Naming.lookup(url + "service02");

            Class stubClass = service02.getClass();
            System.out.println(service02 + " 是 " + stubClass.getName() + " 的实例！");
            // 获得本底存根已实现的接口类型
            Class[] interfaces = stubClass.getInterfaces();
            for (Class c : interfaces) {
                System.out.println("存根类实现了 " + c.getName() + " 接口！");
            }
            System.out.println(service02.service("你好！"));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
// 运行结果
Proxy[IService,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:[127.0.0.1:50667](remote),objID:[2d2c01c3:17431676983:-7fff, -151566034752698272]]]]] 是 com.eh.eden.pattern.$Proxy0 的实例！
存根类实现了 java.rmi.Remote 接口！
存根类实现了 com.eh.eden.pattern.IService 接口！
server >> 你好！

时序图

https://gitee.com/lienhui68/picStore/raw/master/null/20200828033223.png

RPC

rpc是远端过程调用，其调用协议通常包含传输协议和序列化协议。

传输协议包含: 如著名的 gRPC 使用的 http2 协议，也有如dubbo一类的自定义报文的tcp协议。

序列化协议包含: 如基于文本编码的 xml json，也有二进制编码的 protobuf hessian等。

为什么要使用自定义 tcp 协议的 rpc 做后端进程通信?

要解决这个问题就应该搞清楚 http 使用的 tcp 协议，和我们自定义的 tcp 协议在报文上的区别。

首先要否认一点 http 协议相较于自定义tcp报文协议 增加的开销在于连接的建立与断开。http协议是支持连接池复用的，也就是建立一定数量的连接不断开，并不会频繁的创建和销毁连接。二要说的是http也可以使用protobuf这种二进制编码协议对内容进行编码，因此二者最大的区别还是在传输协议上。

通用定义的http1.1协议的tcp报文包含太多废信息，一个POST协议的格式大致如下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>

即使编码协议也就是body是使用二进制编码协议，报文元数据也就是header头的键值对却用了文本编码，非常占字节数。如上图所使用的报文中有效字节数仅仅占约 30%，也就是70%的时间用于传输元数据废编码。当然实际情况下报文内容可能会比这个长，但是报头所占的比例也是非常可观的。

那么假如我们使用自定义tcp协议的报文如下

https://gitee.com/lienhui68/picStore/raw/master/null/20200828034027.png

报头占用的字节数也就只有16个byte，极大地精简了传输内容。

这也就是为什么后端进程间通常会采用自定义tcp协议的rpc来进行通信的原因。

所谓的效率优势是针对http1.1协议来讲的，http2.0协议已经优化编码效率问题，像grpc这种rpc库使用的就是http2.0协议。这么来说吧http容器的性能测试单位通常是kqps，自定义tpc协议则通常是以10kqps到100kqps为基准

简单来说成熟的rpc库相对http容器，更多的是封装了“服务发现”，“负载均衡”，“熔断降级”一类面向服务的高级特性。可以这么理解，rpc框架是面向服务的更高级的封装。如果把一个http servlet容器上封装一层服务发现和函数代理调用，那它就已经可以做一个rpc框架了。

所以为什么要用rpc调用？

因为良好的rpc调用是面向服务的封装，针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。

RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API。

公司的系统都由成千上万大大小小的服务组成，各服务部署在不同的机器上，由不同的团队负责。这时就会遇到两个问题：1）要搭建一个新服务，免不了需要依赖他人的服务，而现在他人的服务都在远端，怎么调用？2）其它团队要使用我们的新服务，我们的服务该怎么发布以便他人调用？下文将对这两个问题展开探讨。

如何调用他人的远程服务

由于各服务部署在不同机器，服务间的调用免不了网络通信过程，服务消费方每调用一个服务都要写一坨网络通信相关的代码，不仅复杂而且极易出错。

　　如果有一种方式能让我们像调用本地服务一样调用远程服务，而让调用者对网络通信这些细节透明，那么将大大提高生产力，比如服务消费方在执行helloWorldService.sayHello(“test”)时，实质上调用的是远端的服务。这种方式其实就是RPC（Remote Procedure Call Protocol），在各大互联网公司中被广泛使用，如阿里巴巴的hsf、dubbo（开源）、Facebook的thrift（开源）、Google grpc（开源）、Twitter的finagle（开源）等。

　　要让网络通信细节对使用者透明，我们需要对通信细节进行封装，我们先看下一个RPC调用的流程涉及到哪些通信细节：

https://gitee.com/lienhui68/picStore/raw/master/null/20200902004924.png

  1. 服务消费方（client）调用以本地调用方式调用服务；
  2. client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
  3. client stub找到服务地址，并将消息发送到服务端；
  4. server stub收到消息后进行解码；
  5. server stub根据解码结果调用本地的服务；
  6. 本地服务执行并将结果返回给server stub；
  7. server stub将返回结果打包成消息并发送至消费方；
  8. client stub接收到消息，并进行解码；
  9. 服务消费方得到最终结果。

Stub可以理解为存根

客户端存根：存放服务端的地址信息，再将客户端的请求参数按照应用层自定义协议打包成网络消息，然后通过网络远程发送给服务方。

服务端存根：接收客户端发送过来的消息，将消息应用层自定义协议解包，并调用本地的方法。

RPC的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。

怎么做到透明化远程服务调用

怎么封装通信细节才能让用户像以本地调用方式调用远程服务呢？对java来说就是使用代理！java代理有两种方式：1） jdk 动态代理；2）字节码生成。尽管字节码生成方式实现的代理更为强大和高效，但代码维护不易，大部分公司实现RPC框架时还是选择动态代理方式。

下面简单介绍下动态代理怎么实现我们的需求。我们需要实现RPCProxyClient代理类，代理类的invoke方法中封装了与远端服务通信的细节，消费方首先从RPCProxyClient获得服务提供方的接口，当执行helloWorldService.sayHello(“test”)方法时就会调用invoke方法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class RPCProxyClient implements java.lang.reflect.InvocationHandler{
    private Object obj;

    public RPCProxyClient(Object obj){
        this.obj=obj;
    }

    /**
     * 得到被代理对象;
     */
    public static Object getProxy(Object obj){
        return java.lang.reflect.Proxy.newProxyInstance(obj.getClass().getClassLoader(),
                obj.getClass().getInterfaces(), new RPCProxyClient(obj));
    }

    /**
     * 调用此方法执行
     */
    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        //结果参数;
        Object result = new Object();
        // ...执行通信相关逻辑
        // ...
        return result;
    }
}

1
2
3
4
5
6

public class Test {
     public static void main(String[] args) {
         HelloWorldService helloWorldService = (HelloWorldService)RPCProxyClient.getProxy(HelloWorldService.class);
         helloWorldService.sayHello("test");
     }
 }

怎么对消息进行编码和解码

  1. 确定消息数据结构

    上节讲了invoke里需要封装通信细节，而通信的第一步就是要确定客户端和服务端相互通信的消息结构。

    客户端的请求消息结构一般需要包括以下内容：

    1. 接口名称

    2. 方法名

    3. 参数类型&参数值

    4. 超时时间

      这里设置的超时时间是供client stub执行wait(timeout)使用的

      注意区分客户端超时和服务端超时

      • 当服务端调用的方法执行时间超过设置的超时时间，方法还是会一直执行，只是执行结束后会拿设置的timeout进行比较，如果超过timeout则会输出警告信息打印到日志里。

      • 如果客户端调用方法返回超时，则会直接报超时。当一个请求发出去，当前的请求线程处于锁等待的阻塞状态，而这个condition的唤醒条件1、超时，2、接收到provider的返回。

      • 不管客户端是否超时，服务端只要被调用了，就会一直执行下去。这个时间是在server stub里打印的。

      • 所以说客户端管理的超时时间是针对服务端响应的时间，而服务端的超时间是用来为分析日志提供一些系统运行的情况，并不影响实际的调用过程

    5. requestID，标识唯一请求id，在下面一节会详细描述requestID的用处。

    同理服务端返回的消息结构一般包括以下内容

    1. 返回值
    2. 状态code
    3. requestId

  2. 序列化

    一旦确定了消息的数据结构后，下一步就是要考虑序列化与反序列化了。

    什么是序列化？序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程。

    什么是反序列化？将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程。

    为什么需要序列化？转换为二进制串后才好进行网络传输嘛！

    为什么需要反序列化？将二进制转换为对象才好进行后续处理！

    现如今序列化的方案越来越多，每种序列化方案都有优点和缺点，它们在设计之初有自己独特的应用场景，那到底选择哪种呢？从RPC的角度上看，主要看三点：

    1. 通用性，比如是否能支持Map等复杂的数据结构；
    2. 性能，包括时间复杂度和空间复杂度，由于RPC框架将会被公司几乎所有服务使用，如果序列化上能节约一点时间，对整个公司的收益都将非常可观，同理如果序列化上能节约一点内存，网络带宽也能省下不少；
    3. 可扩展性，对互联网公司而言，业务变化飞快，如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提供系统的灵活度。

通信

消息数据结构被序列化为二进制串后，下一步就要进行网络通信了。目前有两种常用IO通信模型：1）BIO；2）NIO。一般RPC框架需要支持这两种IO模型

如何实现RPC的IO通信框架呢？1）使用java nio方式自研，这种方式较为复杂，而且很有可能出现隐藏bug，但也见过一些互联网公司使用这种方式；2）基于mina，mina在早几年比较火热，不过这些年版本更新缓慢；3）基于netty，现在很多RPC框架都直接基于netty这一IO通信框架，省力又省心，比如阿里巴巴的HSF、dubbo，Twitter的finagle等。

为什么要有requestID

如果使用netty的话，一般会用channel.writeAndFlush()方法来发送消息二进制串，这个方法调用后对于整个远程调用(从发出请求到接收到结果)来说是一个异步的，即对于当前线程来说，将请求发送出来后，线程就可以往后执行了，至于服务端的结果，是服务端处理完成后，再以消息的形式发送给客户端的。于是这里出现以下两个问题：

  1. 怎么让当前线程“暂停”，等结果回来后，再向后执行？

  2. 单一长连接与多线程并发如何协同工作

    如果有多个线程同时进行远程方法调用，这时建立在client server之间的socket连接上会有很多双方发送的消息传递，前后顺序也可能是随机的，server处理完结果后，将结果消息发送给client，client收到很多消息，怎么知道哪个消息结果是原先哪个线程调用的？

    如下图所示，线程A和线程B同时向client socket发送请求requestA和requestB，socket先后将requestB和requestA发送至server，而server可能将responseA先返回，尽管requestA请求到达时间更晚。我们需要一种机制保证responseA丢给ThreadA，responseB丢给ThreadB。

    https://gitee.com/lienhui68/picStore/raw/master/null/20200902010936.png

如何解决呢？

  1. client线程每次通过socket调用一次远程接口前，生成一个唯一的ID，即requestID（requestID必需保证在一个Socket连接里面是唯一的），一般常常使用AtomicLong从0开始累计数字生成唯一ID；

  2. 将处理结果的回调对象callback，存放到全局ConcurrentHashMap里面put(requestID, callback)；

  3. 线程调用channel.writeAndFlush()发送消息后，紧接着执行callback的get()方法试图获取远程返回的结果。在get()内部，则使用synchronized获取回调对象callback的锁，再先检测是否已经获取到结果，如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态。

    callback对象用于在调用线程和监听服务端消息的线程之间通信，传递返回结果。

  4. 服务端接收到请求并处理后，将response结果（此结果中包含了前面的requestID）发送给客户端，客户端socket连接上专门监听服务端消息的线程收到消息，分析结果，取到requestID，再从前面的ConcurrentHashMap里面get(requestID)，从而找到callback对象，再用synchronized获取callback上的锁，将方法调用结果设置到callback对象里，再调用callback.notifyAll()唤醒前面处于等待状态的线程。

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

    public Object get() {
        synchronized (this) { // 旋锁
            while (!isDone) { // 是否有结果了
                wait(); //没结果是释放锁，让当前线程处于等待状态
            }
        }
    }
       
private void setDone(Response res) {
        this.res = res;
        isDone = true;
        synchronized (this) { //获取锁，因为前面wait()已经释放了callback的锁了
            notifyAll(); // 唤醒处于等待的线程
        }
    }

如何发布自己的服务

如何让别人使用我们的服务呢？有同学说很简单嘛，告诉使用者服务的IP以及端口就可以了啊。确实是这样，这里问题的关键在于是自动告知还是人肉告知。

人肉告知的方式：如果你发现你的服务一台机器不够，要再添加一台，这个时候就要告诉调用者我现在有两个ip了，你们要轮询调用来实现负载均衡；调用者咬咬牙改了，结果某天一台机器挂了，调用者发现服务有一半不可用，他又只能手动修改代码来删除挂掉那台机器的ip。现实生产环境当然不会使用人肉方式。

有没有一种方法能实现自动告知，即机器的增添、剔除对调用方透明，调用者不再需要写死服务提供方地址？当然可以，现如今zookeeper被广泛用于实现服务自动注册与发现功能！

简单来讲，zookeeper可以充当一个服务注册表（Service Registry），让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端口）去访问具体的服务提供者。如下图所示：

https://gitee.com/lienhui68/picStore/raw/master/null/20200902013342.png

zookeeper提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立的是一个 Socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除，比如100.19.20.02这台机器如果宕机了，那么zookeeper上的路径就会只剩/HelloWorldService/1.0.0/100.19.20.01:16888。

服务分组与服务版本

在Dubbo中接口类并不能唯一确定一个服务，在dubbo中接口+服务分组+版本号才能唯一确定一个服务，下面来讲解下服务分组和版本号的使用。

服务分组

当一个接口有多种实现时，可以用 group 区分。

  • 服务提供方：

    https://gitee.com/lienhui68/picStore/raw/master/null/20200902014026.png

    上面配置在服务提供方法提供了com.test.UserServiceBo接口的两套实现，服务分组分别为olddubbo,newdubbo。

  • 服务消费方：

    https://gitee.com/lienhui68/picStore/raw/master/null/20200902014041.png

    上面配置在服务消费方消费com.test.UserServiceBo接口的两套实现，服务分组分别为olddubbo,newdubbo。

需要注意的是消费方只能消费与自己服务分组相同的提供方的服务，这里userServiceOld生成的是服务提供方分组为olddubbo的接口的代理。 userServiceNew生成的是服务提供方分组为newdubbo的接口的代理。

服务版本

当同一个服务分组的接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。 可以按照以下的步骤进行版本迁移：

  1. 在低压力时间段，先升级一半提供者为新版本
  2. 再将所有消费者升级为新版本
  3. 然后将剩下的一半提供者升级为新版本

比如：

  • 服务提供方

    https://gitee.com/lienhui68/picStore/raw/master/null/20200902014210.png

    服务提供方法在分组dubbo下提供了两个版本号的服务

  • 服务消费方

    https://gitee.com/lienhui68/picStore/raw/master/null/20200902014219.png

同理需要注意的是服务消费方只能消费与自己接口+分组+版本一致的服务提供方的服务。

小结

dubbo中唯一确定一个服务的是接口+服务分组+版本号，服务提供方和消费方提供和消费服务时候显示的配置服务分组和版本号是一一对应的。

服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费方服务提供者地址列表已经发生改变，从而进行更新。

更为重要的是zookeeper与生俱来的容错容灾能力（比如leader选举），可以确保服务注册表的高可用性。

rpc服务和http服务的区别

传输协议

  • http服务是基于http协议
  • rpc服务是基于自定义的应用层协议

传输效率

  • RPC，使用自定义的应用层协议，可以让请求报文体积更小，提高传输效率
  • 如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装以下是可以作为一个RPC来使用的

性能消耗

主要在于序列化和反序列化的耗时

  • RPC，可以基于thrift实现高效的二进制传输
  • HTTP，大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能

负载均衡

  • RPC，基本都自带了负载均衡策略
  • HTTP，需要配置Nginx，HAProxy来实现

服务治理

下游服务新增，重启，下线时如何不影响上游调用者

  • RPC，能做到自动通知，不影响上游
  • HTTP，需要事先通知，修改Nginx/HAProxy配置

小结

  • RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。
  • HTTP主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。

关于Netty

Netty框架不局限于RPC，更多的是作为一种网络协议的实现框架，比如HTTP，由于RPC需要高效的网络通信，就可能选择以Netty作为基础。除了网络通信，RPC还需要有比较高效的序列化框架，以及一种寻址方式。如果是带会话（状态）的RPC调用，还需要有会话和状态保持的功能。

大体上来说，Netty就是提供一种事件驱动的，责任链式（也可以说是流水线）的网络协议实现方式。网络协议包含很多层次，很多部分组成，如传输层协议，编码解码，压缩解压，身份认证，加密解密，请求的处理逻辑，怎么能够更好的复用，扩展，业界通用的方法就是责任链。

一个请求应答网络交互通常包含两条链，一条链（Upstream）是从传输层，经过一系列步骤，如身份认证，解密，日志，流控，最后到达业务层，一条链（DownStream）是业务层返回后，又经过一系列步骤，如加密等，又回到传输层。

https://gitee.com/lienhui68/picStore/raw/master/null/20200828035052.png

这样每一层都有一个处理接口，都可以进行不同的操作，比如身份认证，加解密，日志，流控，将不同的处理实现像拼积木那样插接起来就可以实现一个网络协议了（快速开发）。每一层都有自己的实现，上层不需要关注面向网络的操作（可维护）。Netty已经提供了很多实现。

https://gitee.com/lienhui68/picStore/raw/master/null/20200828035120.png

当然Netty还有许多好处，比如对非阻塞IO（NIO）的支持，比如在链上传递时最大程度的减少buffer的copy（高性能）。

参考

RMI(远程方法调用)

既然有 HTTP 请求，为什么还要用 RPC 调用？

更新于 2020-06-04
 java网络编程, rpc, rmi
返回 | 主页