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/

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
ESXi虚拟机磁盘格式转换与减小硬盘容量的方法
VMware虚拟机磁盘厚置备、精简置备两种格式。精简置备磁盘按需增长,厚置备磁盘立刻分配所需空间。厚置备磁盘较之精简置备磁盘有较好的性能,但初始置备浪费的空间较多。 精简置备磁盘虚拟机,如果频繁增加、删除、修改数据,精简置备磁盘实际占用的空间会超过为其分配的空间。例如某个VMware Workstation或VMware ESXi的虚拟机,为虚拟硬盘分配了40GB的空间(精简置备)。如果这台虚拟机反复添加、删除数据,在虚拟机中看到硬盘剩余空间只能还有很多,例如剩余一半,但这个虚拟硬盘所占用的物理空间可能已经超过了40GB,如果是厚置备磁盘则不会存在这个问题。 实际的生产环境中,虚拟机选择厚置备磁盘还是精简置备磁盘,要根据实际情况选择。如果虚拟机强调性能、并且数据量不大,则选择“厚置备立刻置零”,这将获得最好的性能。如果数据量持续增长、但变动不大,只是持续的增加,则可以选择“精简置备”磁盘。 在生产环境中,为虚拟机分配厚置备磁盘,磁盘的大小以达到稳定工作时占用的实际空间的1.5~2倍为宜,例如虚拟机稳定工作后需要400GB的空间,则为虚拟硬盘分配600~800GB为宜。空间不够可以再增加...
- 下一篇
晒一晒老司机写的“超融合私有云”解决方案
超融合私有云定义 超融合是指将所有虚拟化计算资源(内存、cpu、存储、网络等)整合到一个物理设施,并且能够方便横向扩展容量。传统的云架构相比较,超融合私有云不需要借助外挂存储及光纤交换机。大大简化了架构,并节省大笔开支,同时也降低了管理难度。 超融合私有云特征 ü 高可用性--数据更安全 任意部件甚至部分物理主机故障,都不会影响运行其上的服务。假使物理服务器down机,其上运行的虚拟机或者linux容器,会自动漂移到正常运行的其它物理节点。 ü 快速部署--更高效率 数分钟安装好底层系统,一条指令建立起集群,数小时即可交付使用。 ü 统一管理--化繁为简 Ø 浏览器访问任一集群节点,都可以对所有物理节点进行管理。 Ø Web界面管理一切:物理节点、集群、网络、虚拟机、存储、迁移、备份、恢复、克隆… ü 超融合--物超所值 Ø 系统架构超融合,舍弃昂贵的共享存储及光纤交换设备,降低设备采购成本、消灭存储单点、消除存储集中IO,从而间接提高了存储性能。 Ø 服务器虚拟机与桌面虚拟化融合,充分利用计算资源,物尽其用。 ü 去中心化 Ø 去中心化物理节点集群:任意一个或者多个物理节...
相关文章
文章评论
共有0条评论来说两句吧...