关于java:12437字带你深入探究RPC通讯原理

如下是 Http 申请案例：

申请过程会有 3 次握手 4 次挥手：

1: 浏览器申请服务器（订单服务）, 申请建设链接                              1 次握手
2: 服务器 (订单服务) 响应浏览器，能够建设链接，并询问浏览器是否能够建设链接      2 次握手
3: 浏览器响应服务器(订单服务)，能够建设链接                                  3 次握手

------ 开始传输数据 ------

1: 浏览器向服务端 (订单服务) 发动申请，要求断开链接                            1 次挥手
2: 服务器 (订单服务) 回应浏览器, 数据还在传输中                              2 次挥手
3: 服务器 (订单服务) 接管完数据后, 向浏览器发消息要求断开链接                     3 次挥手
4: 浏览器收到服务器音讯后, 回复服务器 (订单服务) 批准断开链接                     4 次挥手

RPC 的次要性能指标是让 构建分布式计算（利用）更容易 ，在提供弱小的近程调用能力时不损失本地调用的语义 简洁性 。为实现该指标，RPC 框架需提供一种 通明调用机制，让使用者不用显式的辨别本地调用和近程调用。

RPC 的长处：

分布式设计
部署灵便
解耦服务
扩展性强

RPC 框架劣势：

RPC 框架个别应用长链接，不用每次通信都要 3 次握手，缩小网络开销。
RPC 框架个别都有 注册核心，有丰盛的监控治理、公布、下线接口、动静扩大等，对调用方来说是无感知、统一化的操作、协定私密，安全性较高
RPC 协定更简略内容更小，效率更高，服务化架构、服务化治理，RPC 框架是一个强力的撑持。
RPC 基于 TCP 实现，也能够基于 Http2 实现

支流 RPC 框架：

Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅反对 Java 语言。
Motan：新浪微博外部应用的 RPC 框架，于 2016 年对外开源，仅反对 Java 语言。
Tars：腾讯外部应用的 RPC 框架，于 2017 年对外开源，仅反对 C++ 语言。
Spring Cloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，提供了丰盛的生态组件。
gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，反对多种语言。
Thrift：最后是由 Facebook 开发的外部零碎跨语言的 RPC 框架，2007 年奉献给了 Apache 基金，成为 Apache 开源我的项目之一，反对多种语言。

利用例举:

分布式操作系统的过程间通信
过程间通信是操作系统必须提供的根本设施之一, 分布式操作系统必须提供散布于异构的结点机上过程间的通信机制，RPC 是实现音讯传送模式的分布式过程间通信形式之一。
结构分布式设计的软件环境
因为分布式软件设计，服务与环境的散布性, 它的各个组成成份之间存在大量的交互和通信, RPC 是其根本的实现办法之一。Dubbo 分布式服务框架基于 RPC 实现，Hadoop 也采纳了 RPC 形式实现客户端与服务端的交互。
近程数据库服务
在分布式数据库系统中，数据库个别驻存在服务器上，客户机通过近程数据库服务性能拜访数据库服务器，现有的近程数据库服务是应用 RPC 模式的。例如，Sybase 和 Oracle 都提供了存储过程机制，零碎与用户定义的存储过程存储在数据库服务器上，用户在客户端应用 RPC 模式调用存储过程。
分布式应用程序设计
RPC 机制与 RPC 工具为分布式应用程序设计提供了伎俩和不便, 用户能够无需晓得网络结构和协定细节而间接应用 RPC 工具设计分布式应用程序。
分布式程序的调试
RPC 可用于分布式程序的调试。应用反向 RPC 使服务器成为客户并向它的客户过程收回 RPC，能够调试分布式程序。例如，在服务器上运行一个远端调试程序，它一直接管客户端的 RPC，当遇到一个调试程序断点时，它向客户机发回一个 RPC，告诉断点曾经达到，这也是 RPC 用于过程通信的例子。

具体调用过程：

服务消费者（client 客户端）通过本地调用的形式调用服务。
客户端存根（client stub）接管到申请后负责将办法、入参等信息序列化（组装）成可能进行网络传输的音讯体。
客户端存根（client stub）找到近程的服务地址，并且将音讯通过网络发送给服务端。
服务端存根（server stub）收到音讯后进行解码（反序列化操作）。
服务端存根（server stub）依据解码后果调用本地的服务进行相干解决。
本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）。
服务端存根（server stub）将返回后果从新打包成音讯（序列化）并通过网络发送至生产方。
客户端存根（client stub）接管到音讯，并进行解码（反序列化）。
服务生产方失去最终后果。

所波及的技术:

动静代理

生成 Client Stub（客户端存根）和 Server Stub（服务端存根）的时候须要用到 java 动静代理技术。
序列化
在网络中，所有的数据都将会被转化为字节进行传送，须要对这些参数进行 序列化和反序列化 操作。

目前支流高效的开源序列化框架有 Kryo、fastjson、Hessian、Protobuf 等。
NIO 通信

Java 提供了 NIO 的解决方案，Java 7 也提供了更优良的 NIO.2 反对。能够采纳 Netty 或者 mina 框架来解决 NIO 数据传输的问题。开源的 RPC 框架 Dubbo 就是采纳 NIO 通信，集成反对 netty、mina、grizzly。
服务注册核心

通过注册核心，让客户端连贯调用服务端所公布的服务。支流的注册核心组件：Redis、Nacos、Zookeeper、Consul、Etcd。Dubbo 采纳的是 ZooKeeper 提供服务注册与发现性能。
负载平衡

在高并发的场景下，须要多个节点或集群来晋升整体吞吐能力。
健康检查

健康检查包含，客户端心跳和服务端被动探测两种形式。

序列化的作用

在网络传输中，数据必须采纳二进制模式，所以在 RPC 调用过程中，须要采纳序列化技术，对入参对象和返回值对象进行序列化与反序列化。
序列化原理

自定义的二进制协定来实现序列化：

一个对象是如何进行序列化? 上面以 User 对象例举解说:

User 对象:
```
package com.itcast;
public class User {

    /**
     * 用户编号
     */
    private String userNo = "0001";

    /**
     * 用户名称
     */
    private String name = "zhangsan";

}
```
包体的数据组成:

