最近在参与 Spring Cloud 微服务项目开发，在学习企业级开发流程时，对"技术负责人在项目启动阶段需要完成哪些工作"做了一次系统整理，于是有了这篇文章。
目录
[一 系统设计](#一 系统设计)
[二 需求分解](#二 需求分解)
[三 需求计划](#三 需求计划)
[四 工程创建](#四 工程创建)
[五 Apifox的创建](#五 Apifox的创建)
一 系统设计
主要工作:设计系统架构,拆分微服务,设计技术架构,设计目录结构
1.设计系统架构
接入层:
系统界面(Vue)
接入网关(Nginx):Nginx根据用户请求的是什么资源来进行处理,若请求的是静态资源,那么Nginx直接进行处理并将资源返回给浏览器,若请求的是动态资源,那么将请求转发到api网关(GateWay)
业务模块层
2.划分微服务原则
(1)单一职责原则
(2)高内聚低耦合原则
(3)服务自治原则
(4)单向依赖原则
3.微服务拆分的具体步骤
(1)先根据业务情况进行划分
(2)再根据技术角度拆分,比如单纯看业务的话是会漏掉网关这个重要的微服务的
(3)根据实际情况来进行划分,比如有些系统的地图使用率比较低,加上基础管理的用户量和并发可能相对较少,此时就可以考虑将两个微服务进行合并
4.技术架构
Nginx的作用:负载均衡,动静分离,反向代理
Gateway的作用:负载均衡,动态路由,权限控制
Nacos:服务注册,服务发现,配置隔离,配置更新,配置回滚
Open-Feign:实现服务间的调用
spring自带的:任务调度,定时任务,定时调度
阿里云OSS:文件存储,图像浏览
部署部分:让项目以容器化的形式进行部署--docker
gitee:集群流水线部署,代码仓库不可少
阿里云镜像仓库:阿里云提供的容器镜像存储服务
CI/CD:实现流水线(使用码云实现流水线部署)
涉及到的核心技术组件:
Redisson:基于Redis的Java客户端,提供分布式锁,集合等高级功能
Caffeine:高性能的Java本地缓存库,两级缓存,一级是本地缓存,一级是Redis缓存
Jwt:轻量级的认证规范,常用于用户身份认证
DockerCompose:定义和允许多容器,实现一键启动,管理和编排多容器依赖关系
Docker:容器化平台
5.项目目录结构
(1)工程分层
第一层,项目父工程,作为整个项目的根目录
第二层,公共模块,各个微服务
第三层,公共模块下第三层:基础通用包,通用消息包,公共协议,通用安全包,各中间件通用包
各个微服务下的第三层:微服务api层,微服务实现层
说明:公共SDK类似于一个工具包,我们可以对这些工具进行进一步分类,希望拿这种工具的时候不要连带着把其他工具也带出来了
公共模块层解释:
通用消息包:对于微信,邮件等的消息通知
公用协议:软件开发时通信或数据交换时所遵循的一套规则或约定,比如统一响应数据结构,统一状态码,就比如前后端请求和响应约定的统一格式返回
通用安全包:类似于异常处理等
各中间件通用包:例如redis或者rabbitmq等中间件
基础通用包:虽然进行细分,但是还是要控制度,不能划分太多太碎,于是对一些不属于上面那几类包的就统一放到基础通用包下
各个微服务下第三层的解释:
服务api:提供外部调用api(通过open-feign实现)和外部调用引用的Bean或者常量等信息的引用
服务实现:具体业务的实现
(2)包组织
基本原则:
①微服务中,业务模块按功能分包
②模块内分controller,domain,mapper,service
说明:为什么要按照上述原则来分,因为后续具体哪个微服务下的哪块功能随着业务的迭代要单独拆分出一个微服务,此时直接创建出一个微服务,然后将对应的功能包cut一粘贴过去即可
二 需求分解
1.需求分解的目的
主要就是将复杂庞大的开发任务拆解成一个一个的小任务,并分配给对应的开发人员,从而降低项目的风险,提高交付效率
2.分解过程
(1)从原始需求分解
比如
提供微服务架构解决方案的需求分解:--基于springcloud--集成nacos,集成网关......
地图服务需求分解:--城市根据拼音首字母进行归类,热门城市,获取所有城市列表,获取子行政区划,地图上搜索相关位置,根据经纬度获取城市......
参数管理需求分解:增加参数,获取参数列表,删除修改参数......
(2)从项目管理角度分解需求:
①前后端联调:前后端完成开发后,将前端页面与后端接口进行联调,这个由谁来主要负责,还需要谁协作
②部署上线
(3)从质量保障的角度:
①编写测试用例
②系统测试
三 需求计划
1.需求计划制定
(1)需求分配
(2)识别需求间的依赖与约束
(3)优先级排序
制定原则:价值驱动,前置条件优先,高风险需求前置(不确定性高、容易翻车、技术难度大、可能影响全局提前完成验证),低成本高收益优先,持续重评估
(4)人员分配
注:如果某个需求需要多人配合完成需要指定负责人和协作者
(5)制定合理时间计划
说明:上述已经将需求计划好了,接下来需要对需求计划进行输出
2.团队维护(使用码云)
3.码云创建项目
4.创建迭代
将一个大型的项目拆分成多个小的周期,每个周期完成一小部分功能,并通过持续反馈和调整优化产品
5.需求录入与分配
注:优先级的级别没有我们划分层次的那么多种,我们可以适当进行合并一下,然后对于有依赖关系但是是同级别的需求进行时间上前后顺序的一个安排
四 工程创建
注:
项目:码云上创建的项目,用于项目管理
工程:在编译器上创建的,用于代码编写
1.创建本地工程
(1)修改父工程pom.xml文件
作用:
①继承机制:子工程直接继承父工程的依赖
②统一属性:通过<properties>集中定义变量(如版本号,编码格式),子模块可以直接引用这些变量,便于维护和修改版本
③多模块聚合:通过<module>定义子模块列表,用于统一构建,在父工程命令下执行install,会按顺序构建所有子模块
④依赖管理:通过<dependencyManagement>统一管理依赖版本,子工程只需声明groupId和artifactId即可,无需指定版本,可以避免依赖版本冲突
⑤插件管理:通过<pluginManagement>统一管理插件配置(如编译版本,打包方式)
注:SpringBoot版本只要是3.几以上的,JDK版本至少是17
2.码云上创建代码仓库
3.本地仓库推送至远程
需要给当前项目创建目录并且进入到对应目录,但是由于我们已经在idea里创建了对应的目录,并且在终端其已经帮我们自动进行该目录了,我们可以直接执行以下语句
git init
git add .
git commit -m "first commit"
git remote add origin https://gitee.com/xxxx/framework-java.git
git push -u origin "master"4.分支维护
(1)分支策略
原则:团队协作顺利,平衡开发效率,代码稳定
①master分支:用于部署到正式环境,此分支为唯一分支,并且会被设置为保护分支(不允许任何人推送,只允许仓库管理员进行合并)
②develop:开发分支,基于master分支创建的唯一分支,并且会被设置为保护分支,始终保持最新完成(自测通过)以及bug修复后的代码(测试环节发现的bug),可部署到联调或者测试环境
③feature分支:通常为新功能或者新特性开发分支,以feature/开头,后面拼接功能名称,多个单词之间可以用短线分割
新特性或者新功能开发完成后,开发人员需合并到develop分支,合入develop分支后将其删除,如果develop分支产生变更,feature分支需要及时同步
④bug分支:修改bug的分支,此处的bug分为两种,线上bug基于master分支创建出分支,测试过程中发现的bug要基于develop分支进行创建
命名以bug/为开头,后面拼接bug名称(能指明是什么bug),多个单词之间可以用短线分割
注意:
如果是线上bug,直接将bug分支部署到测试环境进行测试,测试通过后合入master分支重新发布上线,上线后删除bug分支
非线上bug修复后合入develop分支,合入后重新将develop分支的代码部署到测试环境,测试人员对所修改bug验证无误后可修改bug分支
问题:
为什么线上bug就是bug分支直接进行部署测试,而非线上bug就是先合并到develop分支后再进行部署测试呢?
原因:
首先从线上bug上看,如果直接合并到master分支,此时如果bug修改不正确则可能破坏master分支,如果合并到develop分支,则可能新功能的迭代影响到了bug分支,feature分支更是功能开发,可能影响bug分支的测试,因此直接bug分支直接部署测试
从非线上bug看,虽然bug分支上也可以直接进行部署测试,但是不方便测试人员测完这个去测试其他的模块,将bug分支合并到develop分支,方便测试人员统一测试新修改的bug和测试新功能
综上所述,未来开发流程:
①将master设置为保护分支(不允许任何人推送,只允许仓库管理员进行合并)
②基于master分支创建develop分支,并设置为保护分支
③开发人员根据新功能的开发基于develop分支创建feature分支
④完成新功能的开发后,开发人员提交feature分支到develop分支的PullRequest,技术负责人进行审核,是否将feature分支合入develop分支
⑤审核未通过,处理PullRequest中存在的问题审核通过后合并后将develop分支部署到开发/测试环境,提供给测试人员进行测试
⑥循环3-5的步骤,直到项目开发完成
⑦将测试完成的develop分支合并master分支,基于master进行线上环境发布
五 Apifox的创建
使用Apifox完成下面内容:
(1)维护接口文档
(2)接口自测
1.基本使用
创建团队,邀请成员,创建项目,创建目录,创建接口
2.接口文档
(1)内容:
①接口概述:包括接口名称,接口功能,接口类别等
②接口地址:接口唯一的访问地址
③接口方法
④请求参数:定义请求时需要传的参数,包括路径参数,查询参数,请求头,请求体
⑤响应数据:定义接口返回的数据格式,包括状态码,消息体,数据体
⑥请求和响应示例
3.常见环境介绍:
开发环境
联调环境
测试环境(测试集群)
线上环境(生产集群)
环境区分开:避免不同的工作相互影响
在apifox里可以随意进行切换环境,设置对应环境里的url
设置环境变量,通常用于设置身份校验的token 本地值:只有当前机器上能看到 远程值:团队内的所有人都能看到