转载

SpringBoot开发案例之整合Dubbo分布式服务

在 SpringBoot 很火热的时候，阿里巴巴的分布式框架 Dubbo 不知是处于什么考虑，在停更N年之后终于进行维护了。在之前的微服务中，使用的是当当维护的版本 Dubbox ，整合方式也是使用的 xml 配置方式。

改造前

之前在 SpringBoot 中使用 Dubbox是这样的。先简单记录下版本，Dubbox-2.8.4、zkclient-0.6、zookeeper-3.4.6。

项目中引入 spring-context-dubbo.xml 配置文件如下：

" class="hljs "><beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://code.alibabatech.com/schema/dubbo
        http://code.alibabatech.com/schema/dubbo/dubbo.xsd
        ">
    <!-- 记录监控信息 -->
    <dubbo:monitor protocol="registry"/>
    <!-- 提供方应用信息，用于计算依赖关系 -->
    <dubbo:application name="spring-boot-pay" />
    <!-- 使用zookeeper注册中心暴露服务地址 subscribe 默认：true 是否向此注册中心订阅服务，如果设为false，将只注册，不订阅 check 默认：true 注册中心不存在时，是否报错    -->
    <dubbo:registry protocol="zookeeper" address="192.168.1.180:2181" check="false"/>
    <!-- 
               生产者配置 生产者  远程默认调用3次 参数 retries="2" async="true" 异步返回结果 默认是同步 timeout="10000" 毫秒
               用dubbo协议在20882端口暴露服务  固定线程池 10 启动时建立线程，不关闭，一直持有  负载均衡策略 轮询
     -->
    <dubbo:provider  timeout="10000"  threads="10" threadpool="fixed" loadbalance="roundrobin"/>
    <!-- name="dubbo" 协议名称   为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护。 host 部署外网设置为内网通信地址-->
    <dubbo:protocol name="dubbo" port="-1" dispatcher="all"  accepts="1000"   />

    <!-- 使用注解方式-->     
    <dubbo:annotation package="com.itstyle"/>
</beans>
复制代码

启动类引入以下注解：

@ImportResource({"classpath:spring-context-dubbo.xml"})
public class Application{
    private static final Logger logger = Logger.getLogger(Application.class);

    public static void main(String[] args) throws InterruptedException,
            IOException {
        logger.info("支付项目启动 ");
    }

}
复制代码

改造后

然而 SpringBoot 引入了新的概念 Spring Boot Starter ，它有效的降低了项目开发过程的复杂程度，对于简化开发操作有着非常好的效果。

starter的理念

starter会把所有用到的依赖都给包含进来，避免了开发者自己去引入依赖所带来的麻烦。

需要注意的是不同的 starter 是为了解决不同的依赖，所以它们内部的实现可能会有很大的差异，例如 jpa 的 starter 和 Redis 的 starter 可能实现就不一样，这是因为 starter 的本质在于 synthesize ，这是一层在逻辑层面的抽象，也许这种理念有点类似于 Docker ，因为它们都是在做一个“包装”的操作，如果你知道 Docker 是为了解决什么问题的，也许你可以用 Docker 和 starter 做一个类比。

starter的实现

虽然不同的 starter 实现起来各有差异，但是他们基本上都会 使用到两个相同的内容 ： ConfigurationProperties 和 AutoConfiguration 。

因为 Spring Boot 坚信“ 约定大于配置 ”这一理念，所以我们使用 ConfigurationProperties 来保存我们的配置，并且这些配置都可以有一个默认值，即在我们没有主动覆写原始配置的情况下，默认值就会生效，这在很多情况下是非常有用的。

除此之外， starter 的 ConfigurationProperties 还使得所有的配置属性被聚集到一个文件中（一般在 resources 目录下的 application.properties ），这样我们就告别了Spring项目中XML地狱。

starter的整体逻辑

强如Dubbo，当然也会创建属于自己的 starter 来迎合 Spring Boot 的火热。

这里我们使用Dubbo比较新的版本，pom.xml 引入以下：

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
    <version>2.6.2</version>
</dependency>
<dependency>
    <groupId>com.alibaba.spring.boot</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>2.0.0</version>
</dependency>
<!-- curator-recipes 替换  zkclient-->
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>4.0.1</version>
</dependency>
复制代码

application.properties 配置：

## dubbo springboot 配置
spring.dubbo.application.id=springboot_pay
spring.dubbo.application.name=springboot_pay
spring.dubbo.registry.address=zookeeper://192.168.1.127:2181
spring.dubbo.provider.threads=10
spring.dubbo.provider.threadpool=fixed
spring.dubbo.provider.loadbalance=roundrobin
spring.dubbo.server=true
spring.dubbo.protocol.name=dubbo
复制代码

启动类加入以下注解：

@EnableDubboConfiguration
@SpringBootApplication
public class Application{
    private static final Logger logger = Logger.getLogger(Application.class);

    public static void main(String[] args) throws InterruptedException,
            IOException {
        logger.info("支付项目启动 ");
    }

}
复制代码