dubbo面试题

   dubbo面试遇到的问题，欢迎参考

1、dubbo中"读接口"和"写接口"有什么区别

2、谈谈dubbo中的负载均衡算法及特点？

3、最小活跃数算法中是如何统计这个活跃数的？

4、简单谈谈你对一致性哈希算法的认识？

5、服务发布过程中做了哪些事？

6、dubbo都有哪些协议,他们之间有什么特点,缺省值是什么？

7、什么是本地暴露和远程暴露,他们的区别？

8、服务提供者能实现失效踢出是根据什么原理

9、讲讲dubbo服务暴露中本地暴露,并画图辅助说明？

10、一般选择什么注册中心,还有别的选择吗

11、dubbo中zookeeper做注册中心,如果注册中心集群都挂掉,那发布者和订阅者还能通信吗

12、项目中有使用过多线程吗有的话讲讲你在哪里用到了多线程

13、zookeeper的java客户端你使用过哪些

14、服务提供者能实现失效踢出是什么原理？

15、zookeeper的有哪些节点,他们有什么区别讲一下应用场景。

16、画一画服务注册与发现的流程图。

17、在dubbo中,什么时候更新本地的zookeeper信息缓存文件订阅zookeeper信息的整体过程是怎么样的

18、既然你们项目用到了dubbo,那你讲讲你们是怎么通过dubbo实现服务降级的,降级的方式有哪些,又有什么区别

19、dubbo监控平台能够动态改变接口的一些设置,其原理是怎样的

20、既然你说你看过dubbo源码,那讲一下有没有遇到过什么坑(区分度高,也是检验是否看过源码的试金石)

21、dubbo的原理是怎么样的请简单谈谈

22、有没有考虑过自己实现一个类似dubbo的RPC框架,如果有,请问你会如果着手实现(面试高频题,区分度高)

23、你说你用过mybatis,那你知道Mapper接口的原理吗(如果回答得不错,并且提到动态代理这个关键词会继续往下问,那这个动态代理又是如何通过依赖注入到Mapper接口的呢)

24、描述一下dubbo服务引用的过程,原理

25、既然你提到了dubbo的服务引用中封装通信细节是用到了动态代理,那请问创建动态代理常用的方式有哪些,他们又有什么区别dubbo中用的是哪一种(高频题)

26、除了JDK动态代理和CGLIB动态代理外,还知不知道其他实现代理的方式(区分度高)

27、你是否了解spi,讲一讲什么是spi,为什么要使用spi

28、对类加载机制了解吗,说一下什么是双亲委托模式,他有什么弊端,这个弊端有没有什么我们熟悉的案例,解决这个弊端的原理又是怎么样的

29、既然你对spi有一定了解,那么dubbo的spi和jdk的spi有区别吗有的话,究竟有什么区别

30、你提到了dubbo中spi也增加了IoC,那你先讲讲Spring的IoC,然后再讲讲dubbo里面又是怎么做的？

31、你提到了dubbo中spi也增加了AOP,那你讲讲这用到了什么设计模式,dubbo又是如何做的？

Java开发需要掌握以下技术：1、掌握Java语言的使用：语言语法、程序逻辑，OOP（面向对象）思想，封装、继承、多态，集合框架、泛型、File I\O技术，多线程技术、socket网络编程，XML技术。编程有关的 *** 作系统基本使用，HTML5规范、HTML5文档结构、HTML5元素、Web语义化；CSS3规范、CSS3选择器、层叠与继承、盒模型与视觉格式化模型、现代CSS布局、CSS3基本属性千锋教育就有线上免费Java线上公开课。 2、掌握Java Web开发技术：Java开发中使用到的Web前端技术，HTML5+CSS3，JavaScript *** 作BOM和DOM，JQuery的选择器、事件处理、动画效果，MySQL数据库技术，JDBC技术、JSP、Servlet、EL和JSTL、过滤器和监听器、AJax异步请求等，Linux技术、SVN、Linux环境下项目发布部署等。3、掌握使用流行框架SSM\SSH技术实现企业级项目开发：重点学习MyBatis、Spring、Spring MVC框架的应用，Git、Java设计模式等，重点学习Struts2 、Spring、Hibernate框架的应用，Maven、Oracle数据库应用技术，了解大数据生态体系，Hadoop基础入门。4、JavaWeb框架：Spring体系结构、Spring IOC、AOP、FactoryBean与BeanFactory、声明性事务处理、Spring 5新特性。Maven与Gradle的使用。Spring Boot自动配置、Spring Boot CLI与Initializr、Spring Boot Starter、Actuator。SpringMVC工作原理和工作流程；拦截器、数据绑定转换和格式化、全局异常处理、转发与重定向、AJAX请求处理。如果想了解更多相关知识，建议到千锋教育了解一下。千锋教育总部位于北京，已在18个城市成立分公司，现有教研讲师团队300余人，每年培养泛IT人才近2万人，十年间累计培养超10余万泛IT人才 。

Dubbo的注册中心承担着Dubbo服务的注册与发现的功能。

Dubbo支持的注册中心主要包括：

其中dubbo官方推荐用Zookeeper作为注册中心，下面介绍 ZookeeperRegistry 。