业务指令为 0x00000001 占 1 个字节，类的包名 com.itcast 占 10 个字节, 类名 User 占 4 个字节;

属性 UserNo 名称占 6 个字节，属性类型 string 占 2 个字节示意，属性值为 0001 占 4 个字节；

属性 name 名称占 4 个字节，属性类型 string 占 2 个字节示意，属性值为 zhangsan 占 8 个字节；

包体共计占有 1 +10+4+6+2+4+4+2+8 = 41 字节。

包头的数据组成:

版本号 v1.0占 4 个字节，音讯包体理论长度为 41 占 4 个字节示意，序列号 0001 占 4 个字节，校验码 32 位示意占 4 个字节。

包头共计占有 4 +4+4+4 = 16 字节。

包尾的数据组成:

通过回车符标记完结 \r\n，占用 1 个字节。

整个包的序列化二进制字节流共 41+16+1 = 58 字节。这里解说的是整个 序列化的解决思路，在理论的序列化解决中还要思考更多细节，比如说办法和属性的辨别，办法权限的标记，嵌套类型的解决等等。
序列化的解决因素
1. 解析效率：序列化协定应该首要思考的因素，像 xml/json 解析起来比拟耗时，须要解析 dom 树，二进制自定义协定解析起来效率要快很多。
2. 压缩率：同样一个对象，xml/json 传输起来有大量的标签冗余信息，信息有效性低，二进制自定义协定占用的空间相对来说会小很多。
3. 扩展性与兼容性：是否可能利于信息的扩大，并且减少字段后旧版客户端是否须要强制降级，这都是须要思考的问题，在自定义二进制协定时候，要做好充分考虑设计。
4. 可读性与可调试性：xml/json 的可读性会比二进制协定好很多，并且通过网络抓包是能够间接读取，二进制则须要反序列化能力查看其内容。
5. 跨语言：有些序列化协定是与开发语言严密相干的，例如 dubbo 的 Hessian 序列化协定就只能反对 Java 的 RPC 调用。
6. 通用性：xml/json 十分通用，都有很好的第三方解析库，各个语言解析起来都非常不便，二进制数据的解决方面也有 Protobuf 和 Hessian 等插件，在做设计的时候尽量做到较好的通用性。
罕用的序列化技术
1. JDK 原生序列化
  
  代码:
```
...
    public static void main(String[] args) throws IOException, ClassNotFoundException {
        String basePath =  "D:/TestCode";
        FileOutputStream fos = new FileOutputStream(basePath + "tradeUser.clazz");
        TradeUser tradeUser = new TradeUser();
        tradeUser.setName("Mirson");
        ObjectOutputStream oos = new ObjectOutputStream(fos);
        oos.writeObject(tradeUser);
        oos.flush();
        oos.close();
        FileInputStream fis = new FileInputStream(basePath + "tradeUser.clazz");
        ObjectInputStream ois = new ObjectInputStream(fis);
        TradeUser deStudent = (TradeUser) ois.readObject();
        ois.close();
        System.out.println(deStudent);
    }
...
```
  (1) 在 Java 中，序列化必须要实现 java.io.Serializable 接口。
  
  (2) 通过 ObjectOutputStream 和 ObjectInputStream 对象进行序列化及反序列化操作。
  
  (3) 虚拟机是否容许反序列化，不仅取决于类门路和性能代码是否统一，一个十分重要的一点是两个类的序列化 ID 是否统一
  （也就是在代码中定义的序列 ID private static final long serialVersionUID）
  
  (4) 序列化并不会保留动态变量。
  
  (5) 要想将父类对象也序列化，就须要让父类也实现 Serializable 接口。
  
  (6) Transient 关键字的作用是控制变量的序列化，在变量申明前加上该关键字，能够阻止该变量被序列化到文件中，在被反序列化后，transient 变量的值被设为初始值，如根本类型 int 为 0，封装对象型 Integer 则为 null。
  
  (7) 服务器端给客户端发送序列化对象数据并非加密的，如果对象中有一些敏感数据比方明码等，那么在对明码字段序列化之前，最好做加密解决, 这样能够肯定水平保障序列化对象的数据安全。
2. JSON 序列化
  
  个别在 HTTP 协定的 RPC 框架通信中，会抉择 JSON 形式。
  
  劣势：JSON 具备较好的扩展性、可读性和通用性。
  
  缺点：JSON 序列化占用空间开销较大, 没有 JAVA 的强类型辨别，须要通过反射解决，解析效率和压缩率都较差。
  
  如果对并发和性能要求较高，或者是传输数据量较大的场景，不倡议采纳 JSON 序列化形式。
3. Hessian2 序列化
  
  Hessian 是一个动静类型，二进制序列化，并且反对跨语言个性的序列化框架。
  
  Hessian 性能上要比 JDK、JSON 序列化高效很多，并且生成的字节数也更小。有十分好的兼容性和稳定性，所以 Hessian 更加适宜作为 RPC 框架近程通信的序列化协定。
  
  代码示例:
```
...
TradeUser tradeUser = new TradeUser();
tradeUser.setName("Mirson");

//tradeUser 对象序列化解决
ByteArrayOutputStream bos = new ByteArrayOutputStream();
Hessian2Output output = new Hessian2Output(bos);
output.writeObject(tradeUser);
output.flushBuffer();
byte[] data = bos.toByteArray();
bos.close();

//tradeUser 对象反序列化解决
ByteArrayInputStream bis = new ByteArrayInputStream(data);
Hessian2Input input = new Hessian2Input(bis);
TradeUser deTradeUser = (TradeUser) input.readObject();
input.close();

System.out.println(deTradeUser);
...
```
  Dubbo Hessian Lite 序列化流程:
  
  Dubbo Hessian Lite 反序列化流程:
  
  Hessian 本身也存在一些缺点，大家在应用过程中要留神：
  - 对 Linked 系列对象不反对，比方 LinkedHashMap、LinkedHashSet 等，但能够通过 CollectionSerializer 类修复。
  - Locale 类不反对，能够通过扩大 ContextSerializerFactory 类修复。
  - Byte/Short 在反序列化的时候会转成 Integer。

Dubbo2.7.3 通信序列化源码实现剖析：

序列化实现流程：

