Dubbo示例目录

最新推荐文章于 2024-10-06 20:16:20 发布

chuandie7960

最新推荐文章于 2024-10-06 20:16:20 发布

阅读量176

点赞数

文章标签： java 大数据数据库

原文链接：https://my.oschina.net/u/3039671/blog/799709

版权

启动时检查：

ubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=true。如果check=false，总是会返回引用，当服务恢复时，能自动连上。

http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E5%90%AF%E5%8A%A8%E6%97%B6%E6%A3%80%E6%9F%A5

集群容错：

在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试。通过配置 retries="2"(注意，这个2不包含第一次错误的计数）可以达到3次错误就不在重试

http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99

负载均衡

在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。

关键配置项：loadbalance="roundrobin"

http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1

线程池模型

如果事件处理的逻辑能迅速完成，并且不会发起新的IO请求，比如只是在内存中记个标识，则直接在IO线程上处理更快，因为减少了线程池调度。
但如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到线程池，否则IO线程阻塞，将导致不能接收其它请求。

示例：


<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />

http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E7%BA%BF%E7%A8%8B%E6%A8%A1%E5%9E%8B

直连提供者

在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，

http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E7%9B%B4%E8%BF%9E%E6%8F%90%E4%BE%9B%E8%80%85

多协议

(1) 不同服务不同协议

不同的服务使用不同的协议传输，不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。

(2) 多协议暴露服务

同一个服务使用多种协议，例如需要与http客户端互操作

http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E5%A4%9A%E5%8D%8F%E8%AE%AE

(3) 多注册中心引用

服务消费者使用多个服务提供者的服务，

服务分组

当一个接口有多种实现时，可以用group区分。

示例：


<dubbo:service group="feedback" interface="com.xxx.IndexService" />

<dubbo:service group="member" interface="com.xxx.IndexService" />

<dubbo:reference id="feedbackIndexService" group="feedback" interface="com.xxx.IndexService" />

<dubbo:reference id="memberIndexService" group="member" interface="com.xxx.IndexService" />

多版本

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

参数校验

http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E5%8F%82%E6%95%B0%E9%AA%8C%E8%AF%81

回声测试

回声测试用于检测服务是否可用，回声测试按照正常请求流程执行，能够测试整个调用是否通畅，可用于监控。


MemberService memberService = ctx.getBean("memberService"); // 远程服务引用
 
EchoService echoService = (EchoService) memberService; // 强制转型为EchoService
 
String status = echoService.$echo("OK"); // 回声测试可用性
 
assert(status.equals("OK"))

上下文信息

上下文中存放的是当前调用过程中所需的环境信息。

(1) 服务消费方


xxxService.xxx(); // 远程调用
boolean isConsumerSide = RpcContext.getContext().isConsumerSide(); // 本端是否为消费端，这里会返回true
String serverIP = RpcContext.getContext().getRemoteHost(); // 获取最后一次调用的提供方IP地址
String application = RpcContext.getContext().getUrl().getParameter("application"); // 获取当前服务配置信息，所有配置信息都将转换为URL的参数
// ...
yyyService.yyy(); // 注意：每发起RPC调用，上下文状态会变化
// ...

(2) 服务提供方


public class XxxServiceImpl implements XxxService {
 
    public void xxx() { // 服务方法实现
        boolean isProviderSide = RpcContext.getContext().isProviderSide(); // 本端是否为提供端，这里会返回true
        String clientIP = RpcContext.getContext().getRemoteHost(); // 获取调用方IP地址
        String application = RpcContext.getContext().getUrl().getParameter("application"); // 获取当前服务配置信息，所有配置信息都将转换为URL的参数
        // ...
        yyyService.yyy(); // 注意：每发起RPC调用，上下文状态会变化
        boolean isProviderSide = RpcContext.getContext().isProviderSide(); // 此时本端变成消费端，这里会返回false
        // ...
    }
 
}

RpcContext是一个ThreadLocal的临时状态记录器，当接收到RPC请求，或发起RPC请求时，RpcContext的状态都会变化。
比如：A调B，B再调C，则B机器上，在B调C之前，RpcContext记录的是A调B的信息，在B调C之后，RpcContext记录的是B调C的信息。