Dubbo在Registry层实现服务的注册于发现，主要包括如下几个类：

流程说明 ：

RegistryProtocol 是对需要暴露服务到注册中心的一层封装，通过 RegistryProtocol 实现将暴露的服务信息注册到注册中心。

ZookeeperRegistry 是通过 ZookeeperRegistryFactory 创建。

说明：

上面是 AbstractRegistryFactory#getRegistry 方法根据URL获取对应注册中心，真正的创建在子类的 createRegistry 方法中实现。

注意 ：

ZookeeperTransporter 才是真正与Zookeeper通信的对象。默认的Zookeeper客户端是curator。

ZookeeperRegistry 在创建时便和Zookeeper创建了连接。

Zookeeper的服务注册就是创建Zookeeper的节点。

根据url对象构建一个URL的 Path ，然后在Zookeeper上创建一个节点，节点是否是持久化的根据 dynamic 参数决定， true 表示创建一个持久化节点，当注册方下线时，持久化节点仍然在Zookeeper上。 false 表示创建临时节点，当注册方下线时，会删除节点，同时通知监听节点的消费方。

Zookeeper中的服务节点路径如 Group/ServiceInterface/category/URL ：

服务下线就是把注册的节点进行删除。

订阅有两种方式pull、push ，pull是客户端定时轮询注册中心拉取配置，push是注册中心主动推送数据给客户端。dubbo是两者结合的方式进行配置的拉取，当第一次启动的时候通过客户端pull拉取 所有数据 方式，在订阅的节点上进行注册watcher，然后客户端与注册中心保持长连接，而后 每个节点有任何数据变化，注册中心就会更新watcher情况进行回调通知到客户端，客户端就接收到这个通知了。

服务在进行注册的时候，服务端会订阅configurators用来监听动态配置的变更。

在消费者启动的时候，消费者会监听providers、routers、configurators来监听服务提供者、路由规则、配置变更的通知。

取消订阅就是删除监听器。

当与zookeeper重新连接时，需要刷新本机生产者列表，这个方法就是干这个的，它把的已订阅的列表都加入订阅失败的容器。

注意 ：

addFailedSubscribed 方法是 FailbackRegistry 将订阅失败的连接放入失败容器， FailbackRegistry 有定时器会定时的处理这些失败的订阅。

通知事件是调用的 AbstractRegistry#notify 方法完成。

流程说明 ：

RegistryDirectory#notify 就是更新本地缓存。

注意 ：

file在 AbstractRegistry 对象创建的时候初始化。

这使用了文件锁的方式保证只有一个在读写文件。

消费者从注册中心获取注册信息后会做本地缓存。内存中也有一份，保存在 Properties 对象里，磁盘上也持久化一份，通过file对象进行引用。

最近一直在看dubbo的源码部分。在阅读的时候，需要有一个入手点，才能一点一点的进行下去。自己在研究的时候，发现思绪比较乱，于是就以 芋道源码 为基础，一点一点的啃食。芋道源码是直接从dubbo的配置和一些核心的API开始讲起，是从dubbo已经启动的过程作为开始节点，而这些核心 API 与 Spring 的之间的关系被省略了，这些东西对我来说属于前置的知识点，所以花了比较长的时间又从 Dubbo 的核心 API 倒着往前看。

在阅读 Dubbo 时，发现前置知识越来越多，如：Spring 的 refresh 中的一些核心点，Spring 中 bean 的生命周期，BeanFactory 与 FactoryBean 的区别等。所以这些前置知识花了特别多的时间去补。所幸，虽然补前置知识虽然时间长，但是性价比还是可以的。Dubbo 是依赖于Spring 的上下文环境的框架，其他依赖于 Spring 的框架也是相同的道理。Spring 的一些对外的扩展点，读过之后也会心中有数。

1、本篇主要是描述了 Dubbo 在 Spring 创建上下文的时候，是如何从创建，到能完整提供一个RPC调用能力的一些相关点。
2、由于源码比较多，直接贴断点也太过臃肿，所以仅仅贴一些关键点来概括整个流程。
3、本文是依赖于前面的 dubbo 项目进行断点分析，项目结构可以参照这里。项目中 dubbo 的配置方式是 xml 文件，所以本篇主要说 xml 配置方式。其他方式道理相同，并不是问题的关键点。

4、项目启动的是 dubbo-user 服务，所以 UserService 为 dubbo:service，OrderService 为 dubbo:reference。

下图为Spring 启动时是如何加载 Dubbo 的，其中省略了大量过程，只保留了一些关键节点，省略的部分可以略微脑补一下。

整个流程的入口是 Spring 的 refresh 方法。每个方法都有比较深的调用栈。与 Dubbo 有关的入口是 refresh 中的 invokeBeanFactoryPostProcessors 方法

这个方法是执行 beanFactory 的一些后处理 *** 作，其核心流程为在Spring容器中找出实现了BeanFactoryPostProcessor接口的processor并执行。Spring容器会委托给PostProcessorRegistrationDelegate的invokeBeanFactoryPostProcessors方法执行。
ConfigurationClassPostProcessor 是比较核心的类，在这里我们关注一下这个类。它的作用是对项目中配置的类进行处理。具体处理可以分为几步：

