升级目标
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.上线前逐一比对各项业务配置，防止遗漏。
