前言：

1、本文内容阅读Dubbo官方文档获得

2、本文是Java API的角度使用Dubbo，不使用Spring.

一、快速体验Dubbo API

版本：2.7.7

1、服务提供者。nacos直接将zookeeper换为nacos即可

ApplicationConfig application = new ApplicationConfig(); application.setName("dubbo-server");   // 连接注册中心配置 RegistryConfig registry = new RegistryConfig(); registry.setAddress("zookeeper://39.100.116.73:2181");   // 服务提供者协议配置 ProtocolConfig protocol = new ProtocolConfig(); protocol.setName("dubbo"); protocol.setPort(12345); protocol.setThreads(100);   // 注意：ServiceConfig为重对象，内部封装了与注册中心的连接，以及开启服务端口   // 服务提供者暴露服务配置 ServiceConfig<RemoteService> service = new ServiceConfig<RemoteService>(); // 此实例很重，封装了与注册中心的连接，请自行缓存，否则可能造成内存和连接泄漏 service.setApplication(application); service.setRegistry(registry); // 多个注册中心可以用setRegistries() service.setProtocol(protocol); // 多个协议可以用setProtocols() service.setInterface(RemoteService.class); service.setRef(new RemoteServiceImpl()); service.setVersion("1.0.0");   // 暴露及注册服务 service.export(); System.out.println("dubbo service started"); new CountDownLatch(1).await();

2、服务调用者

ReferenceConfig<RemoteService> reference = new ReferenceConfig<>(); reference.setApplication(new ApplicationConfig("dubbo-demo-api-consumer")); reference.setRegistry(new RegistryConfig("zookeeper://39.100.116.73:2181")); reference.setInterface(RemoteService.class); reference.setVersion("1.0.0"); RemoteService service = reference.get(); String hello = service.hello("req : hello"); System.out.println(hello);

 

3、Dubbo的泛化调用

ApplicationConfig application = new ApplicationConfig(); application.setName("dubbo-genericService-consumer");   RegistryConfig registry = new RegistryConfig(); registry.setAddress("zookeeper://39.100.116.73:2181");   application.setRegistry(registry);     ReferenceConfig<GenericService> genericReference = new ReferenceConfig<GenericService>(); // 弱类型接口名 genericReference.setInterface("com.back.RemoteService"); // 声明为泛化接口 genericReference.setGeneric(true);   genericReference.setApplication(application); genericReference.setCheck(false);   genericReference.setCluster("failover"); genericReference.setRetries(2); genericReference.setLoadbalance("leastactive"); genericReference.setVersion("1.0.0");   // 用com.alibaba.dubbo.rpc.service.GenericService可以替代所有接口引用 GenericService genericService1 = genericReference.get();   String name = (String) genericService1.$invoke("hello", new String[]{String.class.getName()}, new Object[]{"req_hi"}); System.out.println(name);

二、Dubbo 相关配置

1、启动时检查。将会默认关闭

开启时会检查服务可用性。当提供者服务临时出现故障时会抛出异常

避免提供者服务临时不可用的情况。所以需要关掉

api：reference参见一 中的调用示例

reference.setCheck(false);

2、Dubbo集群容错策略

1）Failover Cluster （默认方式，也将是cwop-rpc现有支持的模式（motan））

失败自动切换，当出现失败，重试其它服务器 。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。

重试次数api：genericReference.setRetries(2);

2）Failfast Cluster

快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

3）Failsafe Cluster

失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

4）Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

5）Forking Cluster

并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

6）Broadcast Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。

 

指定容错策略api：genericReference.setCluster("failover");

3、Dubbo集群负载均衡策略。（cwop-rpc会默认支持LeastActive LoadBalance）

1）Random LoadBalance

• 随机，按权重设置随机概率。
• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

2）RoundRobin LoadBalance

• 轮询，按公约后的权重设置轮询比率。
• 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

3）LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

4）ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
   

指定负载策略api: genericReference.setLoadbalance("leastactive");

4、Dubbo线程模型（需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景）

cwop-rpc 默认将会选择message的Dispatcher + eager 的ThreadPool 来组合。因为DODP中类似模型查询等耗时的Clickhouse查询所有事件都在io线程上运行，io线程将会被阻塞，导致不能接受其他请求.

cached资源不可控、limited 流量峰值后不会收缩、 fixed 线程不关闭一直持有

Dispatcher

• all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
• direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
• message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
• execution 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
• connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

ThreadPool

• fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
• cached 缓存线程池，空闲一分钟自动删除，需要时重建。
• limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
• eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)