ExchangeCodec 的 encode 办法：```java
    @Override
    public void encode(Channel channel, ChannelBuffer buffer, Object msg) throws IOException {if (msg instanceof Request) {encodeRequest(channel, buffer, (Request) msg);
        } else if (msg instanceof Response) {encodeResponse(channel, buffer, (Response) msg);
        } else {super.encode(channel, buffer, msg);
        }
    }
```

反序列化实现流程：

源码：ExchangeCodec 的 decode 办法：```java
    @Override
    public Object decode(Channel channel, ChannelBuffer buffer) throws IOException {int readable = buffer.readableBytes();
        byte[] header = new byte[Math.min(readable, HEADER_LENGTH)];
        buffer.readBytes(header);
        return decode(channel, buffer, readable, header);
    }

```

ExchangeCodec 的 decodeBody 办法：```java
protected Object decodeBody(Channel channel, InputStream is, byte[] header) throws IOException {...} else {
            // decode request.
            Request req = new Request(id);
            req.setVersion(Version.getProtocolVersion());
            req.setTwoWay((flag & FLAG_TWOWAY) != 0);
            if ((flag & FLAG_EVENT) != 0) {req.setEvent(true);
            }
            try {ObjectInput in = CodecSupport.deserialize(channel.getUrl(), is,                 proto);   
            }
    ...
}
```

Protobuf 序列化

Protobuf 是 Google 推出的开源序列库，它是一种轻便、高效的结构化数据存储格局，能够用于结构化数据序列化，反对 Java、Python、C++、Go 等多种语言。

Protobuf 应用的时候须要定义 IDL（Interface description language），而后应用不同语言的 IDL 编译器，生成序列化工具类，它具备以下长处：

压缩比高，体积小，序列化后体积相比 JSON、Hessian 小很多；
IDL 能清晰地形容语义，能够帮忙并保障应用程序之间的类型不会失落，无需相似 XML 解析器；
序列化反序列化速度很快，不须要通过反射获取类型；
音讯格局的扩大、降级和兼容性都不错，能够做到向后兼容。

代码示例:

Protobuf 脚本定义:

// 定义 Proto 版本
syntax = "proto3";
// 是否容许生成多个 JAVA 文件
option java_multiple_files = false;
// 生成的包门路
option java_package = "com.itcast.bulls.stock.struct.netty.trade";
// 生成的 JAVA 类名
option java_outer_classname = "TradeUserProto";


// 预警告诉音讯体
message TradeUser {

    /**
     * 用户 ID
     */
    int64 userId = 1 ;
    
    /**
     * 用户名称
     */
    string userName = 2 ;
}

代码操作:

// 创立 TradeUser 的 Protobuf 对象
TradeUserProto.TradeUser.Builder builder = TradeUserProto.TradeUser.newBuilder();
builder.setUserId(101);
builder.setUserName("Mirson");

// 将 TradeUser 做序列化解决
TradeUserProto.TradeUser msg = builder.build();
byte[] data = msg.toByteArray();

// 反序列化解决, 将方才序列化的 byte 数组转化为 TradeUser 对象
TradeUserProto.TradeUser deTradeUser = TradeUserProto.TradeUser.parseFrom(data);
System.out.println(deTradeUser);

外部接口如何调用实现?

RPC 的调用对用户来讲是通明的，那外部是如何实现呢？外部核心技术采纳的就是动静代理，RPC 会主动给接口生成一个代理类，当咱们在我的项目中注入接口的时候，运行过程中理论绑定的是这个接口生成的代理类。在接口办法被调用的时候，它实际上是被生成代理类拦挡到了，这样就能够在生成的代理类外面，退出其余调用解决逻辑，比方连贯负载治理，日志记录等等。

JDK 动静代理：
```
被代理对象必须实现 1 个接口
```

JDK 动静代理的如何实现?

实例代码:

public class JdkProxyTest {

    /**
     * 定义用户的接口
     */
    public interface User {String job();
    }


    /**
     * 理论的调用对象
     */
    public static class Teacher {public String invoke(){return "i'm Teacher";}
    }


    /**
     * 创立 JDK 动静代理类
     */
    public static class JDKProxy implements InvocationHandler {
        private Object target;

        JDKProxy(Object target) {this.target = target;}

        @Override
        public Object invoke(Object proxy, Method method, Object[] paramValues) {return ((Teacher)target).invoke();}
    }


        public static void main(String[] args){
            // 构建代理器
            JDKProxy proxy = new JDKProxy(new Teacher());
            ClassLoader classLoader = ClassLoaderUtils.getClassLoader();

            // 生成代理类
            User user = (User) Proxy.newProxyInstance(classLoader, new Class[]{User.class}, proxy);

            // 接口调用
            System.out.println(user.job());
        }
}

JDK 动静代理的实现原理:

JDK 外部如何解决?

反编译生成的代理类能够晓得，代理类 $Proxy 外面会定义雷同签名的接口 (也就是下面代码 User 的 job 接口)，而后外部会定义一个变量绑定 JDKProxy 代理对象，当调用 User.job 接口办法，本质上调用的是 JDKProxy.invoke() 办法，从而实现了接口的动静代理。

为什么要退出动静代理?

第一, 如果没有动静代理, 服务端大量的接口将不便于管理，须要大量的 if 判断，如果扩大了新的接口，须要更改调用逻辑，不利于扩大保护。

第二, 是能够拦挡，增加其余额定性能，比方连贯负载治理，日志记录等等。
动静代理开源技术

(1) Cglib 动静代理

Cglib 是一个弱小的、高性能的代码生成包，它宽泛被许多 AOP 框架应用，反对办法级别的拦挡。它是高级的字节码生成库，位于 ASM 之上，ASM 是低级的字节码生成工具，ASM 的应用对开发人员要求较高，相比拟来讲, ASM 性能更好。

(2) Javassist 动静代理

一个开源的剖析、编辑和创立 Java 字节码的类库。javassist 是 jboss 的一个子项目，它间接应用 java 编码的模式，不须要理解虚拟机指令，能够动静扭转类的构造，或者动静生成类。Javassist 的定位是可能操纵底层字节码，所以应用起来并不简略，Dubbo 框架的设计者为了谋求性能破费了不少精力去适配 javassist。

(3) Byte Buddy 字节码加强库

