Java的零拷贝是怎么来的？（附教程）

1、首先需要从磁盘读取数据。 这需要发送读取请求。 您需要从用户模式切换到内核模式才能完成此命令。

2.然后在内核态使用DMA技术将磁盘数据复制到内核态缓存，然后将内核态缓存数据复制到用户态缓存。

3.然后需要将数据从用户态缓存复制到内核态缓存。 此时用户态切换到内核态。

4、然后就得通过DMA技术将内核态缓存的数据复制到网卡缓存中，然后发送，然后切换回用户态。

用户模式和内核模式之间有四次切换，以及四份数据副本。 事实上，发送这个进程时不需要在用户态和内核态之间来回复制数据。有两种零复制方法可以解决这些问题

序列化：

RPC数据传输依赖于TCP。 TCP传输的数据是二进制数据。 这时候就需要对方法中传输的对象进行序列化和反序列化。 序列化需要考虑的要点有：安全性、兼容性、性能、序列化后的大小。

目前比较知名的有Json、、Kryo。 和dubbo默认的序列化方式一样，feign是Json，gRPC是。

SPI

RPC 的扩展插件功能。 在Java中，JDK有自己的SPI服务发现机制，可以动态地查找某个接口的服务实现。 要使用SPI机制，需要在META-INF/目录下创建一个以服务接口命名的文件。 该文件中的内容就是该接口的具体实现类。 事实上，JDK的SPI功能很少被使用，因为： 1. JDK标准SPI会一次性加载实例化扩展点的所有实现。 当JDK启动时，META-INF/文件中的所有实现类都会被一次性加载。 如果某些扩展点的初始化比较耗时或者某些实现类没有被使用，就会造成资源的浪费。 2.如果扩展点加载失败，会导致调用者报错，而且这个错误很难定位。

Dubbo自己的SPI机制在市场上是比较知名的。 Dubbo的SPI机制可以根据需要扩展插件。 几乎所有的功能组件都是基于SPI实现的，并且默认提供了很多可以直接使用的扩展点，比如序列化。 方法、传输协议等

当然它也有自己的SPI机制，只不过是通过注入的方式实现的。 它主要通过按需注入的方式实现类似SPI的机制。

2. 服务治理

服务治理主要包括：服务发现、服务更新、健康检测、负载均衡、容灾容错等，这些功能主要是通过将服务注册到注册中心来实现的。比较著名的注册中心有：、nacos等。

服务发现

服务发现主要维护调用接口和服务提供者地址之间的映射关系，可以帮助我们定位调用服务提供者的IP地址，维护集群IP地址的动态变化。 通过服务发现，我们可以从集群中获取相应接口的IP集，并通过负载均衡选择IP地址来调用它。 这也是PRC的服务发现机制。 服务发现通过以下两种方式实现：

1、服务注册：服务提供者启动时，向注册中心注册自己的节点信息（IP地址、端口、服务接口等）。

2.服务订阅：当服务调用者启动时，去注册中心查找并订阅服务提供者的IP，然后减速

保存在本地，后续远程调用时使用。

3、服务更新：定期从注册中心拉取其他节点的信息，更新本地缓存。

目前比较流行的服务发现框架有Nacos和Nacos。 分布式系统不可能同时满足C（一致性）、A（可用性）和P（分区容错性），其中 是cp，是AP。

自我保护模式可能会在短时间内丢失过多的客户端（可能是网络故障引起的），那么节点将进入自我保护模式，并且不会再注销任何微服务。 当网络故障恢复后，节点会自动退出自我保护模式。在大规模集群服务中发现系统时，放弃强一致性，更加关注系统的健壮性。 最终一致性是分布式系统设计中比较常用的策略。

健康检查

PRC在进行负载均衡和调用服务时，通常需要知道哪些IP地址节点可用，哪些节点不可用。 这些信息需要注册中心对注册的服务节点进行健康检测。 最常见的方法是定期心跳检测。 在已建立的 TCP 连接上发送类似 ping 的请求。 根据服务节点的响应，可以分为以下三种状态：

1、健康状态：连接建立成功，心跳检测始终成功。

2、亚健康状态：连接建立成功，但心跳请求持续失败。

3.死亡状态：建立连接失败。

不同框架中心跳检测的频率是不同的。 例如，如果心跳是每30秒一次，如果90秒内没有收到更新，则该服务将被删除。

负载均衡

微服务框架或者RPC框架都会有负载均衡的功能，这也是集群必备的能力。 一般情况下，从注册中心拉取服务提供者信息并缓存在本地后，调用对应接口服务时，会从对应接口的服务提供者节点集合中选择一个可能的节点进行调用，具体调用哪一个？ 节点会有不同的选择策略，例如：轮询、随机、加权轮询、最小活跃调用数、一致性哈希等。

