下半年参与了一个互联网金融项目的重构,dubbo 转 spring cloud
期间遇到各种大小坑
重构限定于代码层,数据库结构基本保持不变
先期代码迁移主要是包名 文件名的修改,spring cloud的项目配置
和单元测试用例
单元测试不应该用于测试接口
先期设计单元测试 用于接口测试,导致项目自测阶段进展缓慢,流程难以测试,数据不和逻辑
项目依赖有所减轻,么有达到请耦合,各个各个模块之间相互依赖
针对 spring cloud的流程依赖改造 未进行
项目重构的后续:
代码层的重构 促进了代码规范的作用,
重构之后 项目架构清晰,开发联调的效率提高,个人感受,springCloud的微服务比dubbo 开发效率更高。
重构期间git 多个分支并行开发,每次代码合并大量冲突
注意点:
- 合并代码要合并远程分支。本地分支有可能不是最新代码
- 代码行数不宜超过1000行
- import 引入提交前排序
- 代码注释
对于微服务的理解
- 业务划分通过Controller 层约束 不同的业务禁止复用接口
- 服务粒度尽可能小 方便后期service层复用
- 公共DTO 放在在Common 项目中 减少各个项目之间的代码依赖
- 项目之间只是服务调用依赖