答应了小伙伴的Dubbo源码分析系列,今天终于来了,希望不是很晚。
主要也是现在Spring CLoud Alibaba实在是太火了,很多小伙伴都想好好搞搞。
既然如此,我们就选择从Dubbo开始吧。
如果你已经对Dubbo熟练使用了,那这篇文章不太适合你,但如果想了解Dubbo,想学习Dubbo,那就非常适合你。
什么是Dubbo?
Dubbo一开始是由阿里巴巴开发,后面贡献给了Apache,所以后面我们称之为Apache Dubbo或者直接叫Dubbo。
Dubbo 是一款高性能、轻量级的开源服务框架 。
先纠正读法:
错误读法:diubo、dubo
正确读法:|ˈdʌbəʊ|
Dubbo的六大核心能力
开发中,我们都喜欢把Dubbo简称为RPC开源框架。
什么是RPC?
RPC是Remote Procedure Call的简称,翻译过来就是:远程过程调用。
简单的理解是一个节点请求另一个节点提供的服务 。
通俗点讲:
两台服务器A和B,在服务器A上部署一个应用程序serverA,在服务器B上部署一个应用程序serverB。此时,serverA想调用serverB里的某个方法,由于不在同一服务器内,不能直接调用,需要通过网络来表达调用的语义和传导调用的数据。
调用远程的方法就像调用本地的方法一样。
我们开发中,通常两个服务(不同服务器上的服务)之间的调用,通常都是用HTTP REST。
RPC框架
其实关于RPC框架,市面上有很多了,Dubbo只是其中之一。比如说还有:
Dubbo核心角色
我们来看看Dubbo架构中的核心角色:
该图来自于官网,下面我们对图做一个简单介绍:
Registry
注册中心。负责服务地址的注册与查找,服务的 Provider 和 Consumer 只在启动时与注册中心交互。注册中心通过长连接感知 Provider 的存在,在 Provider 出现宕机的时候,注册中心会立即推送相关事件通知 Consumer。
Provider
服务提供者。在它启动的时候,会向 Registry 进行注册操作,将自己服务的地址和相关配置信息封装成 URL 添加到 ZooKeeper 中。
Consumer
服务消费者。在它启动的时候,会向 Registry 进行订阅操作。订阅操作会从 ZooKeeper 中获取 Provider 注册的 URL,并在 ZooKeeper 中添加相应的监听器。获取到 Provider URL 之后,Consumer 会根据负载均衡算法从多个 Provider 中选择一个 Provider 并与其建立连接,最后发起对 Provider 的 RPC 调用。如果 Provider URL 发生变更,Consumer 将会通过之前订阅过程中在注册中心添加的监听器,获取到最新的 Provider URL 信息,进行相应的调整,比如断开与宕机 Provider 的连接,并与新的 Provider 建立连接。Consumer 与 Provider 建立的是长连接,且 Consumer 会缓存 Provider 信息,所以一旦连接建立,即使注册中心宕机,也不会影响已运行的 Provider 和 Consumer。
Monitor
监控中心。用于统计服务的调用次数和调用时间。Provider 和 Consumer 在运行过程中,会在内存中统计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。监控中心在上面的架构图中并不是必要角色,监控中心宕机不会影响 Provider、Consumer 以及Registry 的功能,只会丢失监控数据而已。
猥琐发育,后期爆发,(前期可能关注的不多,但是后期它特别香)
Container:
服务运行容器。是一个独立的容器,因为服务通常不需要Tomcat、JBoss等Web容器的特性,没必要用Web容器去加载服务。服务容器只是一个简单的main方法,并加载一个简单的Spring容器,用于暴露服务。
流程说明
在上面这张图中,有几个角色,并且还画了很多线条,下面我们对此做一个简单说明。
Dubbo官网
Dubbo的官网:
由于Dubbo是由阿里巴巴技术团队开发的,所以,文档方面对于咱们中国人来说那是相当的友好,一个字:爽!
另外,Dubbo官网上很多东西,我们就不在这里一一介绍了。
建议大家都去官网逛逛。
话不多说,咱们先来嗨一把!
demo案例1
我们先来搞一个没有注册中心的案例。
我们搭建一个项目,并创建三个module:
项目整体结构如下:
下面,我们来代码做一个简单说明。
首先是pom依赖:
org.apache.dubbo
dubbo
3.0.4
com.tian.dubbo
dubbo-demo-api
1.0-SNAPSHOT
consumer和provider项目都需要添加这两个依赖。
api
api主要是定义服务接口以及一些工具类,主要是供consumer和provider共用。
在api中我们只定义了一个服务接口:DemoService
package com.tian.dubbo.service;
public interface DemoService {
String sayHello(String msg);
}
然后打成jar,在consumer和provider项目中添加到pom.xml依赖里,最后两遍都可以使用了。
provider
在resources目录下创建一个目录META-INF.spring源码,然后在目录下创建一个application.xml,内容如下:
再在resources目录下创建一个日志打印的配置文件:log4j.properties
###set log levels###
log4j.rootLogger=debug, stdout
###output to the console###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=[%d{dd/MM/yy HH:mm:ss:SSS z}] %t %5p %c{2}: %m%n
在定义一个业务实现类:DemoServiceImpl
package com.tian.dubbo.service;
public class DemoServiceImpl implements DemoService {
public String sayHello(String msg) {
System.out.println("msg= " + msg);
return "SUCCESS";
}
}
再就是定义一个provider的启动类:ProviderMain
package com.tian.dubbo;
import org.apache.dubbo.container.Main;
public class ProviderMain {
public static void main(String[] args) {
Main.main(args);
}
}
注意:这里的Main类是Dubbo
最后,我们启动ProviderMain类,日志输出:
好了,已经启动成功了。
我们继续来看看consumer项目,在项目中,也就是调用我们服务的项目。
consumer
在consumer项目中application.xml配置文件和provider有所区别。
这个url地址,我们在provider启动的时候,可以从日志中找到。
日志文件和provider一样,然后就是ConsumerMain启动类了。
package com.tian.dubbo;
import com.tian.dubbo.service.DemoService;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class ConsumerMain {
public static void main(String[] args) {
DemoService demoService = null;
ApplicationContext context = new ClassPathXmlApplicationContext
("classpath:META-INF/spring/application.xml");
demoService = context.getBean(DemoService.class);
//调用服务
System.out.println(demoService.sayHello("tian"));
}
}
前面,我们已经把provider成功启动了,下面我们就来启动ConsumerMain。
从日志可以看出我们已经成功调用了provider,我们再来看看provider的日志输出:
也成功的输出了我们想要的。
到此,一个简单的入门无注册中心(通过url直接调用)的方式就完成了。
url在开发联调的时候还是很拥有的哦,因为它摆脱了对注册中心的依赖。
demo案例2
前面我们已经演示完了无注册中心,下面我们来演示有注册中心。
Dubbo目前差不多能支持市面上所有的注册中心:
我们在实际开发中,Dubbo注册中心大部分都是使用Zookeeper和Nacos。
下面们基于Zookeeper来演示(nacos类似,下面会说到)。
代码层面
我基于前面的案例进行改造。改造只需要调整两个地方:
pom依赖
我们需要在前面demo中consumer和provider的pom.xml中添加Zookeeper的依赖:
org.apache.dubbo
dubbo-dependencies-zookeeper
3.0.4
pom
provider端
在provider项目中我们需要调整:
改成:
这个timeout建议配上,我这里其实没必要配,因为dubbo服务和Zookeeper都在我本地。
然后我们启动provider项目:
看到我们的项目已经启动成功,并且已经注册到Zookeeper上了。
我们可以使用Zookeeper的可视化工具,看看注册上去的信息。
我们再看看consumer端的调整。
consumer端
我们需要在application.xml中添加
同时,去掉reference中的url:
因为是通过Zookeeper注册中心拿到地址,所以这里的url就可以去掉了。
最后,启动ConsumerMain类:
可以看到我们也成功调用服务,另外也有大量的Zookeeper日志。
到此,说明,我们的Zookeeper为注册中心的demo案例也成功了。
注意:provider和consumer项目都需要依赖相关jar包(api、zookeeper、dubbo)
其他
关于Nacos源码,我们这里就不演示了,因为太简单了,如果你把Nacos搭建好了后,直接配置就好了。
就是把address地址改一下就可以了。
- 最新
- 最热
只看作者