在加载类信息时，spring 会去用各种方式扫到注册的 bean 信息。我们在 spring 中注册的 bean，逃不出这个方法的扫描方式。 核心方法是:

扫描之后，会将扫描到的 bean 注册到 beanDefinitionMap 中

首先是此处 orgspringframeworkbeansfactoryxmlDefaultBeanDefinitionDocumentReader#parseBeanDefinitions，可以看出方法会以配置文件根节点起，遍历所有子节点。

其次是这里 orgspringframeworkbeansfactoryxmlBeanDefinitionParserDelegate#parseCustomElement(orgw3cdomElement, orgspringframeworkbeansfactoryconfigBeanDefinition)， 此方法会通过解析出来的节点，获取对应的 Spring 的 namespaceUri ，进而获取对应的配置文件处理器。
此处 ele 参数实际值为 <dubbo:service />，namespaceUri 为 >个人觉的两者都不会被淘汰，但是在未来分布式微服务解决方案中或者架构中，springCloud会占主导地位。

springCloud：

1springCloud提供了完成的分布式解决方案，基础解决方案以及组件比较健全，而且最近几年围绕springCloud边缘服务组件越来越多，例如：nacos。

2springCloud是基于springboot的，spring的使用部署太方便了。

dubbo：

1dubbo更多解决的是服务间的调用，也就是服务通讯协议rpc，也会是dubbo没有完整的分布式解决方案基础设施。例如：注册中心需要借助Zookeper，链路追踪：zipkin。

要说Dubbo，算是Spring Cloud的一个子集好了,大致相当于Spring Cloud里的 Eureka + Feign + 1/2Hystrix另外

现在大公司也在慢慢想springCloud服务过度，还有面试中文springCloud问题越来阅读，dubbo越来越少。

dubbo生态圈没有spring cloud好，会被先淘汰掉。现有架构都会优先选择Spring cloud，毕竟使用起来更简单一点。

微服务现在是一阵风而已，实际来说，很多系统不适用，综合算下来，微服务成本比原来大多了。不是所有系统都是互联网，都是d缩性很强。有的系统就是固定数据量，稳定运行，可能几个大一点服务器就足够了。

真正需要微服务的不会像现在看到的那么多。

慢慢沉淀，估计会把一些不需要的改回去，套壳的改回去。

如果简化方式，感觉dubbo这种轻便的有优势，开发运维都简单。或者替代品也是轻便为主。

剩的可能真的需要微服务，一般都是中等规模以上的，或者巨头，一般都有自己的内部框架。这种用也得全套完善的。

它们都淘汰也是早晚的事[捂脸]毕竟是java闭源。随着service mesh的兴起，isito的落地并于k8s的无缝融合，一切像基础设施下沉[呲牙]

事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。

以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式：

第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。

第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。

第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。

第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，信贷系统，核心系统等。

因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。

个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。

分层是计算机科学永恒的主题，service mesh是微服务的未来，这样看来这两个以后都会被取代，只有spring boot能够继续存活。

这是两个作用和使用场景不同的框架，目前的情况来看都不会被淘汰。

springcloud用于微服务，dubbo用于服务治理，各有各的适用场景。

在国外springcloud使用的多，在国内dubbo使用的多。

springcloud由国外的spring团队开发维护，热度和可靠性不用多说，dubbo由国内的阿里巴巴开发，现交由Apache孵化器，可靠性也很高。

Spring cloud是当前主流的微服务架构，轻便，插件式的设计理念很赢得当前开发及企业的青睐，在很多方面优于dubbo的架构设计，我认为dubbo最终会被淘汰，但短时间内不会，因为很多金融机构之前很多系统用的是dubbo架构，金融机构在短时间内考虑系统和业务的稳定性不会立刻就更新换代

dubbo

对内rpc，对外>微服务架构已成为目前互联网架构的趋势，关于微服务的讨论，几乎占据了各种技术大会的绝大多数版面。国内使用最多的服务治理框架非阿里开源的 dubbo 莫属，千米网也选择了 dubbo 作为微服务治理框架。另一方面，和大多数互联网公司一样，千米的开发语言是多样的，大多数后端业务由 java 支撑，而每个业务线有各自开发语言的选择权，便出现了 nodejs，python，go 多语言调用的问题。

跨语言调用是一个很大的话题，也是一个很有挑战的技术活，目前业界经常被提及的解决方案有如下几种，不妨拿出来老生常谈一番：

当我们再聊跨语言调用时我们在聊什么？纵观上述几个较为通用，成熟的解决方案，可以得出结论：解决跨语言调用的思路无非是两种：

如果一个新型的团队面临技术选型，我认为上述的方案都可以纳入参考，可考虑到遗留系统的兼容性问题

旧系统的迁移成本

这也关键的选型因素。我们做出的第一个尝试，便是在 RPC 协议上下功夫。

通用协议的跨语言支持

springmvc的美好时代

springmvc

springmvc

在没有实现真正的跨语言调用之前，想要实现“跨语言”大多数方案是使用 >