5、Dubbo静态服务。（服务提供者初次注册时为禁用状态，需人工启用。断线时，将不会被自动删除，需人工禁用。）

此功能适合服务超级多，人工来控制哪些服务生效与否的情况。

cwop-rpc默认不开启静态服务。

6、Dubbo多协议。

Dubbo支持不同服务发布不同协议。

cwop-rpc默认发布Dubbo协议

7、Dubbo服务分组

当接口有多个实现时可以通过group区分

服务提供者api：service.setGroup("feedback");

服务调用者api：genericReference.setGroup("feedback");

8、Dubbo多版本

接口中的version属性（参见一中的提供者例子）

同接口可以存在不同版本调用

9、Dubbo分组聚合

对同一个接口、不同分组的多个服务可以将其结果集聚合

api未找到。（待验证）

10、Dubbo调用结果缓存

1）缓存策略

• lru 基于最近最少使用原则删除多余缓存，保持最热的数据被缓存。
• threadlocal 当前线程缓存，比如一个页面渲染，用到很多 portal，每个 portal 都要去查用户信息，通过线程缓存，可以减少这种多余访问。
• jcache 与 JSR107 集成，可以桥接各种缓存实现。

设置缓存api：

MethodConfig methodConfig = new MethodConfig();
methodConfig.setName("hello");
methodConfig.setCache("lru");
genericReference.setMethods(Lists.newArrayList(methodConfig));

 

11、Dubbo泛化调用

示例参见一

泛化调用过程如果参数是对象，则使用Map来传输

官网示例：

// 引用远程服务 // 该实例很重量，里面封装了所有与注册中心及服务提供方连接，请缓存 ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>(); // 弱类型接口名 reference.setInterface("com.xxx.XxxService");  reference.setVersion("1.0.0"); // 声明为泛化接口 reference.setGeneric(true);    // 用org.apache.dubbo.rpc.service.GenericService可以替代所有接口引用  GenericService genericService = reference.get();    // 基本类型以及Date,List,Map等不需要转换，直接调用 Object result = genericService.$invoke("sayHello", new String[] {"java.lang.String"}, new Object[] {"world"});    // 用Map表示POJO参数，如果返回值为POJO也将自动转成Map Map<String, Object> person = new HashMap<String, Object>(); person.put("name", "xxx"); person.put("password", "yyy"); // 如果返回POJO将自动转成Map Object result = genericService.$invoke("findPerson", new String[] {"com.xxx.Person"}, new Object[]{person});

 

对于泛化类型：

 

12、Dubbo延迟暴露

服务延迟一小段时间后暴露

api：service.setDelay(2);

 

13、并发控制

Dubbo可以做到限制服务级别和方法级别的并发控制（server并发大小和client并发调用大小）

 

13、连接控制

1）Dubbo可以限制服务端接收的连接大小

2）Dubbo可以限制客户端服务使用连接

3）同时配置以客户端配置为准（Dubbo的配置覆盖策略）

 

14、token认证

防止调用者绕过注册中心产生调用。可以自定义密码，也可以随机Token令牌（UUID）

api：

service.setToken(true);
service.setToken("111");

 

15、优雅停机

Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果用户使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。

api：

DubboShutdownHook.destroyAll();

 

 

16、日志适配

Dubbo适配了多种日志（支持log4j2）。cwop-rpc将默认配置为log4j2

api：

application.setLogger("log4j2");

配置：

META-INF/dubbo/org.apache.dubbo.common.logger.LoggerAdapter

内容：

xxx=com.xxx.XxxLoggerAdapter

17、注册中心简化

Dubbo之前版本被诟病的一点是太多和实际服务调用不是核心相关的参数被写入到注册中心，导致性能下降。

在加入apache 后注册中心被优化为：注册中心、配置中心、元数据中心三大部分。

开启注册中心简化配置：dubbo.properties

dubbo.registry.simplified=true

 

 

三、异常处理

1、是否支持异常栈传输？若不支持需要在扩展Filter在attachment中加异常标识来扩展实现？

待验证

 

四、通过Dubbo给NacosClient 调参

示例：nacos://127.0.0.1:8848?namingLoadCacheAtStart=true

示例中的参数cwop-rpc会默认自动加上

解决的问题：

Zookeeper注册中心有一个问题，如果注册中心全部宕机时，Client依然可以正常访问Server，但是Client重启后就无法访问了

而Nacos能够做到注册中心全挂，client重启后依然可以调用server（配置这个参数后可以，会本地持久化，重启时加载）。