springcloud微服务项目解析与服务拆分

本文介绍了SpringCloud微服务项目如何进行统一版本管理、工具类整合、项目结构设计以及服务拆分。详细讲解了服务网关的搭建、单点登录的实现和服务容错的处理策略,包括分布式事务的解决方案,如两阶段提交和AT模式,并讨论了常见的服务容错模式,如超时、限流和仓壁模式。
摘要由CSDN通过智能技术生成

统一版本

通过全服务共享一个总父项目,各个子项目不加版本,由这个总父项目来控制版本,子项目会根据情况自动升级。
这种专门管理版本的项目,我们一般称为BOM(Bill Of Materials 物料清单)。已经成为非常成熟的模式。如果你沿着spring-boot的parent往上追溯也会找到spring-boot-dependencies,就是一个BOM。
这里需要了解下 这个标签,它会管理依赖的版本,包括依赖排除这些,但是不会为子项目加入这个依赖。这点跟 是不同的,这也是BOM的关键技术。
另外,子项目通过 指定父项目。
比如创建一个mall-parent项目,负责管理版本全局统一的父pom。

统一工具类

一般公司内部都有自己的工具类,会提供一些类似如日期格式化,ID生成等等的工具类。这类的工具类是非常通用的,每个项目的每个模块都会需要用上。所以会考虑直接在总父pom中加入依赖。一旦加入就是全局引入,所有项目就自动获得这个依赖。所以除了这个统一工具类的依赖以外,很少会再加入其他依赖。
比如创建一个mall-commons项目(单纯的maven-quickstart项目)来统一提供工具类,具体功能如下:

提供各种基础工具
统一响应格式
统一错误码
统一的异常父类
统一的ID生成工具

统一项目结构

项目当然可以是单体项目。但是既然是为了解决可能面对的复杂问题,我们就来模拟一个复杂的项目结构。
这里涉及到maven多模块项目的概念。
maven多模块项目其实是指在一个项目中包含多个独立的模块项目,每个模块可以单独打包成jar或者war。

项目拆分

单个项目组成部分

一个逻辑业务项目一般被具体拆分为以下几个部分
1.app层
2.service层
3.infra层
4.common层
5.client层
该业务的所有接口归纳给client层暴露出去,install 导本地的maven仓库,其他项目就可以调用此项目的各类业务接口,同时也将各个业务完整的划分开来。

项目依赖关系

居中

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值