Byte Buddy 是致力于解决字节码操作和简化操作复杂性的开源框架。Byte Buddy 指标是将显式的字节码操作暗藏在一个类型平安的畛域特定语言背地。它属于后起之秀，在很多优良的我的项目中，像 Spring、Jackson 都用到了 Byte Buddy 来实现底层代理。相比 Javassist，Byte Buddy 提供了更容易操作的 API，编写的代码可读性更高。

几种动静代理性能比拟：

单位是纳秒。大括号内代表的是样本标准差，综合后果:

Byte Buddy > CGLIB > Javassist> JDK。

源码分析：

外围源码：

服务注册发现的作用

在高可用的生产环境中，个别都以集群形式提供服务，集群外面的 IP 可能随时变动，也可能会随着保护裁减或缩小节点，客户端须要可能及时感知服务端的变动，获取集群最新服务节点的连贯信息。
服务注册发现性能

服务注册：在服务提供方启动的时候，将对外裸露的接口注册到注册核心内，注册核心将这个服务节点的 IP 和接口等连贯信息保留下来。为了检测服务的服务端的无效状态，个别会建设双向心跳机制。

服务订阅：在服务调用方启动的时候，客户端去注册核心查找并订阅服务提供方的 IP，而后缓存到本地，并用于后续的近程调用。如果注册核心信息发生变化，个别会采纳推送的形式做更新。

服务注册发现的具体流程

支流服务注册工具有 Nacos、Consul、Zookeeper 等，

基于 ZooKeeper 的服务发现：

ZooKeeper 集群作为注册核心集群，服务注册的时候只须要服务节点向 ZooKeeper 节点写入注册信息即可，利用 ZooKeeper 的 Watcher 机制实现服务订阅与服务下发性能。

A. 先在 ZooKeeper 中创立一个服务根门路，能够依据接口名命名（例如：/dubbo/com.itcast.xxService），在这个门路再创立服务提供方与调用方目录（providers、consumers），别离用来存储服务提供方和调用方的节点信息。

B. 服务端发动注册时，会在服务提供方目录中创立一个长期节点，节点中存储注册信息，比方 IP，端口，服务名称等等。

C. 客户端发动订阅时，会在服务调用方目录中创立一个长期节点，节点中存储调用方的信息，同时 watch 服务提供方的目录（/dubbo/com.itcast.xxService/providers）中所有的服务节点数据。当服务端产生变动时，比方下线或宕机等，ZooKeeper 就会告诉给订阅的客户端。

ZooKeeper 计划的特点：

ZooKeeper 的一大特点就是强一致性，ZooKeeper 集群的每个节点的数据每次产生更新操作，都会告诉其它 ZooKeeper 节点同时执行更新。它要求保障每个节点的数据可能实时的完全一致，这样也就会导致 ZooKeeper 集群性能上的降落，ZK 是采纳 CP 模式（保障强一致性），如果要重视性能，能够思考采纳 AP 模式（保障最终统一）的注册核心组件，比方 Nacos 等。

源码分析

Dubbo Spring Cloud 订阅的源码(客户端）：

外围源码：

RegistryProtocol 的 doRefer 办法：

private <T> Invoker<T> doRefer(Cluster cluster, Registry registry, Class<T> type, URL url) {RegistryDirectory<T> directory = new RegistryDirectory<T>(type, url);
        directory.setRegistry(registry);
        directory.setProtocol(protocol);
        // all attributes of REFER_KEY
        Map<String, String> parameters = new HashMap<String, String>(directory.getUrl().getParameters());
        URL subscribeUrl = new URL(CONSUMER_PROTOCOL, parameters.remove(REGISTER_IP_KEY), 0, type.getName(), parameters);
        if (!ANY_VALUE.equals(url.getServiceInterface()) && url.getParameter(REGISTER_KEY, true)) {directory.setRegisteredConsumerUrl(getRegisteredConsumerUrl(subscribeUrl, url));
            registry.register(directory.getRegisteredConsumerUrl());
        }
        directory.buildRouterChain(subscribeUrl);
        directory.subscribe(subscribeUrl.addParameter(CATEGORY_KEY,
                PROVIDERS_CATEGORY + "," + CONFIGURATORS_CATEGORY + "," + ROUTERS_CATEGORY));

        Invoker invoker = cluster.join(directory);
        ProviderConsumerRegTable.registerConsumer(invoker, url, subscribeUrl, directory);
        return invoker;
    }

Dubbo Spring Cloud 注册发现的源码（服务端）：

外围源码：

RegistryProtocol 的 export 办法：

public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
        // 获取注册信息
        URL registryUrl = getRegistryUrl(originInvoker);
        // 获取服务提供方信息
        URL providerUrl = getProviderUrl(originInvoker);

        // Subscribe the override data
        // FIXME When the provider subscribes, it will affect the scene : a certain JVM exposes the service and call
        //  the same service. Because the subscribed is cached key with the name of the service, it causes the
        //  subscription information to cover.
        final URL overrideSubscribeUrl = getSubscribedOverrideUrl(providerUrl);
        final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
        overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);

        providerUrl = overrideUrlWithConfig(providerUrl, overrideSubscribeListener);
        //export invoker
        final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker, providerUrl);

        // 获取订阅注册器
        final Registry registry = getRegistry(originInvoker);
        final URL registeredProviderUrl = getRegisteredProviderUrl(providerUrl, registryUrl);
        ProviderInvokerWrapper<T> providerInvokerWrapper = ProviderConsumerRegTable.registerProvider(originInvoker,
                registryUrl, registeredProviderUrl);
        //to judge if we need to delay publish
        boolean register = registeredProviderUrl.getParameter("register", true);
        if (register) {
            // 进入服务端信息注册解决
            register(registryUrl, registeredProviderUrl);
            providerInvokerWrapper.setReg(true);
        }

        // Deprecated! Subscribe to override rules in 2.6.x or before.
        // 服务端信息订阅解决
        registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);

        exporter.setRegisterUrl(registeredProviderUrl);
        exporter.setSubscribeUrl(overrideSubscribeUrl);
        //Ensure that a new exporter instance is returned every time export
        return new DestroyableExporter<>(exporter);
    }

有哪些网络 IO 模型

