本文会参考 Dubbo 的整体设计思路，手写一个极简版 RPC 框架。

它不会像 Dubbo 那样把协议、注册中心、集群容错、SPI 扩展、线程模型都做得非常完整，但会把 RPC 最核心的一条链路跑通，并且补上一个生产中很重要的能力：熔断降级。

也就是说，本文最后实现出来的效果大概是这样的：

1. 服务提供方通过 RpcServer 暴露接口实现类
2. 服务消费方通过 RpcClient 拿到一个接口代理对象
3. 调用本地接口方法时，底层自动转换成一次网络请求
4. 注册中心负责保存服务名和服务地址的映射关系
5. 客户端通过负载均衡选择一个 Provider
6. 当远程调用持续失败时，熔断器打开，后续请求直接走降级逻辑

什么是Dubbo

Dubbo是一个分布式、高性能、透明化的RPC服务框架，提供服务自动注册、自动发现等高效服务治理方案，可以和Spring框架无缝集成。Dubbo最常用的应用就是远程调用。

Dubbo中服务端最核心的对象有四个：

• ApplicationConfig：配置当前应用信息
• ProtocolConfig：配置提供服务的协议信息
• RegistryConfig：配置注册相关信息
• ServiceConfig：配置暴露的服务信息

高级特性

序列化

• dubbo 内部已经将序列化和反序列化的过程内部封装了，只需要在定义pojo类时实现Serializable接口即可
• 一般会定义一个公共的pojo模块，让生产者和消费者都依赖该模块。

Dubbo 支持的序列化方式对比：

注册模型的改变

在服务注册领域，市面上有两种模型，一种是应用级注册，一种是接口级注册

在Spring Cloud中， 一个应用是一个微服务，而在Dubbo2.7中，一个接口是一个微服务。

所以，Spring Cloud在进行服务注册时，是把应用名以及应用所在服务器的IP地址和应用所绑定的端 口注册到注册中心，相当于key是应用名，value是ip+port，而在Dubbo2.7中，是把接口名以及对应 应用的IP地址和所绑定的端口注册到注册中心，相当于key是接口名，value是ip+port。 所以在Dubbo2.7中，一个应用如果提供了10个Dubbo服务，那么注册中心中就会存储10对 keyvalue，而Spring Cloud就只会存一对keyvalue，所以以Spring Cloud为首的应用级注册是更加适 合的。

Dubbo 调用图解

dubbo的调用图（来自官网），如下图，共包含了5个模块

• Provider 服务提供方

• Registry 服务注册中心（这里可以认为是zookeeper

• Consumer 服务使用方

• Container 服务提供方的容器

• Monitor 服务监控中心

调用过程

dubbo的服务调用方是在xml配置了类似于 <dubbo:reference interface="com.jwfy.dubbo.product.ProductService" id="productService" />的配置，意味着后续在spring中通过 getBean('productService') 就可以获取到远程代理对象。dubbo:reference 本身映射成为的bean是ReferenceBean，其会存储整个dubbo需要的各种信息，例如控制中心的注册地址，服务端的具体IO和端口等。

JDK的SPI机制的缺点

⽂件中的所有类都会被加载且被实例化。这样也就导致获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。如果不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，没有办法指定某⼀个类来加载和实例化，这就造成了浪费。

此时dubbo的SPI可以解决

dubbo的SPI机制

dubbo⾃⼰实现了⼀套SPI机制来解决Java的SPI机制存在的问题。

dubbo中则采用了类似kv对的样式，在具体使用的时候则通过相关想法即可获取，而且获取的文件路径也不一致