【实战总结】SpringMVC架构升级SpringCloudAlibaba

升级目标

SpringMVC+Dubbo+Zookeeper分布式架构改为Spring Cloud Alibaba微服务

技术框架:Spring Boot 2.7.2、Spring Cloud 2021.0.3 & Alibaba 2021.0.1.0

容器:Tomcat 9.0.65

JDK:1.8

配置中心:Nacos 2.0.4

消息队列:RocetMQ 4.9.3

配置中心:Apollo 11.0

缓存: Redis 4.0.14

接口服务:Swagger 3.0

数据源:Druid 支持多数据源,通过@Master和@Slave控制

远程调用:OpenFeign 11.8

APM工具:SkyWalking 9.2.0,包括分布式日志收集和链路追踪,性能指标分析和服务依赖分析等

升级背景

1. 产品方面：统一各系统框架和组件，封装通用功能，同时保持未来的高扩展性。Spring Cloud Alibaba生态更完善，功能更新更快，利于产品宣传，对产品进行长远布局。

2. 运维方面：提高部署和投产效率，目前架构与Docker、k8s集成不方便，Spring Cloud Alibaba天然支持CI、CD和Docker、k8s集成。

3. 业务方面：核心业务系统比较庞大，各模块耦合严重，不够灵活。考虑将按技术分层改为按业务领域拆分微服务，各微服务修改、部署互不影响，某个微服务停止服务不影响整体系统，容错性更高。

4. 架构设计：目前垂直架构存在弊端，重复代码多，系统间没有统一的注册中心，接口调用繁琐。Spring Cloud Alibaba统一使用Nacos集群注册中心，打破系统间壁垒。

升级原则

1. 所有架构设计以产品和业务为第一优先级，保证业务稳定、不受影响，同时提升系统性能和产品价值。

2. 以业务领域和业务量为基准拆分微服务。

3. 适当追新，新技术要适合业务和产品，并且收益大于成本可以考虑使用。

4. 尽量控制升级工作量。

5. 通用功能封装公共模块，避免重复造轮子。

架构图

升级收益

1.减少服务器成本。

2.视图层与业务层在同一个微服务，不再使用分布式调用，提高运行效率和可用性。

3.支持Docker、k8s运维管理。

升级步骤

1.pom依赖版本升级，解决jar包冲突，在root中统一维护依赖版本。

2.将SpringMVC XML配置文件修改为@Configration注入。

3.删除dubbo相关代码，将service服务作为依赖供web服务引用。

4.将log4j修改为logback，新增skywalking链路日志，并与logback集成。

5.ActiveMQ修改为RocketMQ。

6.新增异常统一处理、参数统一校验及日志切面。

7.兼容原Filter及Interceptor。

8.新增Swagger、Feign等。

9.将老旧的Redis客户端底层修改为RedisTemplate。

10.将各组件所有配置及业务配置兼容Apollo配置中心。

11.运维同步构造Docker容器、Jenkins流水线发布、各中间件集群。

升级过程

1.从现有系统git版本拉取升级分支。

2.升级过程中如果有新功能上线及时合并到升级分支。

3.基于升级分支版本对架构进行升级，保留原始提交记录。

4.本地调试完成后，发布测试环境时merge其他在途分支。

5.测试完成，准备上线。

上线方式

理想状态下应该是将新旧服务做集群，上线后将流量切到新服务上，如果有问题能随时切回原服务。

但实际上系统不断有迭代功能，这就意味着新旧服务要都要经过测试才能保证都能在生产环境可用，这次升级因资源限制，结合系统的重要性不是太高，最终决定使用新服务直接替代旧服务，有一定风险，幸好没有出现什么大问题。

注意事项

1.由于代码改动太大，合并代码后要逐一比对，防止处理冲突过程中代码丢失。

2.上线前逐一比对各项业务配置，防止遗漏。