若依单体项目拆分微服务-全过程分享(带源码)

之前写过一篇,这次详细再说下

若依微服务版改造 拆分多仓库(带源码)_CJ点的博客-CSDN博客

一、前言

目标:若依的单体项目转换成分布式部署

效果:结合springCloud、Nacos配置中心模式,实现微服务化拆分

难点:

  1. 原项目为若依脚手架单体项目还带一些业务模块,无法简单复制粘贴迁移

  2. 基础权限表结构带有公司业务字段(创建人ID等)

  3. 维护成本在,不能过多拆分。(容易拖死自己)

  4. 原项目mybatis-plus结合的太深(自动注入创建ID等),分布式必须继续使用

  5. 若依的分布式项目不是直接分仓库的

可利用点:

  1. 若依提供单体和分布式的脚手架,用的数据库表95%是一样

  2. 有公司的其它分布式架构参考

二、架构的选择

若依单体架构,原项目的架构图,所有的代码都是一个仓库的。

(framework 、ruoyi-system 组成核心的权限模块,代码集中一个仓库,各个模块之间的引用非常紧密,基本拆不开)

com.ruoyi     
├── common            // 工具类
│       └── annotation                    // 自定义注解
│       └── config                        // 全局配置
│       └── constant                      // 通用常量
│       └── core                          // 核心控制
│       └── enums                         // 通用枚举
│       └── exception                     // 通用异常
│       └── filter                        // 过滤器处理
│       └── utils                         // 通用类处理
├── framework         // 框架核心
│       └── aspectj                       // 注解实现
│       └── config                        // 系统配置
│       └── datasource                    // 数据权限
│       └── interceptor                   // 拦截器
│       └── manager                       // 异步处理
│       └── security                      // 权限控制
│       └── web                           // 前端控制
├── ruoyi-generator   // 代码生成(可移除)
├── ruoyi-quartz      // 定时任务(可移除)
├── ruoyi-system      // 系统代码
├── ruoyi-admin       // 后台服务
├── ruoyi-business     //业务模块
├── ruoyi-autoBuilder     // 业务模块
├── ruoyi-datastata     // 业务模块

参考公司的一个分布式架构

(缺失权限、基础系统模块,核心通用模块不够全、业务不通)

├── fenxiao-admin         // 管理后台总出口
├── fenxiao-application         // 小程序端总出口
├── fenxiao-gateway         // 网关模块 [8080]
├── fenxiao-api             // 接口模块
│       └── fenxia-api-system                          // 系统接口
├── fenxiao-common          // 通用模块
│       └── fenxiao-common-core                         // 核心模块
│       └── fenxiao-common-datascope                    // 权限范围
│       └── fenxiao-common-datasource                   // 多数据源
│       └── fenxiao-common-log                          // 日志记录
│       └── fenxiao-common-redis                        // 缓存服务
│       └── fenxiao-common-security                     // 安全模块
│       └── fenxiao-common-swagger                      // 系统接口
├── fenxiao-parent         // 总的maven管理模块
├── fenxiao-modules         // 业务模块
├── fenxiao-modules         // 业务模块
├── fenxiao-modules         // 业务模块
├── fenxiao-modules         // 业务模块

若依分布式式架构

(没有结合Mybati-plus\表结构缺失创建人ID、代码都集中在一个仓库、缺失一个maven版本管理模块单独作为模组存储)

com.ruoyi     
├── ruoyi-ui              // 前端框架 [80]
├── ruoyi-gateway         // 网关模块 [8080]
├── ruoyi-auth            // 认证中心 [9200]
├── ruoyi-api             // 接口模块
│       └── ruoyi-api-system                          // 系统接口
├── ruoyi-common          // 通用模块
│       └── ruoyi-common-core                         // 核心模块
│       └── ruoyi-common-datascope                    // 权限范围
│       └── ruoyi-common-datasource                   // 多数据源
│       └── ruoyi-common-log                          // 日志记录
│       └── ruoyi-common-redis                        // 缓存服务
│       └── ruoyi-common-security                     // 安全模块
│       └── ruoyi-common-swagger                      // 系统接口
├── ruoyi-modules         // 业务模块
│       └── ruoyi-system                              // 系统模块 [9201]
│       └── ruoyi-gen                                 // 代码生成 [9202]
│       └── ruoyi-job                                 // 定时任务 [9203]
│       └── ruoyi-file                                // 文件服务 [9300]
├── ruoyi-visual          // 图形化管理模块
│       └── ruoyi-visual-monitor                      // 监控中心 [9100]
├──pom.xml                // 公共依赖

 

 