例如： ，它是服务消费和负载均衡的核心组件。 它是一个基于http和tcp的负载均衡组件。 它实现服务消费，通过配置的服务列表进行轮询访问。 但与集成使用时，服务列表会被服务列表重写并扩展，从注册中心获取服务。 列表（服务列表是从注册中心拉取的服务节点的信息数据）。 同时，它用确认哪些服务可用的功能取代了自己的Iping功能。 因此，通过注册中心服务发现、服务注册、服务续订和健康检测机制来完成可用服务的节点地址和健康信息的发现，然后使用自己的负载策略来消费服务。

断路器，电流限制退化

熔断、限流、降级是微服务分布式系统的必备功能。 主要解决由于访问流量过大、节点负载过大、业务时间过长等带来的诸多问题。 通过熔断和降级，可以避免因业务处理时间过长导致接口服务超时过多而导致系统级联故障。 限流保护系统避免了流量接入过多、节点负载过大等问题。

业界最经典的断路和限流降级解决方案，就是一整套断路和限流降级思路的实现。

接下来我们就来隆重介绍一下：

请求的隔离策略有两种：线程隔离和信号量。还有限流的方法：隔离、熔断、降级

线程隔离：

将打开线程池来执行请求。 这个线程池和普通线程池一样，有核心线程数、最大线程数、任务队列、线程空闲时间等，请求会被扔到线程池中执行。 当超过核心线程数时，当超过线程数时，就会扩容线程，当超过最大线程数时，就会被扔进队列。 机制和普通线程池一模一样。 默认情况下，一个类内容的所有方法的请求流量共享一个线程池。

信号量隔离：限流

与线程隔离不同，信号量隔离可以限制相应服务接口调用的最大并发请求数。基于信号量控制最大并发数可以达到限流的目的。

断路器降级：

可以开启服务接口调用的超时功能。 默认值为 1000 毫秒。 可以设置超时是否中断。 该设置仅对线程隔离策略有效。 默认是超时时中断执行。 也会根据固定时间间隔内调用接口的成功率来判断。 是否开启熔断和半熔断以供后续检测。 默认的熔断和半熔断规则如下：

1. 熔断：

当时间窗口内对后端服务的失败请求数量超过一定比例（默认为50%，可以使用.tage设置比例）时，断路器将切换到熔断状态（Open）。 需要注意的是，时间窗口内的请求数量必须超过一定的值。 计算失败次数（默认 20）。 如果默认值下只有19个请求，即使所有请求都失败，断路器也不会打开（请求数可以通过.ld设置）。 断路器开启后，所有请求将直接失败并触发相应的降级方法。

2、半熔断器：

断路器保持分闸状态一段时间后（默认为5秒，熔断器睡眠时间可通过.conds设置），自动切换到半熔断状态（HALF-OPEN）。 这时候就会放开一个请求，根据返回情况来设置状态。 如果请求成功，断路器将闭合熔丝状态（），否则将再次切换到熔丝状态（OPEN）。 当按照规则发现端服务不可用时，将直接切断请求链，避免发送大量无效请求影响系统吞吐量，并且断路器具有自我检测和恢复能力恢复。

熔断过程中，所有请求都会触发相应的降级方法。

分布式链接跟踪：

在分布式系统中进行RPC调用时，可能会涉及多个远程服务调用。 假设分布式应用系统由4个子服务组成，4个服务的依赖关系为A->B->C->D。 如果调用服务出现异常，仅靠打印日志往往无法快速定位问题。 这时候就需要使用分布式链路跟踪。 比较知名的分布式链接跟踪组件是 .

分布式链路跟踪有Trace和Span的概念。 Trace是一个服务调用链接。 每次分发时都会生成一条Trace。 每个跟踪都有其唯一的标识符。 也就是说，在分布式链路跟踪系统中，每个Trace通过 来区分。

Span代表一个调用链路中的一个链路，也就是说Trace是由多个Span组成的。 在Trace下，每个Span也有其唯一的标识符，Span之间有父子关系。

例如：A->B->C->D的情况，整个调用链中，正常情况下会生成3个span，分别是Span1(A->B)、Span2(B->C)， Span3 (C->D)，然后是 Span3

Span2的父Span为Span2，Span2的父Span为Span1

另一个例子：

该日志将在以下位置生成：[order-,,,false]

1、第一个值是项目中配置的..name的值

2. 第二个值 是生成的ID，即Trace ID，用于标识请求链接。 一个请求链接包含一个Trace ID和多个Span ID。

3. 第三个值是。

4、第四个值：false，是否将信息输出到服务进行采集和展示。

路由网关和配置中心：

路由网关的作用与nginx类似。 所有请求在到达集群之前都会经过网关进行URL过滤、权限验证、负载均衡等。 路由网关还通过服务发现功能将注册中心的所有节点IP信息拉取到本地。 然后通过配置来过滤URL、进行负载均衡等。 业界最著名的路由网关是zuul和zuul。 其中使用的nio网络编程技术在性能上甚至比zuul还要好。

配置中心收集系统配置，如：yml、网关配置变更、网关限流策略变更等配置，然后各节点通过TCP长连接从配置中心拉取相应配置进行实施。 热加载、统一管理的效果。市面上比较流行的有