小工匠

这时就需要一个调度者去监控所有的客户端连接，比如当图中的客户端 A 的输入已经准备好后，就由这个调度者去通知服务端的工作线程，告诉它们由工作线程 1 去服务于客户端 A 的请求。此时，商品详情页的 QPS 已达到了 2 万次/s，在做了服务化拆分之后，此时完成一次请求需要调用 3 次 RPC 服务，计算下来，RPC 服务需要承载大概 6 万次/s 的请求。根据 RPC 协议，服务提供方将二进制数据分割出不同的请求数据，经过反序列化将二进制数据逆向还原出请求对象，找到对应的实现类，完成真正的方法调用；

它通过屏蔽底层通信细节，让开发者像调用本地函数一样使用远程服务。接下来我们将深入解析RPC的核心架构、通信流程及关键特性。高性能场景选择Protobuf/Thrift，调试友好场景用JSON，传统企业系统可能采用SOAP。通过IDL（接口描述语言）定义服务，支持多语言客户端生成（如gRPC支持10+语言）。开发者无需关注底层使用HTTP或TCP协议，框架自动处理网络传输细节。接口调用与本地方法完全一致，参数自动完成序列化/反序列化。发送网络请求(TCP/HTTP)调用远程方法(参数)

这种通过“请求中的类型”，把请求分发到对应的处理类或者处理方法的设计，在服务端处理请求的场景中，这是一个很常用的方法。我们这里使用的也是同样的设计，不同的是，我们使用了一个命令注册机制，让这个路由分发的过程省略了大量的 if-else 或者是 switch 代码。把服务的实现类注册到 RPC 框架中，这个逻辑的实现很简单，我们只要使用一个合适的数据结构，记录下所有注册的实例就可以了，后面在处理客户端请求的时候，会用到这个数据结构来查找服务实例。类，根据服务名分发到具体的服务实现类。这个类的唯一的一个实例。

注册中心和RPC服务。注册中心：负责管理服务元数据，并提供服务发现的功能。RPC服务：负责处理客户端发来的RPC请求，并调用相应的业务服务。简单来说：注册中心的作用是帮助客户端来寻址，找到对应 RPC 服务的物理地址；RPC 服务用于接收客户端桩的请求，调用业务服务的方法，并返回结果。

接Simple RPC - 04 从零开始设计一个客户端（上），我们继续分析 依赖倒置和SPI是如何实现的。接口定义了创建桩的方法，而具体的实现类实现了该接口。通过依赖倒置原则（DIP）和SPI机制，我们有效地解耦了调用方与实现类。在这个RPC框架中，接口及其实现类之间的依赖关系被逆转，调用方只依赖接口，而不直接依赖具体实现。SPI机制进一步解耦了调用方与实现类的实例化，使得在运行时可以动态加载实现类，这为框架的扩展性和灵活性提供了强有力的支持。通过这种设计，框架可以很容易地替换。

生成源代码：根据给定的接口定义，生成“桩”类的 Java 源代码。这个类将实现指定接口，并包含将方法调用转化为 RPC 请求的逻辑。动态编译：将生成的源代码编译成字节码（.class 文件），这个过程可以在运行时完成。加载类：将编译生成的字节码加载到 JVM 中，使得生成的类可以在当前应用中使用。

首先定义了对外提供服务的接口。这样，服务的使用者只需要依赖这个接口，而不需要关心其具体实现。这种设计的好处在于，它有效地解耦了接口的使用者和实现者，使我们能够安全地替换接口的实现。通过将接口定义得尽量通用，接口就可以独立于具体的使用场景，从而实现高度的复用性。例如，RPC框架中的网络传输和序列化代码，不仅能在这个框架中使用，甚至可以直接应用到其他系统中，而无需进行修改。在协议设计方面，我们为每个命令设计了一个固定的头部信息。

网络传输和序列化这两部分的功能相对来说是非常通用并且独立的，在设计的时候，只要能做到比较好的抽象，这两部的实现，它的通用性是非常强的。不仅可以用于 RPC 框架中，同样可以直接拿去用于实现消息队列，或者其他需要互相通信的分布式系统中。我们先来实现序列化和反序列化部分，因为后面的部分会用到序列化和反序列化。/*** 计算对象序列化后的长度，主要用于申请存放序列化数据的字节数组* @param entry 待序列化的对象* @return 对象序列化后的长度*//*** 序列化对象。

RPC，全称为Remote Procedure Call（远程过程调用），是一种计算机通信协议，用于允许程序在不同的计算机或网络节点上通过远程方式调用函数或方法。它允许开发者编写分布式应用程序，使得分布在不同位置的计算机能够像本地调用一样进行通信。以下是RPC的主要特点和工作原理：远程过程调用：RPC允许一个程序（客户端）调用另一个程序（服务器）上的函数或方法，就像调用本地函数一样，而无需了解底层网络通信细节。