dubbo为分布式服务框架，天生下来就是来构建分布式服务的，dubbo的一大特点就是分层结构，而且层与层之间都可以解耦，方便扩展。dubbo本身也提供了各种各样的功能。对于分布式来说，dubbo的两大特点，集群容错和负载均衡。对于企业级应用来说十分合适。而且dubbo对于项目的配置也十分的简单。对于spring也是无缝连接。
dubbo与spring cloud的对比
对于二者的架构，都是基于提供者，消费者，注册中心的架构模式。
对于二者提供的功能来说，spring cloud更像一个分布式服务平台，它融合了很多组件，来提供各自的功能。对于分布式和微服务这块spring cloud有这更加完备的实现。而dubbo就略差一点了，很多功能都需要自己去扩展，不过对于一般项目而言，dubbo的功能就够用了。
对于采用的传输协议来说，Dubbo使用RPC通讯协议，有多重序列化的方式，对于传输的数据来说，必须实现serizlizable接口。而且使用dubbo也依赖于jar包的interface接口。需要把api包发布到私服上，由各个业务模块服务引用，从这点来说，Dubbo只能依赖于Java。
而对于spring cloud来说，使用rest api，只需要符合JSON就可以了，这点更像前端请求后端的模式。对于服务间的调用，依赖于各个组件，需要进行配置，加上一些注解的方式去实现。调用spring cloud的服务，需要使用实现http协议的工具去调用服务。这点对于不同的平台来说，十分的方便。
从个人学习上来说：认为Dubbo更加的简单，易学，而且对于英语不好的人来说，Dubbo更加的容易上手。而且在项目的配置上面来说，更加的简单。而Spring cloud来说，上手就需要很多了，首先得需要对spring boot的一些内容理解，对各个组件的配置也需要进行学习，Spring cloud在设计方面也更加考验项目负责人的设计能力。以上是被人对于二者的理解，多多指教。
由于项目上最终还是选择了Dubbo。下面就来介绍下Dubbo。
Dubbo的设计是分层的
下面介绍下源码的包模块
dubbo-common公共逻辑模块，主要提供工具类
dubbo-remoting远程通讯模块。相当于Dubbo协议的实现，如果RPC使用RMI协议则不需要使用此包。
dubbo-rpc模块，抽象协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
dubbo-cluster 集群模块，把多个服务提供者包装为一个提供者，包括了负载均衡，集群容错，路由等。集群的地址列表可以是静态配置的，也可以是由注册中心下发。
dubbo-registry 注册中心模块：基于注册中心下发地址的集群方式，以及各种注册中心的抽象。
dubbo-monitor监控模块，统计服务调用次数，调用时间，调用链跟踪的服务。
dubbo-config dubbo对外的API，用户通过Config使用Dubbo,隐藏Dubbo所有的细节。
dubbo-container容器模块，是一个Standlone的容器，以Main加载spring启动。
Dubbo的调用链
1、Dubbo采用spring自定义标签的方式和spring容器集成，再有java动态字节码技术，生成动态代理类。
2、走向第一个Filter,这个过滤器有mock调用，本地调用。
3、走到第一个Invoker,这个Invoker是集群包装的一个Invoker.
4、使用集群容错提供的几种调用机制，在注册中心提供的调用者列表，使用负载均衡策略选出要调用的服务对象
5、根据使用的协议得到调用的服务对象
6、使用netty等通信框架，开始进行数据的传输。
7、使用序列化协议和通信编码等开始访问服务端
8、服务端由线程池来处理消费者的程序，分别有多种线程访问模型。
9、对应消费者，响应的序列化协议，以及传输编码
10、服务端的过滤拦截器，进行统计调用等。
11、获取到动态代理的server业务对象。返回相应的响应给消费端。