分为五种：
- 同步阻塞 IO（BIO）
- 同步非阻塞 IO（NIO）
- IO 多路复用
- 信号驱动 IO
- 异步非阻塞 IO（AIO）
罕用的是同步阻塞 IO 和 IO 多路复用模型。
什么是阻塞 IO 模型

通常由一个独立的 Acceptor 线程负责监听客户端的连贯。个别通过在while(true) 循环中服务端会调用 accept() 办法期待接管客户端的连贯的形式监听申请，申请一旦接管到一个连贯申请，就能够建设通信套接字, 在这个通信套接字上进行读写操作，此时不能再接管其余客户端连贯申请，直到客户端的操作执行实现。
零碎内核解决 IO 操作分为两个阶段——期待数据和拷贝数据。而在这两个阶段中，利用过程中 IO 操作的线程会始终都处于阻塞状态，如果是基于 Java 多线程开发，那么每一个 IO 操作都要占用线程，直至 IO 操作完结。

IO 多路复用

概念：服务端采纳单线程过 select/epoll 机制，获取 fd 列表，遍历 fd 中的所有事件, 能够关注多个文件描述符，使其可能反对更多的并发连贯。

IO 多路复用的实现次要有 select，poll 和 epoll 模式。

文件描述符：

在 Linux 零碎中所有皆能够看成是文件，文件又可分为：一般文件、目录文件、链接文件和设施文件。

文件描述符（file descriptor）是内核为了高效治理已被关上的文件所创立的索引，用来指向被关上的文件。文件描述符的值是一个非负整数。

下图阐明（右边是过程、两头是内核、左边是文件系统）：

1）A 的文件描述符 1 和 30 都指向了同一个关上的文件句柄，代表过程屡次执行关上操作。

2）A 的文件描述符 2 和 B 的文件描述符 2 都指向文件句柄（#73），代表 A 和程 B 可能是父子过程或者 A 和过程 B 关上了同一个文件（低概率）。

3）（工夫缓和可不讲）A 的描述符 0 和 B 的描述符 3 别离指向不同的关上文件句柄，但这些句柄均指向 i -node 表的雷同条目（#1936），这种状况是因为每个过程各自对同一个文件发动了关上申请。

程序刚刚启动的时候，0 是规范输出，1 是规范输入，2 是规范谬误。如果此时去关上一个新的文件，它的文件描述符会是 3。

三者的区别：

| | select | poll | epoll |
| :——— | :————————————————- | :———————————————– | :———————————————————– |
| 操作形式 | 遍历 | 遍历 | 回调 |
| 底层实现 | bitmap | 数组 | 红黑树 |
| IO 效率 | 每次调用都进行线性遍历，工夫复杂度为 O(n) | 每次调用都进行线性遍历，工夫复杂度为 O(n) | 事件告诉形式，每当 fd 就绪，零碎注册的回调函数就会被调用，将就绪 fd 放到 readyList 外面，工夫复杂度 O(1) |
| 最大连接数 | 1024（x86）或 2048（x64）| 无下限 | 无下限 |
| fd 拷贝 | 每次调用 select，都须要把 fd 汇合从用户态拷贝到内核态 | 每次调用 poll，都须要把 fd 汇合从用户态拷贝到内核态 | 调用 epoll_ctl 时拷贝进内核并保留，之后每次 epoll_wait 不拷贝 |

select/poll 解决流程：

此处是动图

epoll 的解决流程：

此处是动图

当连贯有 I / O 流事件产生的时候，epoll 就会去通知过程哪个连贯有 I / O 流事件产生，而后过程就去解决这个过程。这样性能相比要高效很多！

epoll 能够说是 I /O 多路复用最新的一个实现，epoll 修复了 poll 和 select 绝大部分问题, 比方

epoll 是线程平安的。
epoll 不仅通知你 sock 组外面的数据，还会通知你具体哪个 sock 连贯有数据，不必过程单独轮询查找。

select 模型

应用示例：

 while (1) {
    // 阻塞获取
    // 每次须要把 fd 从用户态拷贝到内核态
    nfds = select(max + 1, &read_fd, &write_fd, NULL, &timeout);
    // 每次须要遍历所有 fd，判断有无读写事件产生
    for (int i = 0; i <= max && nfds; ++i) {if (i == listenfd) {
         --nfds;
         // 这里解决 accept 事件
         FD_SET(i, &read_fd);// 将客户端 socket 退出到汇合中
      }
      if (FD_ISSET(i, &read_fd)) {
        --nfds;
        // 这里解决 read 事件
      }
      if (FD_ISSET(i, &write_fd)) {
         --nfds;
        // 这里解决 write 事件
      }
    }
  }

毛病：

单个过程所关上的 FD 最大数限度为 1024。
每次调用 select，都须要把 fd 汇合从用户态拷贝到内核态，fd 数据较大时影响性能。
对 socket 扫描时是线性扫描，效率较低（高并发场景）

POLL 模型

int max  = 0;  // 队列的理论长度
while (1) {
    // 阻塞获取
    // 每次须要把 fd 从用户态拷贝到内核态
    nfds = poll(fds, max+1, timeout);
    if (fds[0].revents & POLLRDNORM) {
        // 这里解决 accept 事件
        connfd = accept(listenfd);
        // 将新的描述符增加到读描述符汇合中
    }
    // 每次须要遍历所有 fd，判断有无读写事件产生
    for (int i = 1; i < max; ++i) {if (fds[i].revents & POLLRDNORM) {sockfd = fds[i].fd
                if ((n = read(sockfd, buf, MAXLINE)) <= 0) {
                    // 这里解决 read 事件
                    if (n == 0) {close(sockfd);
                        fds[i].fd = -1;
                    }
                } else {// 这里解决 write 事件}
            if (--nfds <= 0) {break;}   
        }
    }
}

毛病：

poll 与 select 相比，只是没有 fd 的限度，都存在雷同的缺点。

EPOLL 模型

应用示例：

// 须要监听的 socket 放到 ep 中
epoll_ctl(epfd,EPOLL_CTL_ADD,listenfd,&ev); 
while(1) {
     // 阻塞获取
     nfds = epoll_wait(epfd,events,20,0);
     for(i=0;i<nfds;++i) {if(events[i].data.fd==listenfd) {
             // 这里解决 accept 事件
             connfd = accept(listenfd);
             // 接管新连贯写到内核对象中
             epoll_ctl(epfd,EPOLL_CTL_ADD,connfd,&ev);
         } else if (events[i].events&EPOLLIN) {
             // 这里解决 read 事件
             read(sockfd, BUF, MAXLINE);
             // 读完后筹备写
             epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);
         } else if(events[i].events&EPOLLOUT) {
             // 这里解决 write 事件
             write(sockfd, BUF, n);
             // 写完后筹备读
             epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);
         }
     }
 }