最终的选择是

使用最新的若依分布式框架+原公司的分布式的parent模块的形式,并入原项目的业务模块。

三、持续迭代改造

一阶段

将若依的分布式架构拆分成多仓库存储。auth+system 组成一个仓库,新增一个parent仓库来管理maven版本,common新增一个Mybaits-plus模块(为后面的业务模块使用)

源码:https://gitee.com/bdp-one

com.ruoyi     
├── ruoyi-ui              // 前端框架 [80]
├── ruoyi-gateway         // 网关模块 [8080]
├── ruoyi-system            // 认证中心 + 权限模块
├── ruoyi-api             // 接口模块
│       └── ruoyi-api-system                          // 系统接口
├── ruoyi-common          // 通用模块
│       └── ruoyi-common-core                         // 核心模块
│       └── ruoyi-common-datascope                    // 权限范围
│       └── ruoyi-common-datasource                   // 多数据源
│       └── ruoyi-common-log                          // 日志记录
│       └── ruoyi-common-redis                        // 缓存服务
│       └── ruoyi-common-security                     // 安全模块
│       └── ruoyi-common-swagger                      // 系统接口
│       └── ruoyi-common-mybatis-plus               // mybatis-plus
├── ruoyi-modules         // 业务模块
│       └── ruoyi-controller                              
│       └── ruoyi-gen                                 // 代码生成 [9202]
├──ruoyi-parent                // maven版本管理+SQL初始
│       └── sql   

二阶段

开始逐步转变成符合公司的开发规范和业务。

1、修改数据库底层的权限表,新增创建人ID

2、新增修改相应JAVA实体类和mapper.xml文件

3、排查个别不同的表字段,修改权限代码

源码:https://gitee.com/organizations/bdp-test

三阶段

  1. 对各种各样的原项目的工具类引入到新的架构里面(复制粘贴,使用正确的jar包和版本)

  2. 解决包冲突(guava),更新核心的nacos为比较新的2.0.3版本

  3. 修改redis为集群配置

  4. 将原业务模块直接迁移过去

  5. 新增common-api-core 存在 HTTP工具类,解决 common 和api 两个模块之间 的相互依赖问题

  6. 没有新建一个总的出口模块,减少一些重复的开发量(但不知好坏)

├── bdp-parent          // 父级pom模组公共依赖
│       └── sql                          // sql
├── bdp-ui              // 前端框架 [80]
├── bdp-gateway         // 网关模块 [8080]
├── bdp-api             // 服务内调用-接口模块
│       └── bdp-api-core                          // HTTP核心工具类接口
│       └── bdp-api-system                          // 系统接口
│       └── bdp-api-modules                        // 原BDP接口
├── bdp-common          // 通用模块
│       └── bdp-common-core                         // 核心模块
│       └── bdp-common-datascope                    // 权限范围
│       └── bdp-common-datasource                   // 多数据源
│       └── bdp-common-log                          // 日志记录
│       └── bdp-common-redis                        // 缓存服务
│       └── bdp-common-security                     // 安全模块
│       └── bdp-common-swagger                      // 系统接口
│       └── bdp-common-mybatis-plus                 // mybatis-plus拓展 
│       └── bdp-common-sso                 // sso
│       └── bdp-common-es                 // es
├── bdp-modules         // 业务模块
│       └── bdp-modules-controller                  // 这里做一个总的控制器
│                                └── bdp-gen                           // 代码生成
│                                └── bdp-business1                     //业务模块-1
│                                └── bdp-business2                     // 业务模块-2
├── bdp-business3         //业务模块-
├── bdp-system            // 系统模块+认证中心 [9201]

 

