关于Dubbo的求职经历分享

终于，在小林的努力下，获得了王哥公司那边的offer，但是因为薪水没有谈妥，小林又重新进入了求职的旅途，在经历了多次求职过程之后，小林也大概地对求职的考点掌握地七七八八了，于是这次他重新书写了简历，投递了一家新的互联网企业。

距离面试开始还有大约十分钟，小林已经抵达了面试现场，并开始调整自己的状态。

过了不久，一个稍显消瘦，戴着黑色眼镜框的男人走了过来，估计这家伙就是小林这次的面试官了。

面试官：你好，请简单先做个自我介绍吧。

小林：嗯嗯，面试官你好，我是XXXX（此处省略200个字）

面试官：我看到你的项目里面有提及到dubbo，rpc技术这一技术栈正好和我们这边的匹配，我先问你些关于dubbo和rpc的技术问题吧。首先你能讲解下什么是rpc吗？

小林：好的，rpc技术其实简单地来理解就是不同计算机之间进行远程通信实现数据交互的一种技术手段吧。一个合理的rpc应该要分为server， client， server stub，client stub四个模块部分，

面试官：嗯嗯，你说的server stub，client stub该怎么理解呢？

小林：这个可以通过名字来识别进行理解，client stub就是将服务的请求的参数，请求方法，请求地址通过打包封装给成一个对象统一发送给server端。server stub就是服务端接收到这些参数之后进行拆解得到最终数据的结果。

小林求职记（六）踩过Dubbo坑，回答印象深，干货整理

在以前的单机版架构里面，两个方法进行相互调用的时候都是先通过内存地址查询到对应的方法，然后调用执行，但是分布式环境下不同的进程是可能存在于不同的机器中的，因此在通过原先的寻址方式调用函数就不可行了，这个时候就需要结合网络io的手段来进行服务的”交流“。

面试官：了解，你对rpc本质还是有自己的理解。可以大致讲解下dubbo在工程中启动的时候的一些整体流程吗？

小林：嗯嗯（猛地想起了之前写的一些笔记内容）

在工程进行启动的时候（假设使用spring容器进行bean的托管），首先会将bean注册到spring容器中，然后再将对应的服务注册到zk中，实现对外暴露服务。

面试官：可以说说在源码里面的核心设计吗？假设说某个dubbo服务没有对外暴露成功，你会如何去做分析呢？

小林：嗯嗯。其实可以先通过阅读启动日志进行分析，dubbo的启动顺序并不是直接就进行zk的连接，而是先校验配置文件是否正确，然后是否已经将bean都成功注册到了Spring的ioc容器中，接下来才是连接zk并且将服务进行注册的环节。

小林求职记（六）踩过Dubbo坑，回答印象深，干货整理

如果确保服务的配置无误，那么问题可能就是出在连接zk的过程了。

面试官：嗯嗯，有一定的逻辑依据，挺好的。你有了解过服务暴露的细节点吗？例如说dubbo是如何将自己的服务提供者信息写入到注册中心（zookeeper）的呢？

小林：我在阅读dubbo对外进行服务暴露的源代码时印象中对ServiceConfig这个类比较熟系。在实现对外做服务暴露的时候，这里面的有个加了锁的export函数，内部会先对dubbo的配置进行校验，首先判断是否需要对外暴露，然后是是否需要延迟暴露，如果需要延迟暴露则会通过S