文章结尾有彩蛋
很早以前,在刚开始搞Spring Cloud基础教程的时候,写过这样一篇文章:《微服务架构的基础框架选择:Spring Cloud还是Dubbo?》,可能不少读者也都看过。之后也就一直有关于这两个框架怎么选的问题出来,其实文中我有明确的提过,Spring Cloud与Dubbo的比较本身是不公平的,主要前者是一套较为完整的架构方案,而Dubbo只是服务治理与RPC实现方案。
由于Dubbo在国内有着非常大的用户群体,但是其周边设施与组件相对来说并不那么完善。很多开发者用户又很希望享受Spring Cloud的生态,因此也会有一些Spring Cloud与Dubbo一起使用的案例与方法出现,但是一直以来大部分Spring Cloud整合Dubbo的使用方案都比较别扭。这主要是由于Dubbod的注册中心采用了ZooKeeper,而开始时Spring Cloud体系中的注册中心并不支持ZooKeeper,所以很多方案是存在两个不同注册中心的,之后即使Spring Cloud支持了ZooKeeper,但是由于服务信息的粒度与存储也不一致。所以,长期以来,在服务治理层面上,这两者一直都一套完美的融合方案。
直到Spring Cloud Alibaba的出现,才得以解决这样的问题。在之前的教程中,我们已经介绍过使用Spring Cloud Alibaba中的Nacos来作为服务注册中心,并且在此之下可以如传统的Spring Cloud应用一样地使用Ribbon或Feign来实现服务消费。这篇,我们就来继续说说Spring Cloud Alibaba中特别支持的RPC方案:Dubbo。
入门案例
我们先通过一个简单的例子,来直观地感受Nacos服务注册中心之下,利用Dubbo来实现服务提供方与服务消费方。这里省略Nacos的安装与使用,如果对Nacos还不了解,可以查看本系列的使用Nacos实现服务注册与发现,下面就直接进入Dubbo的使用步骤。
构建服务接口
创建一个简单的Java项目,并在下面定义一个抽象接口,比如:
public
interface
HelloService
{
String hello(String name);
}
构建服务接口提供方
第一步:创建一个Spring Boot项目,在 pom.xml
中引入第一步中构建的API包以及Spring Cloud Alibaba对Nacos和Dubbo的依赖,比如:
<dependencies>
<!-- 第一步中构建的API包 -->
<dependency>
<groupId>com.didispace</groupId>
<artifactId>alibaba-dubbo-api</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>