四、遇到的困难

  1. jar 冲突

  2. maven 的使用(parent模块没有指定jdk版本导致项目错乱、maven私仓账号密码错了导致项目错乱)

  • 7
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Java单体项目转换为微服务项目需要注意以下几点: 1. 需要对项目进行拆分,将不同的业务模块分离出来,以便更好地实现微服务的独立部署、扩展和管理。 2. 需要重新设计数据库结构,将原来的单一数据库拆分为多个数据库,以便更好地实现微服务的独立管理。 3. 需要使用轻量级的框架和组件,例如Spring Boot、Spring Cloud等,以便更好地实现微服务的快速开发和部署。 4. 需要使用RESTful API等标准协议,以便更好地实现微服务之间的通信和数据交换。 5. 需要使用容器化技术,例如Docker、Kubernetes等,以便更好地实现微服务的容器化部署和管理。 6. 需要实现服务发现和治理,例如使用Consul、Zookeeper等工具,以便更好地实现微服务的自动发现、负载均衡和故障恢复。 7. 需要实现监控和日志收集,例如使用Prometheus、ELK等工具,以便更好地实现微服务的性能监控和问题排查。 ### 回答2: 当将Java单体项目转为微服务项目时,需要注意以下几点: 1. 代码拆分和服务拆分:对于单体项目中的功能模块,需要进行适当的拆分和重构,将其转化为独立的服务。这可以通过将模块独立成独立的代码库或者模块化的方式实现。 2. 服务间通信方式:微服务架构中,各个服务之间需要进行通信。需要考虑采用何种通信方式,如RESTful API、消息队列等。同时,还需要注意数据传输的安全性和可靠性。 3. 服务注册与发现:微服务架构中,服务需要进行注册与发现,以便其他服务能够找到并调用它。可以使用服务注册与发现工具,如ZooKeeper、Consul等,来实现服务的注册和发现。 4. 服务监控和容错:微服务架构中,每个服务都需要进行监控和容错处理。需要使用适当的监控工具来监控服务的运行情况,并及时处理故障。此外,还需要考虑服务的容错机制,如熔断、降级等。 5. 数据一致性和事务管理:微服务架构中,每个服务都有自己的数据库。需要考虑如何保持数据的一致性,以及如何管理跨服务的事务。可以使用分布式事务管理机制,如使用消息队列或者分布式事务框架来解决这些问题。 6. 部署和运维:微服务架构中,需要考虑如何部署和运维各个服务。可以使用容器化技术,如Docker、Kubernetes等,来实现服务的快速部署和管理。 总之,将Java单体项目转为微服务项目需要在代码拆分、服务通信、服务注册与发现、服务监控和容错、数据一致性和事务管理、部署和运维等方面进行适当的调整和改进。 ### 回答3: 将Java单体项目转换为微服务项目一个相对复杂的过程,需要注意以下几点: 1. 项目拆分:将单体项目按照业务模块进行合理的拆分,每个微服务负责一个特定的业务功能。拆分的原则是高内聚、低耦合,使得每个微服务可以独立开发、测试、部署和扩展。 2. 通信机制:选择合适的通信机制,如RESTful API或消息队列等,以便微服务之间可以进行可靠的调用和通信。同时要注意考虑数据的一致性和可靠性,例如使用分布式事务或事件驱动等方式。 3. 数据管理:将原来的关系型数据库根据业务领域划分为多个独立的数据库或数据源,每个微服务只关注自己的数据,通过服务间的通信进行数据交互和同步。同时,考虑到数据的一致性和性能,可以考虑使用缓存或分布式缓存等技术。 4. 部署和扩展:微服务架构通常采用容器化部署,例如Docker和Kubernetes等。在转换过程中,需要重新设计和配置部署环境,包括容器编排、负载均衡和服务发现等。同时,要考虑如何实现弹性扩展和负载均衡,以应对高并发和大规模数据的处理。 5. 监控和治理:微服务架构中,每个微服务都是一个独立的进程,需要实时监控其运行状态和健康状况。因此,需要建立合适的监控系统,例如使用ELK栈(Elasticsearch + Logstash + Kibana)或Prometheus等。此外,还需要考虑如何进行服务的注册、发现和配置管理,以便实现服务的动态更新和管理。 6. 团队协作:微服务架构需要团队成员具备理解和实施微服务架构的能力。因此,在转换过程中,需要进行团队培训和技术支持,确保团队成员掌握新的技术和架构概念,并能够协同合作进行项目开发和维护。 总之,将Java单体项目转换为微服务项目需要综合考虑架构设计、通信机制、数据管理、部署和扩展、监控和治理等方面的问题,同时也需要关注团队协作和技术转型的问题。只有综合考虑并解决这些问题,才能成功实现单体项目微服务架构的转换。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值