毛病：

目前只能工作在 linux 环境下
数据量很小的时候没有性能劣势

epoll 下的两种模式（拓展理解）：

EPOLLLT 和 EPOLLET 两种触发模式，LT 是默认的模式，ET 是“高速”模式。

LT（程度触发）模式下，只有这个 fd 还有数据可读，每次 epoll_wait 都会返回它的事件，揭示用户程序去操作

ET（边缘触发）模式下，它只会提醒一次，直到下次再有数据流入之前都不会再提醒了，无论 fd 中是否还有数据可读。所以在 ET 模式下，read 一个 fd 的时候肯定要把它的 buffer 读完，或者遇到 EAGAIN 谬误

三种模式比照

比照项	select	poll	epoll
数据结构	bitmap	数组	红黑树
最大连接数	1024	无下限	无下限
fd 拷贝	每次调用 select 拷贝	每次调用 poll 拷贝	fd 首次调用 epoll_ctl 拷贝，每次调用 epoll_wait 不拷贝
工作效率	轮询：O(n)	轮询：O(n)	回调：O(1)

为什么阻塞 IO 和 IO 多路复用最为罕用？

在理论的网络 IO 的利用中，须要的是零碎内核的反对以及编程语言的反对。当初大多数零碎内核都会反对阻塞 IO、非阻塞 IO 和 IO 多路复用，但像信号驱动 IO、异步 IO，只有高版本的 Linux 零碎内核才会反对。

同步阻塞 IO、同步非阻塞 IO、同步 IO 多路复用与异步 IO 区别：
- 同步阻塞 IO(本质上，每个申请不论胜利或失败，都会阻塞)
- 同步非阻塞 IO(相比第一种的齐全阻塞，如果数据没筹备好，会返回 EWOULDBLOCK，这样就不会造成阻塞)
- 同步 IO 多路复用
  
  （kernel 会依据 select/epoll 等机制，监听所有 select 接入的 socket，当任何一个 socket 中的数据筹备好了，select 就会返回，使得一个过程能同时期待多个文件描述符。）
- 异步 IO

RPC 框架采纳哪种网络 IO 模型？

1) IO 多路复用利用特点：

IO 多路复用更适宜高并发的场景，能够用较少的过程（线程）解决较多的 socket 的 IO 申请，但应用难度比拟高。

2) 阻塞 IO 利用特点:

与 IO 多路复用相比，阻塞 IO 每解决一个 socket 的 IO 申请都会阻塞过程（线程），但应用难度较低。在并发量较低、业务逻辑只须要同步进行 IO 操作的场景下，阻塞 IO 曾经满足了需要，并且不须要发动大量的 select 调用，开销上要比 IO 多路复用低。

3) RPC 框架利用：

RPC 调用在大多数的状况下，是一个高并发调用的场景，在 RPC 框架的实现中，个别会抉择 IO 多路复用 的形式。在开发语言的网络通信框架的选型上，咱们最优的抉择是基于 Reactor 模式实现的框架，如 Java 语言，首选的框架便是 Netty 框架（目前 Netty 是利用最为宽泛的框架），并且在 Linux 环境下，也要开启 epoll 来晋升零碎性能（Windows 环境下是无奈开启 epoll 的，因为零碎内核不反对）。

为什么须要工夫轮？

在 Dubbo 中，为加强零碎的容错能力，会有相应的监听判断解决机制。比方 RPC 调用的 超时机制 的实现，消费者 判断 RPC 调用是否超时 ，如果超时会将超时后果 返回给应用层 。在 Dubbo 最开始的实现中，是将所有的返回后果（DefaultFuture） 都放入一个汇合中，并且通过一个定时工作，每隔肯定工夫距离就扫描所有的 future，一一判断是否超时。

这样的实现形式尽管比较简单，然而存在一个问题就是会有 很多无意义的遍历操作开销。比方一个 RPC 调用的超时工夫是 10 秒，而设置的超时断定的定时工作是 2 秒执行一次，那么可能会有 4 次左右无意义的循环检测判断操作。

为了解决上述场景中的相似问题，Dubbo 借鉴 Netty，引入了工夫轮算法，缩小无意义的轮询判断操作。
工夫轮原理

对于以上问题，目标是要缩小额定的扫描操作就能够了。比如说一个定时工作是在 5 秒之后执行，那么在 4.9 秒之后才扫描这个定时工作，这样就能够极大缩小 CPU 开销。这时咱们就能够利用时钟轮的机制了。

时钟轮的本质上是参考了生存中的 时钟跳动的原理，那么具体是如何实现呢？

在时钟轮机制中，有 时间槽和时钟轮 的概念，时间槽就相当于时钟的刻度；而时钟轮就相当于指针跳动的一个周期，咱们能够将每个工作放到对应的时间槽位上。

如果时钟轮有 10 个槽位，而时钟轮一轮的周期是 10 秒 ，那么咱们每个槽位的单位工夫就 是 1 秒 ，而 下一层 工夫轮的周期就是 100 秒，每个槽位的单位工夫也就是 10 秒，这就好比秒针与分针，在秒针周期下，刻度单位为秒，在分针周期下，刻度为分。

假如当初咱们有 3 个工作，别离是工作 A（0.9 秒之后执行）、工作 B（2.1 秒后执行）与工作 C（12.1 秒之后执行），咱们将这 3 个工作增加到时钟轮中，工作 A 被放到第 0 槽位，工作 B 被放到第 2 槽位，工作 C 被放到下一层工夫轮的第 2 个槽位，如下图所示：

通过这个场景咱们能够理解到，时钟轮的扫描周期仍是最小单位 1 秒，然而搁置其中的工作并没有重复扫描，每个工作会按要求只扫描执行一次，这样就可能很好 的解决 CPU 节约的问题。

叠加时钟轮，有限增长，效率会一直降落，该如何解决？设定三个时钟轮，小时轮，分钟轮，秒级轮

