Dubbo在开发中，存在两种开发思路。基于SOA(面向服务的体系架构)思想和辅助SpringCloud架构提升效率。
Dubbo 默认使用 Netty 框架
Dubbo基于SOA思想
正常SpringBoot项目是只有一个启动类，接口定义在web层(即Controller层)中,然后调用Service层。（web层和Service层都处于同一个服务中）
Dubbo基于SOA思想则是有两个启动类，web层在消费者启动类服务中，service层在提供者启动类服务中。整个框架是基于Dubbo进行开发。是一个RPC框架。
provider微服务搭建
使用dubbo协议内有一个netty服务器，所以需要一个对应的端口号。(netty是一个基于NIO的客户、服务器端的编程框架，很多中间件中都用到了netty)
consumer微服务搭建
service-api模块封装
把service接口从消费者以及提供者中提取单独封装在一个模块中，封装后消费者中只有controller，提供者中只有serviceImpl和mapper，service-api中只有service接口和domain。封装后需要在消费者和提供者的pom文件中引用service-api的模块依赖。
dubbo通信
消费者调用提供者接口，当借口返回时返回的是对象(如果返回的是字符串不进行序列化也不会出现错误，因为字符串可以直接转换为二进制进行RPC通信)，对象需要序列化转换成二进制，通过RPC通信传输给消费者，消费者接收到二进制以后通过反序列化得到对象。这一过程中需要domain类实现Serializable接口才能保证接口正常，否则会报错。
Dubbo的高级特性
启动检测
为了保障服务的正常可用，Dubbo缺省会在启动时检查依赖的服务是否可用，不可用会抛出异常。Dubbo默认是开启的，我们可以进行关闭，dubbo.consumer.check=false
我们正常启动顺序是先启动提供者再启动消费者。如果先启动消费者将会报出所依赖的提供者服务不可用异常。在开发阶段，提供者不是我们开发的且不可用，而在消费者开发时又有调用，这时我们可以暂时关闭启动检测功能。
多版本支持
在提供者中定义两个serviceImpl分别是1和2,1为老版本，2为新版本，版本号分别定义在@DubboService(version="1.0.0")和@DubboService(version="2.0.0")，这样提供者即保存了新版本又有了老版本，在消费者中@DubboReference(version="2.0.0")指定新老版本进行发布。这样消费者集群和提供者集群可以选择一部分进行测试，同时也可以确保新版本不可用是老版本还在只需改动消费者就可以使用老版本了。
超时与重试
一般超时时间使用默认的超时时间即可，如果超时时间设置过短，当网络出现波动时，请求就会失败，当然dubbo的重试机制会尽量避免这个问题(失败后dubbo会通过重试机制进行两次重试)，如果此时进行的是添加操作，出现网络波动，从而进行重试会导致添加三条记录。所以尽量不要吧超时时间设置过短。
另外我们可以把重试机制关掉@DubboReference(entries=0)，这个所针对的是单一提供者，我们也可以直接在consumer的配置中配置dubbo.consumer.entries=0，直接把所有的提供者重试机制关闭。
负载均衡
在集群部署时，Dubbo提供了4种负载均衡策略，帮助消费者找到最优提供者进行调用。
- Random按照权重随机：按照权重随机，默认值。按权重设置随机概率。
所有服务提供者的权重总和为10，随机策略会随机消费者的权重(0-10之间)，如果0-2会分配到提供者1中，2-5会分配到提供者2中，5-10则会分配到提供者3中。
- RoundRobin按照权重轮询策略：按照权重轮询
根据消费者的权重进行循环分配，1,2分配到提供者1中，3,4,5分配到提供者2中，6,7,8,9,10分配到提供者3中，1-10依次轮询，然后再循环。
- LeastActive最少活跃度策略：最少活跃调用，相同活跃数的随机。
根据当前每个提供者的调用总数最少的进行调用，相同活跃数的随机调用。
- ConsistentHash一致性Hash策略：一致性Hash，相同参数的请求总是发送到同一提供者。
参数为1的请求发送至服务提供者1中，后续再出现参数为1的请求都发送至服务提供者1中。
负载均衡配置方法：@DubboReference(loadbalance="Random") 只需把对应的英文名字设置进去就可以了。
辅助SpringCloud架构提升效率
Feign是基于Http(应用层)协议。SpringCloud默认使用Feign进行通信。
Dubbo基于TCP(传输层)协议，效率更高。可以替换Feign，提升高并发压力，Dubbo是RPC协议，而RPC协议是属于TCP协议的一种。Dubbo默认通过Netty构建TCP长连接的方式进行通信，性能较高。相当于Socket客户端。
Http协议相当于是对TCP协议的封装。效率低于TCP协议，特别是在高并发的场景下。
