li12412414的博客

Dubbo Filter 的入口是ProtocolFilterWrapper。ProtocolFilterWrapper 实现了 Protocol 接口。当调用ExtensionLoader的getExtension方法时，会做拦截处理，如果存在封装器，则返回封装器实现，而将真实实现通过构造方法注入到封装器中。举个简单的例子，当获取DubboProtocol的时候，会先经过ProtocolFilterWrapper进行包装。

Service provider interface 的简写，翻译成中文就是服务提供发现接口。不过这里不要被这个名词搞混了，这里的服务发现和我们常听到的微服务中的服务发现并不能划等号。就如同对一个接口的多种实现方式 A、B、C（可以把它们理解为服务），我需要在运行时知道应该使用哪一种具体的实现。其实本质上来说这就是一种典型的面向接口编程，这一点在我们刚开始学习编程的时候就被反复强调了。

在 Dubbo 中，很多拓展都是通过 SPI 机制进行加载的，比如 Protocol、Cluster、LoadBalance 等。有时，有些拓展并不想在框架启动阶段被加载，而是希望在拓展方法被调用时，根据运行时参数进行加载。这听起来有些矛盾。拓展未被加载，那么拓展方法就无法被调用（静态方法除外）。拓展方法未被调用，拓展就无法被加载。对于这个矛盾的问题，Dubbo 通过自适应拓展机制很好的解决了。

Dubbo 服务调用过程比较复杂，包含众多步骤，比如发送请求、编解码、服务降级、过滤器链处理、序列化、线程派发以及响应请求等步骤。

本篇文章详细分析 Dubbo 服务导出过程，包括配置检测，URL 组装，Invoker 创建过程、导出服务以及注册，服务等等。

在使用Dubbo进行系统间的调用的时候，我们有时候可能会遇到这样的问题:服务提供者抛出了自定义的业务异常，但是服务消费者接收到的却是RunTimeException。这是为什么呢？这就得从Dubbo的ExceptionFilter说起。

场景一：我们要搭建一个统一的测试平台，可以让各个业务方在测试平台中通过输入接口、分组名、方法名以及参数值，在线测试自己发布的 RPC 服务。这时我们就有一个问题要解决，我们搭建统一的测试平台实际上是作为各个 RPC 服务的调用端，而在 RPC 框架的使用中，调用端是需要依赖服务提供方提供的接口 API 的，而统一测试平台不可能依赖所有服务提供方的接口 API。我们不能因为每有一个新的服务发布，就去修改平台的代码以及重新上线。这时我们就需要让调用端在没有服务提供方提供接口的情况下，仍然可以正常地发起 RPC

RPC 是解决分布式系统通信问题的一大利器，而分布式系统的一大特点就是高并发，所以说 RPC 也会面临高并发的场景。在这样的情况下，我们提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题，比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中，我们要保证服务的稳定性和高可用性，这时我们就需要业务进行自我保护，从而保证在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。

集群调用失败时，Dubbo 提供的容错方案。在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。

实现一个简单的RPC远程过程调用(附源码)。

当Dubbo服务提供方要上线的时候，一般是通过部署系统完成实例重启。在这个过程中，服务提供方的团队并不会事先告诉调用方他们需要操作哪些机器，从而让调用方去事先切走流量。而对调用方来说，它也无法预测到服务提供方要对哪些机器重启上线，因此负载均衡就有可能把要正在重启的机器选出来，这样就会导致把请求发送到正在重启中的机器里面，从而导致调用方不能拿到正确的响应结果。因此要设置优雅关闭，避免响应异常问题。

Dubbo启动预热，简单来说，就是让刚启动的服务提供方应用不承担全部的流量，而是让它被调用的次数随着时间的移动慢慢增加，最终让流量缓和地增加到跟已经运行一段时间后的水平一样。