bugboys-ms-member
- 基于 Spring Cloud Greenwich.SR2 、Spring Boot 2.1.6、 OAuth2 的RBAC权限管理系统
- 基于数据驱动视图的理念封装 element-ui，即使没有 vue 的使用经验也能快速上手
- 提供对常见容器化支持 Docker、Kubernetes 支持
- 提供 lambda 、stream api 、webflux 的生产实践
部署文档 | 语雀-团队协作文档 | mindmaster
技术选型
后端技术
| 技术 | 说明 | 官网 |
|---|---|---|
| SpringBoot | 容器+MVC框架 | spring.io/projects/sp… |
| SpringCloud | 容器+MVC框架 | spring.io/projects/sp… |
| SpringSecurity | 认证和授权框架 | spring.io/projects/sp… |
| MyBatis | ORM框架 | www.mybatis.org/mybatis-3/z… |
| MyBatisGenerator | 数据层代码生成 | www.mybatis.org/generator/i… |
| PageHelper | MyBatis物理分页插件 | git.oschina.net/free/Mybati… |
| Swagger-UI | 文档生产工具 | github.com/swagger-api… |
| Hibernator-Validator | 验证框架 | hibernate.org/validator |
| Elasticsearch | 搜索引擎 | github.com/elastic/ela… |
| RabbitMq | 消息队列 | www.rabbitmq.com/ |
| Redis | 分布式缓存 | redis.io/ |
| MongoDb | NoSql数据库 | www.mongodb.com |
| Docker | 应用容器引擎 | www.docker.com |
| Druid | 数据库连接池 | github.com/alibaba/dru… |
| OSS | 对象存储 | github.com/aliyun/aliy… |
| JWT | JWT登录支持 | github.com/jwtk/jjwt |
| LogStash | 日志收集工具 | github.com/logstash/lo… |
| Lombok | 简化对象封装工具 | github.com/rzwitserloo… |
| Jenkins | 自动化部署工具 | github.com/jenkinsci/j… |
前端技术
| 技术 | 说明 | 官网 |
|---|---|---|
| Vue | 前端框架 | vuejs.org/ |
| Vue-router | 路由框架 | router.vuejs.org/ |
| Vuex | 全局状态管理框架 | vuex.vuejs.org/ |
| Element | 前端UI框架 | element.eleme.io |
| Axios | 前端HTTP框架 | github.com/axios/axios |
| v-charts | 基于Echarts的图表框架 | v-charts.js.org/ |
| Js-cookie | cookie管理工具 | github.com/js-cookie/j… |
| nprogress | 进度条控件 | github.com/rstacruz/np… |
一、项目结构
bugboys-ms-project
│
└───bugboys-project-api
│
└───bugboys-project-data
│
└───bugboys-project-server
- 模块说明
- bugboys-project-api
- bugboys-project-data
- bugboys-project-server
- 项目注意事项
api服务接口url统一以
/api开头
bugboys-project-api 说明
1、关于包命名规则
api接口统一在com.bugboys.business.api包下, 命名以 ApiService 结尾, 例如类 BusinessTestApiService
2、api类的开发介绍
BusinessTestApiService
@FeignClient(value = "business", contextId = "businessTestApi", path = "api/businessTest")
@Api(tags = {"testApi"})
public interface BusinessTestApiService {
@ApiOperation("test 接口")
@ApiMethodMapping("/test")
TestRbo test(@RequestParam("mobile") String mobile);
}
关于@FeignClient的使用
- value：应用名称， 例如：会员服务(member)、商城(shop)、商家服务(business)
- contextId：以类名驼峰命名(不包含结尾Service)，例如：businessTestApi
- path：以类名驼峰命名(不包含结尾ApiService)，例如：businessTest
关于@Api的说明
- 必须包含该注解
关于Api服务接口方法的说明
- 必须使用注解
@ApiOperation、@ApiMethodMapping - 超过2个参数需要封装dto对象传输
- 参数禁止
Map传输 - 结果返回对象命名以
Rbo结尾，remote business object(ps: 有更好名称命名可以提下) - 结果禁止返回
Result对象、禁止返回void、禁止返回Map对象、禁止返回Java基本类型(int/long等)，需要返回具体的业务对象或者Java封装基本类型包装类(Integer/Long)
bugboys-project-data 说明
目前该包用于api交互的对象、或者提供给其他服务使用到的枚举类
1、关于包命名规则
传递参数使用dto，返回结果使用Rbo
bugboys-project-server 说明
com.bugboys.project
│
└───api.controller
│
└───common (公共的枚举类、工具类、配置类、拦截器等)
│
└───component (公共的组件包)
│
└───controller (控制器包、如：后台admin、应用接口app、等等)
│
└───dao
│
└───entity
│
└───pojo (dto、vo、bo、或者一些convert类转换操作、或者entity的wrapper)
│
└───service
1、api.controller包
注：禁止在改类下编写业务代码，业务代码统一在service层编写，可以参考member、shop服务下面的
@ApiControllerMapping("api/businessTest")
@Api(tags = {"测试Api"})
public class BusinessTestApiController implements BusinessTestApiService {
@ApiOperation("test 接口")
@Override
public TestRbo test(String mobile) {
TestRbo testRbo = new TestRbo();
testRbo.setMobile(mobile);
return testRbo;
}
}
2、controller包
@AppControllerMapping
public class PingController {
@RequestMapping("/ping")
public Result ping(){
return Result.ok("api-business");
}
}
二、业务与异常编码
| 业务 | 代码开头 | 说明 | 样例 |
|---|---|---|---|
| 基础服务 | 10 | 后面保留4位 | 105000 |
| 会员服务 | 20 | 后面保留4位 | 105000 |
| 商城服务 | 30 | 后面保留4位 | 105000 |
| 支付服务 | 40 | 后面保留4位 | 105000 |
三、Java项目版本管理规范
版本命名规则
版本命名规范在maven的规范上做了进一步的严格要求，具体格式为：
<主版本>.<次版本>.<增量版本>-<代号>
| 部分 | 说明 | 含义 |
|---|---|---|
| 主版本 | 必须 | 主版本一般来说代表了项目的重大的架构变更，比如说Maven 1和Maven 2，在架构上已经两样了，将来的Maven 3和Maven 2也会有很大的变化。 |
| 次版本 | 必须 | 次版本一般代表了一些功能的增加或变化，但没有架构的变化，比如说Nexus 1.3较之于Nexus 1.2来说，增加了一系列新的或者改进的功能，但从大的架构上来说，1.3和1.2没什么区别。 |
| 增量版本 | 必须 | 增量版本一般是一些小的bug修复，没有有重大的功能变化。 |
| 代号 | 必须 | 分为不稳定版本（SNAPSHOT）和稳定版本（非SNAPSHOT）两类。 SNAPSHOT是指开发分支中的“最新”代码，表示代码可能随时变化，发布到maven的snapshot仓库。 相反，“稳定”版本中的代码（非SNAPSHOT后缀的任何版本值）都是不变的，发布到maven的release仓库。 |
代号的取值范围：
| 代号 | 分类 | 版本 | 说明 |
|---|---|---|---|
| SNAPSHOT | 不稳定版本 | 开发版本 | 指develop分支中或者hotfix/xxx分支上的最新代码，表示代码可能随时变化。 |
| RCx | 稳定版本 | 预发布版本 | 当代码实现了全部功能，清除了大部分 bug，接近发布倒计时。x是数字，如RC1、RC2。 |
| RELEASE | 稳定版本 | 正式发布版本 | 指master分支中的某个tag的对应的代码，表示正式发布的版本。 |
例子：
- 开发版本：0.1.0-SNAPSHOT、0.2.0-SNAPSHOT、2.1.0-SNAPSHOT
- 稳定版本：
- 候选发布版本：0.1.0-RC1、1.2.0-RC2
- 正式发布版本：0.1.0-RELEASE、0.1.1-RELEASE、0.1.2-RELEASE、1.2.0-RELEASE
git-flow流程介绍
项目遵循的是 git-flow 的分支流程规范。git 客户端我们建议使用 SourceTree，因为SourceTree 对 git-flow 提供了内置的可视化支持，而不需要你去记住一大堆的命令。菜单入口是 仓库 - git-flow，不同的 SourceTree 版本可能会有差异
如果你坚持用命令行，可以参考这里。
git-flow 的总体流程示意图如下：
branch（分支）
在 git-flow 中，我们有两个永久分支：
- develop：开发分支。日常开发使用的分支，项目协作者主要工作在这个分支上，同时所有的 pull request 都应该发到这个分支；
- master：主分支。所有提供给用户使用的正式版本（RELEASE），都在这个主分支上发布。
其实，永久分支只需要这两条就够了，不需要其他了。但是，除了永久分支以外，还有一些临时分支，用于应对一些特定目的的版本开发。临时分支主要有三种：：
- feature/xxx：功能分支。它是为了开发某种特定功能，从develop分支上面分出来的，开发完成后，要再并入develop。功能分支可以有多个，这些分支通常只是个人使用，存在开发者本地库中，如果需要多人协作，则需要推送到远程仓库；
- release/xxx：发布分支。它是指发布正式版本之前（即合并到master分支之前），我们可能需要有一个预发布（RC）的版本进行测试。发布分支对代码进行了封版，不允许在发布分支上开发新功能，只允许修复测试发现的bug；
- hotfix/xxx：补丁分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。补丁分支是从master分支上面分出来的，修补结束以后，再合并进master和develop分支。
tag（标签）
标签是用于对应每个预发布版本或发布版本的版本标识，即 x.y.z-RCx 或 x.y.z-RELEASE
例如：1.0.2-RC1、1.0.1-RELEASE
开发工程师
作为开发工程师，你有两类分支：
- develop 开发分支，用于下一个发布版本。
- feature/xxx 功能分支，用于开发新功能 xxx，根据需要可能会有多个功能分支。
新功能开发流程
要开发下一个版本的功能，你要从develop分支开出新的功能分支，最后合并回develop分支，如此往复：
* 4. (develop) 合并 'feature/work-with-correcting-a' 到 develop
|\
| * 3. (feature/work-with-correcting-a) Correcting a
|/
* 2. 合并 'feature/work-with-a' 到 develop
|\
| * 1. (feature/work-with-a) a
|/
*
注意示意图顺序都是从下往上看！ 为了更轻松地与其他开发工程师合作开发一个大功能，你可以从这个功能分支再开出新的功能分支。你可以将这个大型功能分支叫做集成分支。
- 在该 feature 分支上进行开发，提交代码，如需多人协作，push 该分支到远程（origin）仓库。
- 你应定期rebase（变基）或合并 develop 分支的代码到你的 feature 分支，使你的代码保持最新，并避免合并冲突。
- 你应在完成某个功能后，尽可能快地合并 feature 分支代码到 develop 分支并删除该 feature 分支，快速传播你的提交以避免合并冲突。
配置管理员
作为配置管理员，你有两类分支：
- master生产分支，代表正式发布的版本（生产版本）。
- release/xxx 发布分支，用于准备发布版本。
版本发布流程
当准备封版的时候，假设你这次要发布的版本是 0.2.0-RELEASE，你需要：
- 创建一个候选发布版本（release candidate），即从 SourceTree 中选择“建立新的发布版本”，发布版本号填写0.2.0-RELEASE。
- 将release/0.2.0-RELEASE分支的版本号修改为0.2.0-RC1，发布到测试环境进行测试。
- 将develop分支的版本号修改为下一个版本，即将develop分支的版本号修改为0.3.0-SNAPSHOT。
| * 3. 发布 RC1 到测试环境测试
| * 2. (release/0.2.0-RELEASE) 修改版本号为 0.2.0-RC1，打标签: 0.2.0-RC1
* | 1. (develop) 修改版本号为 0.3.0-SNAPSHOT
|/
打补丁流程
并非每个 bug 都有打补丁的必要，对于不紧急的 bug，可以在 develop 里修复后随下一个版本发布。
打补丁是指对提供给用户使用的正式版本进行修复。
假设要对正式版本0.1.0-RELEASE打补丁。
- SourceTree中，选择
建立新的修复补丁，修复补丁版本为0.1.1-RELEASE，此时 SourceTree 从 master 分支创建了一个补丁分支。 - 在补丁分支上修复bug，修改bug的三种做法参考版本发布流程。
- 将hotfix/0.1.1-RELEASE分支的版本号修改为 0.1.1-RC1，发布到测试环境进行测试。
- 如果测试有bug，重复以上第2、3步，其中第3步中的RC版本号进行递增。
- 测试没问题后，将hotfix/0.1.1-RELEASE分支的版本号修改为0.1.1-RELEASE
- 在 SourceTree中，选择 完成修复补丁，此时SourceTree会自动做以下工作：
- 将hotfix/0.1.1-RELEAS分支合并到master分支。
- 将hotfix/0.1.1-RELEASE分支合并到 develop 分支。
- 在master分支上打标签0.1.1-RELEASE。
- 最后，删除该补丁分支。
版本发布环境
bugboys-project不同分支上发布版本时的代号，以及发布的目标环境。
| 项目\git分支 | feature分支 | develop分支 | release分支 | hotfix分支 | master分支 |
|---|---|---|---|---|---|
| project-api/common-mudule | SNAPSHOT，发布到本机 | SNAPSHOT，发布到maven的snapshot仓库 | RCx，发布到maven的release仓库 | RCx，发布到maven的release仓库 | RELEASE，发布到maven的release仓库 |
| project-server | SNAPSHOT，发布到本机 | SNAPSHOT，发布到开发测试环境 | RCx，发布到准生产环境 | RCx，发布到准生产环境 | RELEASE，发布到准生产环境 |
bugoys规范
- 同一项目中所有模块版本保持一致
- 子模块统一继承父模块的版本
- 统一在顶层模块Pom的节中定义所有子模块的依赖版本号，子模块中添加依赖时不要添加版本号
- 开发测试阶段使用SNAPSHOT
- 生产发布使用RELEASE
- 新版本迭代只修改顶层POM中的版本
用于线上发布的代码，不可以使用包含 “SNAPSHOT版本” 的依赖包，从而确保每次构建出的产物都是一致的。
常用maven命令
- 然后运行以下命令即可将制品推送到仓库中
mvn clean install deploy -DskipTests
- 把父模块更新到指定版本号，然后更新子模块，与父模块有相同的版本号
mvn versions:set -DnewVersion=1.0.1-SNAPSHOT
mvn -N versions:update-child-modules
