概述
Apache Dubbo是一款高性能的基于JAVA语言的RPC(Remote Procedure Call)框架。 Apache Dubbo提供了三个关键功能，其中包括接口的远程调用、容错和负载均衡，以及自动服务注册和发现，Apache Dubbo框架在阿里巴巴内外被广泛采用，包括京东、当当、去哪 儿、考拉和其他许多公司。
特点
调用关系说明
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于⻓连接推送变 更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果 调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据 到监控中心。
Maven依赖
<!-- https://mvnrepository.com/artifact/com.alibaba/dubbo -->
<dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.6.0</version>
</dependency>
<!-- https://mvnrepository.com/artifact/com.101tec/zkclient --> <dependency>
<groupId>org.apache.commons</groupId> <artifactId>commons-pool2</artifactId> <version>2.4.2</version>
</dependency> <dependency>
<groupId>com.101tec</groupId> <artifactId>zkclient</artifactId> <version>0.10</version>
</dependency>
服务提供者
定义服务接口
package com.alibaba.dubbo.demo;
public interface DemoService { String sayHello(String name);
}
在服务提供方实现接口
package com.alibaba.dubbo.demo.provider; import com.alibaba.dubbo.demo.DemoService;
public class DemoServiceImpl implements DemoService {
public String sayHello(String name)
{
return "Hello " + name;
}
}
用Spring 配置声明暴露服务
记录一下项目dubbo配置错误，导致启动服务时，找不到对应的服务。
服务提供者
一、用 Spring 配置声明暴露服务 Provider.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<dubbo:application name="A-service-center" />
<dubbo:protocol name="dubbo" port="${dubbo.port}"
dispatcher="all" threadpool="fixed" threads="${dubbo.thread.number}" />
<dubbo:registry address="${dubbo.zookeeper.address}"
file="dubbo-registry/dubbo-registry-A.properties" />
<dubbo:provider filter="CatFilter,DubboMdcFilter,RpcBusinessExceptionFilter" />
<!-- 声明需要暴露的服务接口 -->
//配置错误原因： ref：接口的实现类 我配置的和消费者的id一样导致错误。
<dubbo:service interface="com.dzj.A.api.si.TestServiceInterface"
ref="TestApplicationService" group="${dubbo.group}" timeout="30000"/>
</beans>
服务消费者
二、通过 Spring 配置引用远程服务 Consumer
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<dubbo:application name="dubbo-B-service" />
<dubbo:registry address="${dubbo.zookeeper.address}"
file="dubbo-registry/dubbo-registry-B.properties" />
<dubbo:consumer
filter="CatFilter,DubboMdcFilter,RequestContextPropogationFilter,RpcBusinessExceptionFilter" />
// retries 3 重试机制 消费方
<dubbo:reference
interface="com.dzj.B.api.si.UserServiceInterface"
id="userService" check="false" group="${dubbo.group}" retries="3" />
//暴露服务 Spring注入
<dubbo:reference id="TestServiceInterface"
interface="com.dzj.B.api.si.TestServiceInterface"
group="${dubbo.group}" check="false" />
</beans>
支持特性
启动时检查
Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初 始化完成，以便上线时，能及早发现问题，默认 check="true"。可以通过 check="false" 关 闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。
Dubbo负载均衡策略
在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。
- RandomLoadBalance(随机，按权重设置随机概率)
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
- RoundRobinLoadBalance(轮循，按公约后的权重设置轮循比率)
存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
- LeastActiveLoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
- ConsistentHashLoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
Dubbo的集群容错和负载均衡同样也是Dubbo本身的高级特性.正如我们在说自定义扩展的时候一样,这两个特征同样也可以进行自定义扩展,用户可以根据自己实际的需求来扩展他们从而满足项目的实际需求。
dubbo管理工具
dubbo-admin
只要dubbo配置文件加入zookeeper的服务地址。
先下载(复制一份到一个空间)tomcat ，，然后把dubbo-admin-2.5.4放到tomcat/webapps/下面。
在tomcat/conf/server.xml配置文件修改端口，防止端口占用。
<Connector connectionTimeout="20000" port="8088" protocol="HTTP/1.1" redirectPort="8443"/>
<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="%h %l %u %t "%r" %s %b" prefix="localhost_access_log" suffix=".txt"/>
<Context docBase="dubbo-admin-2.5.4" path="/" reloadable="true" /></Host>
集群容错
调用服务提供者的时候，dubbo提供了各种容错模式。保证获取到可用的服务。
- Failover Cluster 失败自动切换，当出现失败，重试其它服务器
- Failfast Cluster 快速失败，只发起一次调用，失败立即报错。
- Failsafe Cluster 失败安全，出现异常时，直接忽略。
- Failback Cluster 失败自动恢复，后台记录失败请求，定时重发。
- Forking Cluster 并行调用多个服务器，只要一个成功即返回。
- Broadcast Cluster广播调用所有提供者，逐个调用，任意一台报错则报错。 ttps://blog.csdn.net/bluetjs/article/details/52965260
dubbo服务注意事项
为避免服务升级时dubbo failover失效，我在develop上 把 dubbo-consumer 和 dubbo-provider中的 “retries=‘0’ 去除掉了（09fc351cac8d42216776db20e2021c910368b01c)。 服务的幂等需要自行保证好，因为dubbo 默认会retry 2 次，默认的超时时间是1s 。 大家如果有特意指定retries和timeout的，可以再讨论修改。
架构师引导我思考： A调用B服务 B升级了，调用失败了，会出现很多内部服务错误，，为了避免错误，需要重试其他服务，因此去掉retries=‘0’去掉，重试其他服务。
dubbo超时设置
DUBBO消费端设置超时时间需要根据业务实际情况来设定， 如果设置的时间太短，一些复杂业务需要很长时间完成，导致在设定的超时时间内无法完成正常的业务处理。 这样消费端达到超时时间，那么dubbo会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题，需要合理设置接口超时时间。 比如发送邮件，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据。
1）合理配置超时和重连的思路
1.对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
2.业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理
（2）Dubbo超时和重连配置示例
<!-- 服务调用超时设置为5秒,超时不重试–>
<dubbo:service interface="com.provider.service.DemoService" ref="demoService" retries="0" timeout="5000"/>
dubbo重连机制
dubbo在调用服务不成功时，默认会重试2次。 Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。 但是如果不合理的配置重试次数，当失败时会进行重试多次，这样在某个时间点出现性能问题，调用方再连续重复调用， 系统请求变为正常值的retries倍，系统压力会大增，容易引起服务雪崩，需要根据业务情况规划好如何进行异常处理，何时进行重试。
Dubbo 超时机制与重试机制～概念
Dubbo 启动时默认有超时机制与重试机制
- 超时机制：在设置的超时时间内，如果 consume 端没有接收到 provider 的返回值，认为本次调用失败
- 默认超时时间 请求执行默认超时时间：1s 连接默认超时时间：3s
- 超时时间设置
优先级别
consumer 端配置 > provider 端配置 > 全局配置
method 配置 > Interface 配置
- 接口运行机制
consumer会在超过超时时间得到一个调用超时的异常
provider中代码的执行不会因为超时而中断，在执行完毕后，会得到一个dubbo的警告
重试机制：在设置的重试次数内，请求都失败，认为此次请求异常，抛出异常 默认重试次数：2次. Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。
