典型回答 服务发现是指在Dubbo注册中心中查找提供某个服务的服务提供者，以便服务消费者可以调用它们。 Dubbo的注册中心可以是ZooKeeper、Nacos等，服务提供者在启动时会将自己的地址信息注册到注册中心中，服务消费者在调用服务时会从注册中心中获取服务提供者的地址信息。 服务路由是指根据一定的规则将服务请求路由到指定的服务提供者上。Dubbo提供了多种路由策略，如随机路由、轮询路由、一致性哈希路由等。路由规则可以在Dubbo的配置文件中进行配置，也可以在运行时通过API进行动态修改。 因此，服务发现是获取服务提供者的地址信息，路由则是将服务请求路由到指定的服务提供者上。两者都是Dubbo中非常重要的概念，但是它们的作用是不同的。
典型回答 Dubbo提供了缓存机制，其主要作用是缓存服务调用的响应结果，减少重复调用服务的次数，提高调用性能。 Dubbo支持了服务端结果缓存和客户端结果缓存。 服务端缓存是指将服务端方法的返回结果缓存到内存中，以便下次请求时可以直接从缓存中获取结果，而不必再调用服务方法。服务端缓存可以提高响应速度和系统吞吐量。Dubbo提供了三种服务端缓存的实现方式： LRU Cache: 使用基于LRU(最近最少使用)算法的缓存，当缓存空间满时，会将最近最少使用的缓存清除掉。 Thread Local Cache: 使用线程本地缓存，即每个线程都拥有一个缓存实例，缓存结果只对当前线程可见。 Concurrent Map Cache: 使用基于ConcurrentMap的缓存，支持并发读写，相对LRU Cache和Thread Local Cache来说，缓存效率更高。 客户端缓存是指客户端将调用远程服务方法的返回结果缓存到内存中，以便下次请求时可以直接从缓存中获取结果，而不必再调用远程服务方法。消费端缓存可以提高系统的响应速度和降低系统的负载。Dubbo提供了两种消费端缓存的实现方式： LRU Cache: 使用基于LRU算法的缓存，当缓存空间满时，会将最近最少使用的缓存清除掉。 Thread Local Cache: 使用线程本地缓存，即每个线程都拥有一个缓存实例，缓存结果只对当前线程可见。 需要注意的是，缓存虽好用，使用需谨慎，过度依赖缓存可能会出现数据不一致的问题。 扩展知识 服务端缓存 接口维度的服务端缓存配置方式支持XML和注解两种： XML配置： 1 2 <bean id="demoService" class="org.apache.dubbo.demo.provider.DemoServiceImpl"/> <dubbo:service interface="com.foo.DemoService" ref="demoService" cache="lru" /> 注解配置方式： 1 2 3 4 5 6 7 8 9 10 11 12 @DubboService(cache = "lru") public class DemoServiceImpl implements DemoService { private static final Logger logger = LoggerFactory.getLogger(DemoServiceImpl.class); @Override public String sayHello(String name) { logger.info("Hello " + name + ", request from consumer: " + RpcContext.getContext().getRemoteAddress()); return "Hello " + name; } } 还支持方法维度的缓存配置，同样支持XML和注解两种： ...
典型回答 其实，RPC的设计目的就是用于高效的内部服务通信，他通常优化了数据传输和序列化过程，目的是减少网络延迟和提高性能。而HTTP的设计是一种更通用的协议，用于Web文档传输，它在灵活性和可访问性上进行了优化，而不是仅仅专注于性能。 展开来说主要在以下几个方面，RPC做出了很多事情。 轻量级序列化协议，RPC通常使用更高效的数据序列化格式（如Protocol Buffers、Thrift等），这些格式专门为性能和效率设计，它们比HTTP标准使用的文本格式（如JSON、XML）更紧凑、解析更快。 **网络协议更优，**RPC的网络通信协议通常被设计的更轻量（如Netty），他一般不需要像HTTP那样有很复杂的Header信息，从而不需要传输太多的数据。 长连接，虽然RPC和HTTP都是基于TCP的，但是RPC可以使用长连接和更有效的连接管理策略，如gRPC还是基于HTTP/2实现，这可以减少建立连接的开销，并允许多个请求在同一连接上有效地复用。虽然HTTP/1.1也有keep-alive机制，HTTP/2也有很多优化。但是RPC只在企业内部用，所以兼容性更好，而HTTP新版的普及程度并不太高。 定制优化，RPC框架通常允许更深层次的定制和优化，比如调整底层传输细节、序列化方式和错误处理机制。而HTTP作为一个标准化的Web协议，其灵活性和定制能力可能较低，特别是在面向性能的场景中。 **内部网络，**RPC通常应用于企业内部，内部网络交互链路更短，而HTTP在公网上进行通信，一次交互需要经过多个中间节点的转换。
典型回答 ✅什么是SPI，和API有啥区别 在Java中，SPI（Service Provider Interface）是一个为软件设计的扩展机制，允许第三方为某些接口提供实现。不同的框架和库可能会有不同的SPI机制，如JDK、Dubbo都支持。 他的的主要区别如下： 懒加载 vs 预加载 JDK 的 ServiceLoader 会在使用 ServiceLoader.load() 方法时加载所有可用的服务实现，这是一种预加载方式。 Dubbo 的 SPI 支持懒加载，即只有当实际需要使用服务时，才会加载服务的实现。这可以提高应用启动速度，并减少资源消耗。 扩展点自动激活 JDK 的 SPI 不支持根据条件自动选择和激活具体的实现。 Dubbo 的 SPI 支持扩展点自动激活功能。可以通过键值对的方式在配置文件中指定条件，当满足条件时自动选择对应的实现。 Dubbo的SPI扩展机制之自动激活 扩展点自动装配 JDK 的 SPI 不支持依赖注入，服务提供者需要自己管理依赖或使用其他方式注入依赖。 Dubbo 的 SPI 支持依赖注入。Dubbo 可以自动注入扩展点所需的其他扩展点，使得开发者可以很方便地在一个扩展实现中使用其他扩展服务。 扩展点加载 配置文件的位置和格式 在 JDK 中，服务提供者的配置文件放置在 META-INF/services 目录下，文件名是完整的接口名称，文件内容是实现类的全限定名列表。 在 Dubbo 中，配置文件通常放在 META-INF/dubbo （也可以是其他目录，如 META-INF/dubbo/internal），文件名仍然是接口全名。不过，文件内容可以包含键值对，提供更丰富的配置选项和描述。 AOP 支持 JDK 的 SPI 没有内建的方法来支持面向切面编程（AOP）。 Dubbo 的 SPI 机制支持通过 wrapper 类包装扩展点，从而支持 AOP 风格的服务增强。这可以用于日志记录、事务管理等。 扩展名 Dubbo 允许开发者为服务实现指定一个易于理解的名称（即扩展名），使得配置更加直观和简洁。 所以，相比之下，Dubbo 的 SPI 机制因为支持懒加载，所以性能会更好一些，并且他提供了更加丰富的扩展性和灵活性。并且内置了一些更加强大的功能。 ...
典型回答 Dubbo是支持异步进行调用的，有多种方式，大的方面分为Provider异步调用和Consumer异步调用。 Consumer异步调用 Consumer的异步调用比较容易理解，就是在调用方的地方自己做一个异步的处理。比如使用CompletableFuture来实现。 这种调用中，服务提供者提供的还是一个同步的同步接口，只不过调用方在调用的时候不需要同步等待结果，可以先去做其他事情，在需要用这个结果的时候再获取即可： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 @DubboReference private AsyncService asyncService; @Override public void run(String... args) throws Exception { //consumer异步调用 CompletableFuture<String> future3 = CompletableFuture.supplyAsync(() -> { return asyncService.invoke("invoke call request"); }); future3.whenComplete((v, t) -> { if (t != null) { t.printStackTrace(); } else { System.out.println("AsyncTask Response: " + v); } }); System.out.println("AsyncTask Executed before response return."); } Provider异步调用 还有一种方式就是Provider的异步调用，也就是说本身提供的就是一个异步接口。如： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 @DubboService public class AsyncServiceImpl implements AsyncService { @Override public CompletableFuture<String> asyncInvoke(String param) { // 建议为supplyAsync提供自定义线程池 return CompletableFuture.supplyAsync(() -> { try { // Do something long time = ThreadLocalRandom.current().nextLong(1000); Thread.sleep(time); StringBuilder s = new StringBuilder(); s.append("AsyncService asyncInvoke param:").append(param).append(",sleep:").append(time); return s.toString(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return null; }); } } asyncInvoke方法的返回值就是一个CompletableFuture，调用者在调用这个方法时拿到的也是一个Future，在需要结果的时候调用Future的whenComplete方法即可： ...
典型回答 ✅微服务架构的服务治理有哪些实现方案？ Dubbo 的服务治理 我认为是所有的RPC框架，乃至于所有微服务通信方式中做的最好的了。因为他把能想到的都给做了。具体的在 dubbo的官网中有很多介绍，我挑一些重要的列举一下（没必要死记硬背，大概看一下，有个印象，面试的时候能提出来几个就行了，我自己其实也没有都记住。。。。。。）： 注册中心：Dubbo 支持多种注册中心，例如 ZooKeeper、Consul、Etcd 等。注册中心用于服务的注册与发现，使得服务提供者和消费者可以动态地发现和通信。 负载均衡：Dubbo 提供多种负载均衡策略，如随机、轮询、一致性哈希、最少活跃调用等，用于在服务提供者之间分发请求，保证负载均衡。 集群容错：Dubbo 支持多种集群容错策略，包括 Failover、Failfast、Failsafe、Failback 等，用于处理服务提供者发生故障时的处理逻辑。 服务路由：Dubbo 提供路由规则，可以根据条件对服务进行路由，例如基于 IP、标签、版本等条件。 流量管控：Dubbo 支持非常多的流量管控的规则配置，基于这些规则可以实现在运行期动态的调整服务行为如超时时间、重试次数、限流参数等，通过控制流量分布可以实现 A/B 测试、金丝雀发布、多版本按比例流量分配、条件匹配路由、黑白名单等，提高系统稳定性。 配置管理：Dubbo 支持动态的配置管理，可以通过配置中心实时管理服务的配置信息，例如超时时间、重试次数等。 服务降级：Dubbo 提供服务降级功能，当服务提供者出现异常或性能下降时，可以通过降级策略保证服务的可用性和稳定性。 调用过滤器：Dubbo 提供了调用过滤器机制，可以在服务调用的前后执行一些操作，例如权限控制、日志记录等。 可视化控制台：Dubbo Admin 是 Dubbo 官方提供的可视化 Web 交互控制台，基于 Admin 你可以实时监测集群流量、服务部署状态、排查诊断问题。 服务网格：基于 Dubbo 开发的服务可以透明的接入 Istio 等服务网格体系，Dubbo 支持基于 Envoy 的流量拦截方式，也支持更加轻量的 Proxyless Mesh 部署模式。 安全体系：Dubbo 支持基于 TLS 的 HTTP、HTTP/2、TCP 数据传输通道，并且提供认证、鉴权策略，让开发者实现更细粒度的资源访问控制。
典型回答 ✅Dubbo的SPI和JDK的SPI有什么区别？ 在上面这篇中我们已经介绍过了 Dubbo 的 SPI 和 JDK 的SPI 的机制的区别，但是还是有人问，为啥 Dubbo 不直接用 JDK 的SPI 的机制？ 其实，已经讲过了，只不过不够那么直接，其实不用的原因，就是 JDK 的SPI 存在的那些缺点，我从上文中总结出几个供大家参考： **JDK SPI 机制虽然简单易用，但在灵活性和扩展性上有所不足。**比如说JDK的 SPI 只能加载所有实现类的实例，并不能对实例进行过滤或排序，缺乏对加载顺序、优先级等高级特性的支持。Dubbo 的 SPI 支持扩展点自动激活功能。可以通过键值对的方式在配置文件中指定条件，当满足条件时自动选择对应的实现。 **JDK SPI 机制在加载实现类时会扫描所有的服务提供者配置文件，这会导致性能问题。**特别是在服务提供者较多时，这种扫描和加载机制会带来额外的性能开销。 Dubbo 提供了一种更灵活的依赖注入机制，可以在运行时根据需要注入不同的实现。Dubbo 的扩展机制允许开发者在代码中动态指定和注入扩展点，而不必在编译时确定所有的实现类。这种方式相比 JDK SPI 更加灵活，便于管理和维护。 除此之外，Dubbo 自定义的 SPI 机制还提供了一些高级功能。比如对 AOP 的支持等。