tik 命令行工具 出发点

• 简化重复工作
• 统一开发习惯
• 为后面跟多自动化做支持

通过命令行工具初始化项目

tik create xxx

会根据提前准备好的模板创建目录，后续大家可以一起维护这个模板

仪式感的更新版本号

tik release

选择更是的尺度是 patch,feature,major

生成容器运行管理相关的配置文件

tik ci

这个会生成

docker-compose.yml, 容器相关

rancher-compose.yml, 编排相关

build, 镜像构建脚本

upgrade 服务升级脚本

此处可以提问

后续会继续完善做到完全自动发布。

项目模板的改造关键点

• env代替config

开发本地使用dotenv来进行配置，

打包运行后依赖容器的环境变量

这样可以使代码更加“无状态”，配置管理更方便

所以要求代码中有用到外部变量的都使用 process.env.XXX 方式

• /midlerwares 通用型中间件

  • cors
  • error_handler

  兜底所有没有被catch的错误，建议业务上面尽量定义完整错误列表，此处只处理未定义的错误

  • traceId

  串联上下游调用关系，后续日志统一收集后可以很好追踪链路

• /utils 通用型工具箱

  • common_field

  Mongoose 插件式公共字段，在定义schema的地方使用

  • logger log4js

  避免使用console.log, 会阻塞

  因为在app.js里已经挂到global

  因此可以直接使用 log.info, log.warn, log.error, 日志信息会通过stream输出到指定文件

  • mongo

  一般不会引用，只会在 app.js 引用一次创建链接

  • redis

  只返回一个连接成功的 promise 化的redis-client,

  如果需要针对业务特点进行封装，请在src里自行设计，此处不限制太多。

  • response

  重点！ 定义了success和error两个方法，

  但是不提倡用中间件注册到ctx，

  一来ctx每次会被销毁，二来希望统一一种方式处理返回

  所以controller内部引入这个模块，使用 success / error处理结果。

  使用 response.error 的时候不需要 单独 记录。

• test 测试

主体架构是 ava + superkoa(supertest)

测试样例已经提供，可以照着写

package.json 已经写好，直接运行npm test即可

• src 业务相关的代码

  • /src/router.js

  这个文件不需要更改，请勿改动。

  它会自动读取内层的 router 注册到 app

  • /src/{module}/v1 具体的业务逻辑集合

  {module}主要是方便在一个系统内部在逻辑上归纳出几个部分，更多的时候因为服务拆分得足够小，只会有一两个module

  版本：这个 v1,v2 只是方便临时出现多版本兼容。常规来说应该在集群里启动不同版本的实例，通过反向代理实现多版本。 重点

  • /src/{module}/v1

  相对来说这层是业务强相关的，但还是提供了一点点约束

  controllers, middlewares,models,router.js 这些望文生义很好理解，简单看一下初始化的样例代码。

  需要特别提醒一下，区别于最外面的middlewares，这一层的更偏重于具体业务。

  • error.js 是一个需要统一思路的环节。

  请参考样例代码来定义错误，这样可以在直接throw的时候有更好的统一处理。

  错误码的规则，XXXYYY, 3位http语义分类，3位错误序列。调用方收到的是10位错误码，因为最前面还会加 4位 APPID

  如

  1001404001 USER_NOT_FOUND

  1001500002 INTERNAL_ERROR_2