java面试-dubbo相关

记录一些面试时被问到有关dubbo的题目，并对此的尝试回答和相关代码demo

代码demo地址

1.你简历里项目使用到的dubbo的版本是多少，对不同版本之前的区别有了解过吗

2.7.5以及3.x
2.7.5对比以前的版本增加了对nacos注册中心的支持以及其余的增强，
3.x【3.0 3.1 3.2】作为目前比较主流的版本，在性能优化的同时也提供了更好的支持

PS：3.0增加了新的协议triple支持，这里可以去了解下

dubbo历史版本对比

2.在原有项目单体转分布式过程中为什么选择了分布式，使用dubbo，而不是选择springcloud

回答这种问题的时候，最好先说出这两种技术选型的区别，如性能差异，然后基于实际情况再回答

在技术选型这方面，我们项目组最开始是有提出过选择springcloud走微服务的想法，但在经过对比评估后，最后决定选择dubbo，主要是基于这几个方面考虑。

首先我们项目团队在其他项目上有过dubbo的使用经验，这可以降低项目落地风险和减少成本，而且社区环境上，springboot+dubbo+nacos也有很多成熟的整合经历，就算出现问题也可以很容易找到解决方案

其次考虑到性能，走springcloud+openfeign通过使用http进行服务调用，对很多非java语言的项目也能有很好的兼容性，但是我们项目组并没有这种需求。这种情况下dubbo基于tcp和更高效的二进制序列化能够给我们带来更好的性能。基于这两个方面考虑，最终我们选择了使用springboot+dubbo+nacos来对旧项目进行改造升级

3.是否有了解过dubbo的spi机制

一种服务发现机制，能够提供强大自定义扩展功能。用户可根据自身需求替换dubbo原生实现，以及新增功能

对比jdk spi，jdk spi会一次性实例化所有实现，比较浪费时间和浪费资源。dubbo的spi机制能够按需加载，自动完成依赖注入，同时增加了aop能力

dubbo spi扩展文档

这里如果没写过建议去自己写一两个有关的activate和adptive的测试例子

我们项目里主要通过spi增加了日志扩展，收集服务调用的详细日志

4.dubbo在服务调用时的具体链路流程有没有了解过

简单来说就是消费者调用方法，实际调用的是dubbo的动态代理，这时候dubbo会根据注册中心获取到的服务实例列表，根据路由规则/负载均衡选中其中一个服务实例，然后就到了过滤器链的执行部分，中间执行调用链后，就是封装，序列化，发起请求到服务提供者。
服务提供者收到请求，先会到线程池，分发线程，然后通过反射找到真实方法进行调用，前后会经过服务端的过滤器链，最后再封装结果返回

参考，具体请看第四部分

5.如果我要在服务调用间传递用户id或者token，可以怎么实现

利用dubbo的spi机制，consumer端增加增加过滤器，调用服务前查出用户id/token并注入当前请求的attachment内。provider端增加过滤器，拿出token并存入当前线程上下文内。

这套方案同理也可以用来做服务调用幂等性判断
案例参考

PS：多个扩展过滤器情况下，考虑使用order设置执行顺序。

6.在使用dubbo后，有没有遇到过一些问题，具体又是怎么发现和解决呢

这个问题可以先提出一个生产遇到过的问题，然后按先说问题详情，再说如何定位，最后到如何解决来回答

如果没有问题可以找一下网上的一些比较常见的故障，这里我提一些容易遇到的问题，如调用服务时由于更新超时导致dubbo重试引起重复插入

在单体项目改造为springboot+dubbo的分布式架构后，我们遇到过在服务调用时由于被调用的服务时间超时，但实际能够正常运行，导致dubbo发起重试，进而重复更新/插入数据的情况。

在遇到这种情况后，我们先定位到具体发生的服务接口，然后排查是哪个部分的耗时过长，如果是代码逻辑上的耗时，就尝试利用多线程来减少时间，如果是数据库查询的问题，就分析sql语句进行调优。再者就是对这一个服务接口根据实际情况单独配置超时时间和重试次数，同时对对应接口做幂等判断，防止重复插入/修改。

下面这个例子也可以看看，
简单说就是下游依赖服务偶发超时，但是下游服务的业务日志显示业务运行正常，没有存在耗时超时情况。
背景：内部扩展了一个日志filter，记录dubbo的调用记录
排查过程就是先通过链路追踪工具找到对应服务调用位置，发现filter的日志里的处理时间和下游业务日志的耗时时间对不上。通过两者进一步缩小排查范围
偶发超时排查

7.dubbo服务间调用你们使用哪种序列化协议，为什么选择它，有没有遇到过序列化性能的问题吗

我们项目里这部分并没有做额外的调整，使用的是默认的hessian2序列化协议，默认协议在性能和跨语言兼容性都不错。如果想要更好的性能，可以考虑用kryo，但是kryo针对的是java生态。

PS：这里可以在说的时候考虑扩展到dubbo3新增的协议（注意这不是序列化协议）triple

8.对dubbo的集群容错有没有了解

dubbo的集群容错机制有 失败重试，失败切换，失败快速失败，失败安全，广播调用几种。

这里的触发是不包含业务异常的，只有在如dubbo调用超时之类的才会触发容错机制

1. 失败重试是默认策略，失败后会尝试切换到其他服务器进行重试，常用于读操作
2. 失败切换，当调用失败后，会记录请求定时重发，常用于消息通知
3. 失败快速失败，只发起1次调用，失败立即报错，通常用在非幂等性的写操作
4. 失败安全，调用失败时直接忽略
5. 广播，向所有提供者进行调用，有一个失败就失败