Dubbo 中的工夫轮原理是如何实现？

次要是通过 Timer，Timeout，TimerTask 几个接口定义了一个定时器的模型，再通过 HashedWheelTimer 这个类实现了一个工夫轮定时器（默认的时间槽的数量是 512，能够自定义这个值）。它对外提供了简略易用的接口，只须要调用 newTimeout 接口，就能够实现对只需执行一次工作的调度。通过该定时器，Dubbo 在响应的场景中实现了高效的任务调度。

Dubbo 源码分析

工夫轮外围类 HashedWheelTimer 构造：

工夫轮在 RPC 的利用

调用超时与重试解决 ：下面所讲的客户端调用 超时的解决 ，就能够利用到时钟轮，咱们每发一次申请，都创立一个解决申请超时的定时工作放到时钟轮里，在高并发、高访问量的状况下，时钟轮每次只轮询一个时间槽位中的工作，这样会 节俭大量的 CPU。

源码：

FailbackRegistry，代码片段：

// 构造方法
public FailbackRegistry(URL url) {super(url);
        this.retryPeriod = url.getParameter(REGISTRY_RETRY_PERIOD_KEY, DEFAULT_REGISTRY_RETRY_PERIOD);

        // since the retry task will not be very much. 128 ticks is enough.
        // 重试器的时间槽数量，设定为 128
        retryTimer = new HashedWheelTimer(new NamedThreadFactory("DubboRegistryRetryTimer", true), retryPeriod, TimeUnit.MILLISECONDS, 128);
    }

// 失败工夫工作注册器
private void addFailedRegistered(URL url) {FailedRegisteredTask oldOne = failedRegistered.get(url);
        if (oldOne != null) {return;}
        FailedRegisteredTask newTask = new FailedRegisteredTask(url, this);
        oldOne = failedRegistered.putIfAbsent(url, newTask);
        if (oldOne == null) {
            // never has a retry task. then start a new task for retry.
            // 旧工作不存在，则搁置工夫轮，开启新一个工作
            retryTimer.newTimeout(newTask, retryPeriod, TimeUnit.MILLISECONDS);
        }
    }

定时心跳检测 ：RPC 框架调用端定时向服务端发送的心跳检测，来保护连贯状态，咱们能够将心跳的逻辑封装为一个心跳工作，放到时钟轮里。心跳是要定时反复执行的，而时钟轮中的工作执行一遍就被移除了，对于这种须要反复执行的定时工作咱们该如何解决呢？咱们在 定时工作逻辑完结的最初 ，再加上一段逻辑，重设这个工作的执行工夫，把它 从新丢回到时钟轮里。这样就能够实现循环执行。

源码：

HeaderExchangeServer 代码片段：

...
// 建设心跳工夫轮，槽位数默认为 128
private static final HashedWheelTimer IDLE_CHECK_TIMER = new HashedWheelTimer(new NamedThreadFactory("dubbo-server-idleCheck", true), 1,
            TimeUnit.SECONDS, TICKS_PER_WHEEL);
...
    // 启动心跳工作检测
    private void startIdleCheckTask(URL url) {if (!server.canHandleIdle()) {AbstractTimerTask.ChannelProvider cp = () -> unmodifiableCollection(HeaderExchangeServer.this.getChannels());
            int idleTimeout = getIdleTimeout(url);
            long idleTimeoutTick = calculateLeastDuration(idleTimeout);
            CloseTimerTask closeTimerTask = new CloseTimerTask(cp, idleTimeoutTick, idleTimeout);
            this.closeTimerTask = closeTimerTask;

            // init task and start timer.
            // 开启心跳检测工作
            IDLE_CHECK_TIMER.newTimeout(closeTimerTask, idleTimeoutTick, TimeUnit.MILLISECONDS);
        }
    }
...

连贯检测，会一直执行，退出工夫轮中。

AbstractTimerTask 源码：

    @Override
    public void run(Timeout timeout) throws Exception {Collection<Channel> c = channelProvider.getChannels();
        for (Channel channel : c) {if (channel.isClosed()) {continue;}
            // 调用心跳检测工作
            doTask(channel);
        }
        // 从新放入工夫轮中
        reput(timeout, tick);
    }

还能够参考 HeartbeatTimerTask、ReconnectTimerTask 源码实现。

为什么要采纳异步？

如果采纳同步调用，CPU 大部分的工夫都在期待而没有去计算，从而导致 CPU 的利用率不够。

RPC 申请比拟耗时的起因次要是在哪里？

在大多数状况下，RPC 自身解决申请的效率是在毫秒级的。RPC 申请的耗时大部分都是业务耗时，比方业务逻辑中有拜访数据库执行慢 SQL 的操作，外围是在 I / O 瓶颈。所以说，在大多数状况下，影响到 RPC 调用的吞吐量的起因也就是业务逻辑解决慢了，CPU 大部分工夫都在期待资源。
调用端如何实现异步？

罕用的形式就是 Future 形式，它是返回 Future 对象，通过 GET 形式获取后果；或者采纳入参为 Callback 对象的回调形式，处理结果。

从 DUBBO 框架，来看具体是如何实现异步调用？

服务端如何实现异步？

为了晋升性能，连贯申请与业务解决不会放在一个线程解决，这个就是服务端的异步化。服务端业务解决逻辑退出异步解决机制。

在 RPC 框架提供一种回调形式，让业务逻辑能够异步解决，解决完之后调用 RPC 框架的回调接口。

RPC 框架的异步策略次要是调用端异步与服务端异步。调用端的异步就是通过 Future 形式。

服务端异步则须要一种回调形式，让业务逻辑能够异步解决。这样就实现了 RPC 调用的全异步化。

RPC 框架的异步实现

RPC 框架的异步策略次要是调用端异步与服务端异步。调用端的异步就是通过 Future 形式实现异步，调用端发动一次异步申请并且从申请上下文中拿到一个 Future，之后通过 Future 的 get 办法获取后果，如果业务逻辑中同时调用多个其它的服务，则能够通过 Future 的形式缩小业务逻辑的耗时，晋升吞吐量。

服务端异步则须要一种回调形式，让业务逻辑能够异步解决，之后调用 RPC 框架提供的回调接口，将最终后果异步告诉给调用端。这样就实现了 RPC 调用的全异步。

