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

前言

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

改造前

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

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

<?xml version="1.0" encoding="UTF-8"?>
<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>

启动类引入以下注解:

@SpringBootApplication
@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 引入以下:

<!-- dubbo 替换  dubbox-->
<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("支付项目启动 ");
    }

}

相关暴露接口实现配置:

import org.springframework.stereotype.Component;
import com.alibaba.dubbo.config.annotation.Service;

@Service
@Component
public class AliPayServiceImpl implements IAliPayService {
      //省略代码
}

最后启动服务,如果启动成功并注册到注册中心,说明改造成功。

补充

Dubbo 2.6.1 是改变结构后首次发布的版本,Dubbo 2.6.0 已合并当当网提供的 Dubbox 分支。

Dubbo的版本策略:两个大版本并行发展,2.5.x是稳定版本,2.6.x是新功能实验版本。2.6上实验都稳定了以后,会迁移到2.5。

总结

  • 原当当 Dubbox 2.8.4 替换为 Dubbo 2.6.2
  • 原 spring-context-dubbo.xml 配置 替换为 dubbo-spring-boot-starter 2.0.0
  • 原 zkclient 0.6 替换为 curator-recipes 4.0.1
  • 原 zookeeper 3.4.6 升级为 zookeeper 3.5.3

案例

支付宝,微信,银联详细代码案例:https://gitee.com/52itstyle/spring-boot-pay

参考

https://github.com/apache/incubator-dubbo

https://github.com/alibaba/dubbo-spring-boot-starter/blob/master/README_zh.md

https://github.com/spring-projects/spring-boot/tree/master/spring-boot-project/spring-boot-starters

https://www.nosuchfield.com/2017/10/15/Spring-Boot-Starters/

原文地址:http://blog.51cto.com/itstyle/2299907

时间: 2024-11-10 02:13:32

SpringBoot开发案例之整合Dubbo分布式服务的相关文章

SpringBoot开发案例从0到1构建分布式秒杀系统

前言 最近,被推送了不少秒杀架构的文章,忙里偷闲自己也总结了一下互联网平台秒杀架构设计,当然也借鉴了不少同学的思路.俗话说,脱离案例讲架构都是耍流氓,最终使用SpringBoot模拟实现了部分秒杀场景,同时跟大家分享交流一下. 秒杀场景 秒杀场景无非就是多个用户在同时抢购一件或者多件商品,专用词汇就是所谓的高并发.现实中经常被大家喜闻乐见的场景,一群大妈抢购打折鸡蛋的画面一定不会陌生,如此场面让服务员大姐很无奈,赶上不要钱了. 业务特点 瞬间高并发.电脑旁边的小哥哥.小姐姐们如超市哄抢的大妈一般

SpringBoot开发案例之多任务并行+线程池处理

前言 前几篇文章着重介绍了后端服务数据库和多线程并行处理优化,并示例了改造前后的伪代码逻辑.当然了,优化是无止境的,前人栽树后人乘凉.作为我们开发者来说,既然站在了巨人的肩膀上,就要写出更加优化的程序. SpringBoot开发案例之JdbcTemplate批量操作 SpringBoot开发案例之CountDownLatch多任务并行处理 改造 理论上讲,线程越多程序可能更快,但是在实际使用中我们需要考虑到线程本身的创建以及销毁的资源消耗,以及保护操作系统本身的目的.我们通常需要将线程限制在一定

一篇文章带你深入了解Dubbo分布式服务框架

一.产生的背景 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进.下面我们用一个图来具体说明架构和开发框架的演进过程.单一应用架构当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本.此时,用于简化增删改查工作量的数据访问框架(ORM)是关键. 垂直应用架构当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率.此时,用于加速前端

Dubbo分布式服务子系统的划分

一.划分子系统的策略 按照系统的业务模块的独立性划分 二.划分时服务子系统的数量的控制 过多:可能划分过细,破坏业务子系统的独立性,部署维护工作量大,独立进程占用内存多 过少:没能很好的解耦,开发维护不好分工,升级维护影响面大 三.服务子系统划分要注意的地方 3.1 不要出现A服务中的SQL需要链接查询到B服务中的表等情况,这样在A服务与B服务进行垂直拆库时就会出错       eg:服务虽然拆分了,但是还是用的同一个数据库 3.2  服务子系统间避免出现环状的依赖调用        eg:A服

fastdfs分布式文件系统之与dubbo整合实现分布式服务接口

fastdfs是开源的轻量级分布式文件系统,它提供了java版本的client api.通过client API可以实现对文件的上传.追加.下载.删除等功能. 为了避免每个应用都配置fasdtfs参数.读取配置文件.调用client api获取trackerServer和StorageServer进行上传.下载.删除等操作及返回结果的 处理.所以采用与dubbo整合,提供分布式服务接口,来简化其它服务和应用的文件操作处理,同时提高代码的复用性. 1.总体结构 如图,总共分为fastdfs-api

Dubbo分布式服务框架入门

参考http://blog.csdn.net/u013142781/article/details/50387583 一.Dubbo概念介绍 1.1.Dubbo是什么? Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC(Remote Procedure Call Protocol)远程服务调用方案,以及SOA(Service-Oriented Architecture,面向服务的体系结构)服务治理方案.简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的,只

(二)构建springmvc整合dubbo分布式平台-平台功能导图

上一篇我们介绍了构建dubbo分布式平台的技术选型.目标.特点.独立服务项目等,今天针对于独立服务项目提供平台功能导图,也是我们未来逐步研发的功能. 我这边不做多介绍,直接上图了: 下面的章节中,我们会针对于不同的平台提供不同的解决方案和实施步骤,会详细记录每一个细节点,希望能够帮助大家一起学习! 原文地址:http://blog.51cto.com/13494127/2066675

Dubbo分布式服务框架

Dubbo (开源分布式服务框架) 编辑 本词条缺少信息栏,补充相关内容使词条更完整,还能快速升级,赶紧来编辑吧! Dubbo是 [1]  阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 [2]  Spring框架无缝集成. Dubbo是一款高性能.轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现. 目录 1 主要核心部件 2 工作原理 3 特性 主要核心部件

Maven多模块、Dubbo分布式服务框架的SpringMVC项目的基础搭建

现互联网公司后端架构常用到Spring+SpringMVC+MyBatis,通过Maven来构建.通过学习,我已经掌握了基本的搭建过程,写下基础文章为而后的深入学习奠定基础. 首先说一下这篇文章的主要内容分为: 1.Maven多模块项目的创建: 2.Maven与SpringMVC的整合: 3.Dubbo的环境配置及与整合: 4.新手在整合过程易犯的错误. 通过一个简单的demo来说明,大家多多指教,分享经验! 一.Maven多模块项目的创建 我们需要建立一个多模块的maven项目,其目录结构为