springcloud研发规范
1) 程序结构规范
1: Facade-Stub：包含所有对外提供服务的借⼝定义，并对外提供
2: Faade：实现Faade-Stub⾥⾯定义的全部借⼝，可以调⽤Service模块和Common模块
3: Task：包含全部的任务实现，可以调⽤Service模块和Common模块
4: Service：包含业务处理逻辑，通常来说事务在此模块中实现，可以调⽤Client、Dao和Common
5: Client：包含全部对其他服务的调⽤，通过引⼊Faade-Stub实现借⼝调⽤，可以调⽤其他服务的Faade-Stub和本服务Common 6: Dao：包含所有对数据的操作，包含SQL、NoSql等，可以调⽤Common
7: Common:⼀些本服务中通⽤的⽅法
8: 模块命名⽅法: 业务名称-服务名称-模块名称 akucun-ur-client
9: 使⽤⼦模块的⽅式引⼊到主POM中
<modules>
<module>akucun-ur-client</module>
<module>akucun-ur-common</module>
<module>akucun-ur-dao</module>
<module>akucun-ur-facade</module>
<module>akucun-ur-facade-stub</module>
<module>akucun-ur-rvice</module>
<module>akucun-ur-task</module捐赠仪式
>
</modules>
2) 技术栈规范
新业务应⽤全部使⽤:
java + mybatis + springcloud 的技术栈进⾏研发
⽼系统逐步替换成规定的技术栈
l 数据库设计规范
ID 统⼀叫: pid
created_time、updated_time、created_by、update_by是必须要加到表定义中的。
如果有删除动作还需要加上is_delete、delete_time、delete_by等字段 , is_delete 为NOT NULL字段 默认为0 , 1 表⽰删除
所有字段尽量全部都是NOT NULL，如果业务上确实需要使⽤为NULL的字段，请说明。
请尽量将数据关于春节的图画
库的默认步长设置为2⽅便以后扩展
频繁需要连表查询的数据，考虑是否可以进⾏数据冗余
3) 接⼝设计规范
对外接⼝设计时参照RESTful风格
使⽤HTTP Method 来标识操作:
POST: 表⽰新增
GET: 表⽰查询
DELETE: 表⽰删除
PUT: 含有近义词的
表⽰更新
PATCH: 新春祝福词
; 表⽰部分更新(依照以前的经验⽼说，不太常⽤，或者转义使⽤)
使⽤资源来标识操作的对象
这个URL标识将 api->v1版本->b2b域下->ID为1的⽤户 作为操作对象
注：对于特别复杂的接⼝，可以不严格遵照规范设计，但是要在设计时提出
接⼝数据传递通过原则上通过JSON实现
所有接⼝的返回值必须有统⼀的结构，具体结构会在后⾯给出
接⼝返回的状态码需要统⼀分段分配
前端和后端需要共同维护状态码和报错信息的对应表
每个服务都要提供health-check接⼝,⽤于检测其可⽤
4) 提测规范
开发⼈员根据接⼝⽂档完成研发后需要将接⼝(编号)提测
提测的接⼝集合应该⾄少是⼀个完整的流程或功能(例如对会员信息的增删改查，应该⼀起提测)有依赖关系的接⼝应该先提测底层接⼝再提测上层接⼝从教
每个提测接⼝应需给出⼀个调⽤⽰例(可苦难的名言
以保存在postman上)
postman 账号：aikucun
密码：aikucun123456
完成接⼝测试之后才能进⾏前端系统的测试(可能是某个模块的接⼝)
5) 上线规范
测试⼈员在某个代码版本上完成测试后(通常完成测试可以认为是没有优先级⾼的BUG即可不需要修改完全部BUG)⽅可上线每⼀次上线都应该⾄少记录BUG FIX List, 新应⽤或者新功能列表，已有功能的修改列表三个表格
上线步骤通常可以分为:1)数据上线 2)应⽤服务上线 3)前端系统上线
可以对数据进⾏适当备份.
执⾏DDL
执⾏DML
执⾏缓存数据的上线
6) 数据上线规范
可以对数据进⾏适当备份.
执⾏DDL
执⾏DML
执⾏缓存数据的上线
7) 应⽤服务上线规范
理清需要上线服曹先生
务的调⽤关系
执⾏底层服务的上线
执⾏上层服务的上线
线上冒烟测试
回归测试(可选)
8) 前端系统上线规范
将静态资源发布到各个前端系统中(nginx、cdn等，没有顺序限制)
线上冒烟测试
回归测试(可选)
9) springcloud项⽬规范
输出类: Result
分页类: Pagination
Result中的code message对应的枚举: ums.CodeMsg
2: 项⽬发布规范说明:
git 的分⽀整体预览图如下。
从上图可以看到主要包含下⾯⼏个分⽀：
master: 主分⽀，主要⽤来版本发布。
develop：⽇常开发分⽀，该分⽀正常保存了开发的最新代码。
feature：具体的功能开发分⽀，只与 develop 分⽀交互。
relea：relea 分⽀可以认为是 master 分⽀的未测试版。⽐如说某⼀期的功能全部开发完成，那么
就将 develop 分⽀合并到relea 分⽀，测试没有问题并且到了发布⽇期就合并到 master 分⽀，进⾏发布。
hotfix：线上 bug 修复分⽀。
3: springboot 项⽬运⾏说明:
添加启动参数: -=merchant-platform-facade 和 -Dhost=192.1标准合同范本
68.1.1 -D log.level=info -=2 -=3
说明:
⽇志⽂件夹名称如: /home/⽤户/logs/merchant-platform-facade/⽇志⽂件
host 服务器的ip地址 ELK⽤来区分那台服务器打印的⽇志
log.level 初始⽇志级别
数据中⼼昆虫记推荐理由
数据中⼼中对应的服务器编号
4: 启动类继承 SpringBootServletInitializer 可以打war包
5: 待续...
10) 属性⽂件中敏感数据加密处理
测试环境和线上环境对数据⽂件中的敏感数据加密处理, 可借助springcloud config加密解密功能
11) ⽤户登录⾏为埋点
待续...
当前阶段爱库存技术选择如下
缓存阿⾥云 redis 集群
数据库RDS 的读写分离
API通信restfulAPI 英文左右
为主
消息队列rocketMQ
⽂件存储 OSS 与 fastDFS (优化抽像可切换)搜索引擎 ElasticSearch
