Dubbo官方地址：https://dubbo.apache.org/zh/docs/quick-start/
Dubbo是什么？Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，并提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
简单来说就是一个管理微服务的框架，只有在分布式框架的时候才会使用，本质上就是一个做服务调用的框架，告别Web Service模式中的WSdl，以服务者与消费者的方式通过Dubbo进行调用注册。
RPC：全称Remote Procedure Call, 即远程过程调用；主要作用是屏蔽网络编程细节，实现调用远程方法就像调用本地方法（同一个进程中的方法）一样的体验。同时屏蔽底层网络通信的复杂性，让我们更加专注业务逻辑的开发。
SOA：是一种思想，一种方法论，一种分布式的服务架构，解决了多服务凌乱问题，SOA架构解决数据服务的复杂程度，同时SOA又有一个名字，叫做服务治理。
Dubbo的流程Provider：服务提供者
Register：注册中心(Eureka、Consul、Zookeeper)
Consumer：消费者，调用服务方
Monitor：监控，Provider和Consumer 用异步的方式发送信息至Monitor，可以将服务调用信息保存至本地，需要单独配置，若果宕机不会影响服务调用
调用顺序：
- 首先启动注册中心。
- 启动服务提供者，服务提供者将自身的ip、端口以及暴露的接口注册到注册中心（如果发生更改将会在将信息自动注册到注册中心）。
- 启动服务消费者，消费者将自身的信息注册到注册中心（通过配置可关闭）同时拉取提供者的信息进行保存，（如果提供者的信息发生改变，注册中心将会通知消费者进行更改）
- 消费者在拿到提供者的信息之后，如果需要调用接口，将不通过注册中心直接调用提供者。
- 消费者和提供者通过异步的方式发送消息至Monitor，Consumer和Provider会将信息存放在本地磁盘，平均1min会发送一次信息。
Dubbo源码地址： git clone https://github.com/apache/dubbo.git
Dubbo支持多种开发模式：xml，注解，与SpringBoot整合
SpringBoot 整合模式 服务提供者- 需要引入spring boot dubbo 启动器
org.apache.dubbo dubbo-spring-boot-starter 2.7.8 org.apache.dubbo dubbo
- 需要在配置类中标明注册中心的地址、服务的通信方式、Dubbo对外暴露的端口号、以及需要扫描的包名
dubbo:
scan:
# 包名根据自己的实际情况写
base-packages: com.dubbo.service
protocol:
# 用于消费者调用的端口号
port: 20880
# 消费者调用的通信协议
name: dubbo
registry:
#zookeeper注册中心地址
address: zookeeper://192.168.0.107:*
- 将需要对外暴露的接口实现类加上注解@DubboService
// 该实现类的方法将对外提供
@DubboService
public OrderServiceImpl implements OrderService {
}
服务消费者
-
pom 以及 yml 文件配置和服务提供者的相同。
-
在远程调用时需要在调用的接口上使用注解@DubboReference
@Controller
public class OrderController {
// 该接口将使用远程调用
@DubboReference
private OrderService orderService;
public String getOrder (Long orderId) {
orderService.getOrderById(orderId);
}
}
配置的优先级
- jvm 启动配置
-Ddubbo.timeout=4000
-
外部配置中心
-
自身程序中方法上的注解
@DubboService(methods = {
@Method(name = "getOrder",timeout = 3500)
})
4. 自身程序中接口上的注解
```java
@DubboService(timeout=2000)
public class OrderService{
}
- 自身程序中的配置文件（yml）
dubbo:
timeout:3000
- Dubbo默认配置文件dubbo.propertise
dubbo.timeout=1000高级用法 启动时检查
在消费者启动时，会去检查依赖的是否可以使用，如果不是可以使用将会不会正常启动
可以通过 check=“false” 来关闭启动时检查
集群容错措施 集群容错可以通过cluster进行配置
Failover Cluster（失败重试）
当请求失败的时候将自动切换到其他服务器进行请求，但重试会延迟反应时间，不建议设置过多，失败重试为缺省设置，重试次数为2次，也就是当请求失败时一共访问三次服务。
可以通过 retries=“*” 来配置重试次数
Failfast Cluster（快速失败）
当请求失败时，直接结束并抛出异常，通常适用在写入、保存操作。
Failsafe Cluster（失败安全）
当请求失败时，不会抛出异常。
Failback Cluster（失败自动恢复）
当请求失败时，后台会自动记录，并定时重发，通常用在发送短信、邮件业务，不关心返回结果的业务。
Failback Cluster（并行调用多个服务器）
同时向多个服务器发出请求，只有一个返回数据即可，通常用于实时性要求较高的读操作，会消耗大量资源。
Broadcast Cluste（广播调用所有提供者）
逐个调用所有提供者，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
可以通过loadbalance进行配置
Random 加权随机
默认算法，默认权重相同
RoundRobin 加权轮询
按公约后的权重设置轮询比率，循环调用节点
RoundRobin 加权最少活跃调用优先
活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数 - 响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。
ShortestResponse 加权最短响应优先
在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。
ConsistentHash 一致性 Hash
相同参数的请求总是发到同一提供者。
服务分组当一个接口有多种实现时，可以用 group 区分
多版本可以通过version熟悉进行配置
当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。
可以按照以下的步骤进行版本迁移：
- 在低压力时间段，先升级一半提供者为新版本
2.再将所有消费者升级为新版本
3.然后将剩下的一半提供者升级为新版本
可在消费者方 使用 stub 属性来配置
在服务提供者方实现，在调用接口前后进行拦截。
可在消费者方 使用 mock 属性来配置
在服务提供者方实现，调用接口后抛出了RPCException 异常是，进入本地伪装方法，优先级高于本地存根。
