dubbo 阿里开源的一个SOA服务治理框架,从目前来看把它称作是一个RPC远程调用框架更为贴切。单从RPC框架来说,功能较完善,支持多种传输和序列化方案。所以想必大家已经知道他的核心功能了:就是远程调用。
实现步骤
dubbo 引入:
org.apache.dubbo
dubbo
2.7.4.1
服务端代码:
public void openServer(int port) {
ApplicationConfig config = new ApplicationConfig();
config.setName("simple-app");
ProtocolConfig protocolConfig=new ProtocolConfig();
protocolConfig.setName("dubbo");
protocolConfig.setPort(port);
protocolConfig.setThreads(20);
ServiceConfig serviceConfig=new ServiceConfig();
serviceConfig.setApplication(config);
serviceConfig.setProtocol(protocolConfig);
serviceConfig.setRegistry(new RegistryConfig(RegistryConfig.NO_AVAILABLE));
serviceConfig.setInterface(UserService.class);
serviceConfig.setRef(new UserServiceImpl());
serviceConfig.export();
}
客户端代码:
static String remoteUrl = "dubbo://127.0.0.1:12345/tuling.dubbo.server.UserService";
// 构建远程服务对象
public UserService buildRemoteService(String remoteUrl) {
ApplicationConfig application = new ApplicationConfig();
application.setName("young-app");
ReferenceConfig referenceConfig = new ReferenceConfig<>();
referenceConfig.setApplication(application);
referenceConfig.setInterface(UserService.class);
referenceConfig.setUrl(remoteUrl);
UserService userService = referenceConfig.get();
return userService;
}
在上一个例子中如多个服务的集群?即当有多个服务同时提供的时候,客户端该调用哪个?以什么方式进行调用以实现负载均衡?
一个简单的办法是将多个服务的URL同时设置到客户端并初始化对应的服务实例,然后以轮询的方式进行调用。
但如果访问增大,需要扩容服务器数量,那么就必须增加配置重启客户端实例。显然这不是我们愿意看到的。Dubbo引入了服务注册中的概念,可以解决动态扩容的问题。
演示基于注册中心实现服集群:
# 服务端连接注册中心
serviceConfig.setRegistry(new RegistryConfig("multicast://224.1.1.1:2222"));
# 客户端连接注册中心
referenceConfig.setRegistry(new RegistryConfig("multicast://224.1.1.1:2222"));
#查看 基于UDP 占用的2222 端口
netstat -ano|findstr 2222
在前面两个例子中 出现了,ApplicationConfig、ReferenceConfig、RegistryConfig、com.alibaba.dubbo.config.ServiceConfig等实例 ,很显然不需要每次调用的时候都去创建该实例那就需要一个IOC 容器去管理这些实例,spring 是一个很好的选择。
提供者配置----------------------------------
提供者服务暴露代码:
ApplicationContext context = new ClassPathXmlApplicationContext("/spring-provide.xml");
((ClassPathXmlApplicationContext) context).start();
System.in.read();
消费者配置---------------------------------------
消费者调用代码:
ApplicationContext context = new ClassPathXmlApplicationContext("/spring-consumer.xml");
UserService userService = context.getBean(UserService.class);
UserVo u = userService.getUser(1111);
System.out.println(u);
标签 | 用途 | 解释 |
---|---|---|
dubbo:application/ | 公共 | 用于配置当前应用信息,不管该应用是提供者还是消费者 |
dubbo:registry/ | 公共 | 用于配置连接注册中心相关信息 |
dubbo:protocol/ | 服务 | 用于配置提供服务的协议信息,协议由提供方指定,消费方被动接受 |
dubbo:service/ | 服务 | 用于暴露一个服务,定义服务的元信息,一个服务可以用多个协议暴露,一个服务也可以注册到多个注册中心 |
dubbo:provider/ | 服务 | 当 ProtocolConfig 和 ServiceConfig 某属性没有配置时,采用此缺省值,可选 |
dubbo:consumer/ | 引用 | 当 ReferenceConfig 某属性没有配置时,采用此缺省值,可选 |
dubbo:reference/ | 引用 | 用于创建一个远程服务代理,一个引用可以指向多个注册中心 |
dubbo:method/ | 公共 | 用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息 |
dubbo:argument/ | 公共 | 用于指定方法参数配置 |
配置关系图:
配置分类
所有配置项分为三大类。
先来看一个简单配置
通过字面了解 timeout即服务的执行超时时间。但当服务执行真正超时的时候 报的错跟timeout并没有半毛钱的关系,其异常堆栈如下:
可以看到错误表达的意思是 因为Channel 关闭导致 无法返回 Response 消息。
出现这情况的原因在于 虽然timeout 配置在服务端去是用在客户端,其表示的是客户端调用超时间,而非服务端方法的执行超时。当我们去看客户端的日志时候就能看到timeout异常了
类似这种配在服务端用在客户端的配置还有很多,如retries/riː’traɪ/(重试次数)、async/əˈsɪŋk/(是否异步)、loadbalance(负载均衡)。。。等。
**套路一:**服务端配置客户端来使用。
注:其参数传递机制是 服务端所有配置都会封装到URL参数,在通过注册中心传递到客户端
如果需要暴露多个服务的时候,每个服务都要设置其超时时间,貌似有点繁琐。Dubbo中可以通过 dubbo:provider 来实现服务端缺省配置。它可以同时为 dubbo:service 和 dubbo:protocol 两个标签提供缺省配置。如:
#相当于每个服务提供者设置了超时时间 和重试次数
同样客户端也有缺省配置标签:dubbo:consumer,这些缺省设置可以配置多个 通过
、
套路二:dubbo:provider与dubbo:service ,dubbo:consumer与dubbo:reference傻傻分不清楚
在服务端配置timeout 之后 所有客户端都会采用该方超时时间,其客户端可以自定义超时时间吗?通过
小提示:通过DefaultFuture的get 方法就可观测到实际的超时设置。
com.alibaba.dubbo.remoting.exchange.support.DefaultFuture
**套路三:**同一属性到处配置,优先级要小心。
提供端:---------------------------
消费端示例:--------------------