Dubbo 源码：

异步调用：AsyncToSyncInvoker.invoke 办法

获取后果：ChannelWrappedInvoker.doInvoke 办法

咱们前面会解说灰度公布机制，基于 Nginx+Lua、扩大 SpringCloud Gateway 源码灰度公布和负载平衡，只有我的项目集群、分布式应用就会波及到路由与负载平衡。

为什么要采纳路由？

实在的环境中个别是以集群的形式提供服务，对于服务调用方来说，一个接口会有多个服务提供方同时提供服务，所以 RPC 在每次发动申请的时候，都须要从多个服务节点外面 选取一个用于解决申请的服务节点。

这就须要在 RPC 利用中减少路由性能。
如何实现路由？

服务注册发现形式：

通过服务发现的形式从逻辑上看是可行，但注册核心是用来保证数据的一致性。通过服务发现形式来实现申请隔离并不现实。

RPC 路由策略：

从服务提供方节点汇合外面抉择一个适合的节点（负载平衡），把合乎咱们要求的节点筛选进去。这个就是路由策略：

接管申请 –> 申请校验 –> 路由策略 –> 负载平衡 –>

应用了 IP 路由策略后，整个集群的调用拓扑如下图所示：

有些场景下，可能还须要更细粒度的路由形式，比如说依据 SESSIONID 要落到雷同的服务节点上以放弃会话的有效性;

能够思考采纳 参数化路由：

RPC 框架中的负载平衡

RPC 的负载平衡是由 RPC 框架本身提供实现，自主抉择一个 最佳的服务节点，发动 RPC 调用申请。

RPC 负载平衡策略个别包含轮询、随机、权重、起码连贯等。Dubbo 默认就是应用随机负载平衡策略。
自适应的负载平衡策略

RPC 的负载平衡齐全由 RPC 框架本身实现，服务调用方发动申请时，会通过所配置的负载平衡组件，自主地抉择适合服务节点。调用方如果能晓得每个服务节点解决申请的能力，再依据服务节点解决申请的能力来判断调配相应的流量，集群资源就可能失去充沛的利用，当一个服务节点负载过高或响应过慢时，就少给它发送申请，反之则多给它发送申请。这个就是自适应的负载平衡策略。

具体如何实现？

这就须要断定服务节点的解决能力。

次要步骤：

（1）增加计分器和指标采集器。

（2）指标采集器收集服务节点 CPU 核数、CPU 负载以及内存占用率等指标。

（3）能够配置开启哪些指标采集器，并设置这些参考指标的具体权重。

（4）通过对服务节点的综合打分，最终计算出服务节点的理论权重，抉择适合的服务节点。

咱们前面课程会具体解说熔断限流组件 Sentinel 高级用法、源码分析、策略机制，然而 RPC 须要思考熔断限流机制，咱们一起来理解一下。

为什么要进行限流？

在理论生产环境中，每个服务节点都可能因为拜访量过大而引起一系列问题，就需 要业务提供方可能进行自我爱护 ，从而 保障在高访问量、高并发的场景下 ，零碎仍然能 够稳固，高效 运行。
服务端的自我爱护实现

在 Dubbo 框架中，能够通过 Sentinel 来实现更为欠缺的熔断限流性能，服务端是具体如何实现限流逻辑的？

办法有很多种，最简略的是计数器，还有平滑限流的滑动窗口、漏斗算法以及令牌桶算法等等。Sentinel 采纳的是 滑动窗口 来实现的限流。

windowStart: 工夫窗口的开始工夫，单位是毫秒

windowLength: 工夫窗口的长度，单位是毫秒

value: 工夫窗口的内容

初始的时候 arrays 数组中只有一个窗口，每个工夫窗口的 长度是 500ms，这就意味着只有以后工夫与工夫窗口的 差值在 500ms 之内，工夫窗口就不会向前滑动。

工夫持续往前走，当超过 500ms 时，工夫窗口就会向前滑动到下一个，这时就会更新以后窗口的开始工夫：

在以后工夫点中进入的申请，会被统计到以后工夫所对应的工夫窗口中。

调用方的自我爱护

一个服务 A 调用服务 B 时，服务 B 的业务逻辑又调用了服务 C，这时服务 C 响应超时，服务 B 就可能会因为沉积大量申请而导致服务宕机，由此产生 服务雪崩 的问题。

熔断解决流程：

熔断机制：

熔断器的工作机制次要是 敞开、关上和半关上 这三个状态之间的切换。

Sentinel 熔断降级组件它能够反对以下降级策略：

均匀响应工夫 (DEGRADE_GRADE_RT)：当 1s 内继续进入 N 个申请，对应时刻的均匀响应工夫（秒级）均超过阈值（count，以 ms 为单位），那么在接下的工夫窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个办法的调用都会主动地熔断（抛出 DegradeException）。留神 Sentinel 默认统计的 RT 下限是 4900 ms，超出此阈值的都会算作 4900 ms，若须要变更此下限能够通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。
异样比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：当资源的每秒申请量 >= N（可配置），并且每秒异样总数占通过量的比值超过阈值（DegradeRule 中的 count）之后， 资源进入降级状态，即在接下的工夫窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个办法的调用都会主动地返回。异样比率的阈值范畴是 [0.0, 1.0]，代表 0% – 100%。
异样数 (DEGRADE_GRADE_EXCEPTION_COUNT)：当资源近 1 分钟的异样数目超过阈值之后会进行熔断。留神因为统计工夫窗口是分钟级别的，若 timeWindow 小于 60s，则完结熔断状态后仍可能再进入熔断状态。

更多材料，参考 Sentinel 官网文档)。

本文由传智教育博学谷 – 狂野架构师教研团队公布
转载请注明出处！

为什么要学习 RPC

1.1 PRC 概述

1.2 RPC 框架

1.3 利用场景

2. 深刻 RPC 原理

2.1 设计与调用流程

2.2 RPC 深刻解析

2.2.1 序列化技术

2.2.2 动静代理

2.2.3 服务注册发现

2.2.4 网络 IO 模型

2.2.5 工夫轮

3. RPC 的高级机制

3.1 异步解决机制

3.2 路由与负载平衡(理解)

3.3 熔断限流(理解)

站内搜索