Dubbo总结

1.什么是 RPC?

RPC 就是 Remote Procedure Call，远程过程调用，它相对应的是本地过程调用。

2.RPC和HTTP有什么区别？

• RPC 和 HTTP 不是一个层级的东西
• HTTP 只是传输协议，协议只是规范了一定的交流格式。
• RPC 对比的是本地过程调用，是用来作为分布式系统之间的通信，它可以用 HTTP 来传输，也可以基于 TCP 自定义协议传输。
• HTTP 协议比较冗余，所以 RPC 大多都是基于 TCP 自定义协议，定制化的才是最适合自己的。

3.说说你对 Dubbo 的了解

dubbo架构

• Consumer：需要调用远程服务的服务消费方
• Registry：注册中心
• Provider：服务提供方
• Container：服务运行的容器
• Monitor：监控中心
  首先服务提供者 Provider 启动然后向注册中心注册自己所能提供的服务。
  服务消费者 Consumer 启动向注册中心订阅自己所需的服务。然后注册中心将提供者元信息通知给 Consumer，之后 Consumer 因为已经从注册中心获取提供者的地址，因此可以通过负载均衡选择一个 Provider 直接调用 。
  之后服务提供方元数据变更的话注册中心会把变更推送给服务消费者。
  服务提供者和消费者都会在内存中记录着调用的次数和时间，然后定时的发送统计数据到监控中心。

4.说说Dubbo服务暴露的流程

服务暴露流程

服务的暴露起始于 Spring IOC 容器刷新完毕之后，会根据配置参数组装成 URL， 然后根据 URL 的参数来进行本地或者远程调用。
会通过 proxyFactory的getInvoker方法，利用 javassist 来进行动态代理，封装真正的实现类，然后再通过 URL 参数选择对应的协议来进行 protocol.export，默认是 Dubbo 协议。
在第一次暴露的时候会调用 createServer 来创建 Server，默认是 NettyServer。
然后将 export 得到的 exporter 存入一个 Map 中，供之后的远程调用查找，然后会向注册中心注册提供者的信息。

5.说说Dubbo服务引入的流程

服务引入流程

服务的引入时机有两种，第一种是饿汉式，第二种是懒汉式。
饿汉式就是加载完毕就会引入，懒汉式是只有当这个服务被注入到其他类中时启动引入流程，默认是懒汉式。
会先根据配置参数组装成 URL ，一般而言我们都会配置注册中心，所以会构建 RegistryDirectory向注册中心注册消费者的信息，并且订阅提供者、配置、路由等节点。
得知提供者的信息之后会进行Dubbo 协议的引入，创建 Invoker，最后通过 Cluster 来包装 Invoker，最终返回代理类。

6.Dubbo服务调用的流程是什么？

调用某个接口的方法会调用之前生成的代理类，然后会从 cluster 中经过路由的过滤、负载均衡机制选择一个 invoker 发起远程调用，此时会记录此请求和请求的 ID 等待服务端的响应。
服务端接受请求之后会通过参数找到之前暴露存储的 map，得到相应的 exporter ，然后最终调用真正的实现类，再组装好结果返回，这个响应会带上之前请求的 ID。
消费者收到这个响应之后会通过 ID 去找之前记录的请求，然后找到请求之后将响应塞到对应的 Future 中，唤醒等待的线程，最后消费者得到响应，一个流程完毕。

7.知道什么是 SPI 吗？

SPI 是 Service Provider Interface，主要用于框架中，框架定义好接口，不同的使用者有不同的需求，因此需要有不同的实现，而 SPI 就通过定义一个特定的位置，Java SPI 约定在 Classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件，然后文件里面记录的是此 jar 包提供的具体实现类的全限定名。
所以就可以通过接口找到对应的文件，获取具体的实现类然后加载即可，做到了灵活的替换具体的实现类。

8.为什么 Dubbo 不用 JDK 的 SPI，而是要自己实现?

因为 Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化，假设一个实现类初始化过程比较消耗资源且耗时，但是你的代码里面又用不上它，这就产生了资源的浪费。
因此 Dubbo 就自己实现了一个 SPI，给每个实现类配了个名字，通过名字去文件里面找到对应的实现类全限定名然后加载实例化，按需加载。

9.Dubbo 为什么默认用 Javassist？

快，且字节码生成方便。

10.如果让你设计一个 RPC 框架，如何设计？

• 首先需要实现高性能的网络传输，可以用 Netty，不用自己重复造轮子，然后需要自定义协议，毕竟远程交互都需要遵循一定的协议，然后还需要定义好序列化协议，网络的传输毕竟都是二进制流传输的。
• 然后可以搞一套描述服务的语言，即 IDL（Interface description language），让所有的服务都用 IDL 定义，再由框架转换为特定编程语言的接口，这样就能跨语言了。
• 此时最基本的功能已经有了，但是只是最基础的，工业级的话首先得易用，所以框架需要把上述的细节对使用者进行屏蔽，让他们感觉不到本地调用和远程调用的区别，所以需要代理实现。
• 然后还需要实现集群功能，因此需要服务发现、注册等功能，所以需要一个注册中心。
• 最后还需要一个完善的监控机制，统计调用情况等等，方便运维。
• 这样一个 RPC 框架的雏形就差不多了。

（本文总结自个人很喜欢的一个作者敖丙的文章，为了方便自己学习特地简化了一些描述，在此感谢敖丙dalao）