作为微服务里面的另外一大派系 Dubbo ，使用也是蛮多的，很多时候面试也会考到。
前言
平常我们在构建分布式系统的时候，一般都是基于 Dubbo 技术栈或者是 SpringCloud 技术栈来做。
早期其实最先比较流行的是 Dubbo，我记得我们当时有个部分的老大就是用的是 Dubbo 来构建的一个系统，到后面才出来的 SpringCloud，由于它是基于 Spring 生态建立起来的，提供了一整套微服务组件，功能齐全，大受中小型公司开发者的青睐。
但是现在还是有不少公司没有换成 SpringCloud 来做微服务的东西，还是基于 Dubbo，面试的时候不管是 SpringCloud 也好，Dubbo 也罢，基本上都会提到这两个框架的底层原理。你想尝试一下高级的职位，基本上跑不脱这个问题。
OK，今儿我们就大概聊聊 Dubbo 的底层架构原理吧。
服务注册中心
分布式系统里面这个是必备的，服务提供者跟服务消费者都在启动的时候都会注册到服务注册中心来。服务注册中心会记录。
动态代理层 Proxy
通常这些框架大多数采用的思想都是通过对你的方法，接口生成一个代理对象，然后在这个代理对象里面去写它的功能。
所以这里我们需要每个服务都需要提供接口出来，在发起服务调用执勤，会创建一个动态代理对象，在我们的消费者中只有一个接口，我们可以认为动态代理类相当于为这个接口动态的创建一个实体类出来，然后用动态带来对象进行接口调用。
Cluster 集群层
我们准备好了要去调用了远程服务的接口，那么现在问题是我们的服务提供者会部署多台机器，那么我们到底去调用哪台机器呢？怎么选择？
此时动态代理对象回去找一个叫 Cluster 这层的东西，这层就负责具体要调用哪一台机器。
那么 Cluster 层就必须得拿到有哪些机器对不对，不然怎么选呢。那么这个过程就叫做动态感知。
Cluster 里面有很多组件，比如 Directory、Router 还有LoadBalance ，此时就会使用负载均衡组件 LoadBlance 挑选一台机器。到这里，机器就选好了。
protocol 协议层
这层主要就是选择一种协议来组织我们的请求。
Dubbo支持的协议很多，包括：dubbo、rmi、hessian、http、
webservice、thrift、memcached、redis等。默认使用 dubbo 协议。
Exchange 信息交换层
这层最主要的目的就是把我们的请求数据包装成 Request 或者 Response 。
Transport 网络通信层
现在我们挑选好了机器，也把请求按照协议进行组织好了，并且封装好了请求。那么这个请求怎么发送到服务提供者的哪台机器呢？
此时我们就需要选择一个网络通信的框架。由他来负责把你的请求通过网络发送过去。比如比较常见的 netty、mina 等。
在发送过去之前，还得对请求进行序列化。序列化有多种方式可以选择，比如Json、Protobuf、Protostuff、Hessian、Kryo等、Java序列化等等。
服务消费者接受到请求后的处理
那么服务提供者怎么才能收到这个请求呢？此时服务提供者里面也得需要一个网络通信框架，他去监听你开放的某个端口，比如就启动一个 netty 去监听消费者发送过来的请求。
接受到请求过后，然后进行反序列化，然后，前面我们发过来的是 通过 Exchange 层包装的 Request 请求，那么这里也需要 这层来对 请求进行解析。解析的时候，也需要根据一种协议来进行解析。
实际上 解析完成请求以后，还会创建一个动态代理对象，再去调用我们的服务提供者接口，最后返回数据。
整个调用流程图
希望你在面试的时候，能够给面试官画出来这个图。
可能面试的时候还会有更多的细节，那么根据上面大体的几层，一层一层的了解各自的细节。这样子可能会更有把握一些。
把上面的图了解了，再去看官方的，我认为会更好一些。
参考资料：
dubbo 中文文档：
http://dubbo.apache.org/zh-cn/docs/user/quick-start.html
Dubbo 实现原理及架构详解：
http://crazyfzw.github.io/2018/06/10/dubbo-architecture/[1]。
References
[1] http://crazyfzw.github.io/2018/06/10/dubbo-architecture/: http://crazyfzw.github.io/2018/06/10/dubbo-architecture
- END -
