/kratos-mono

基于Kratos的集中式仓库项目模版

Primary LanguageGoMIT LicenseMIT

Kratos-Mono-Repo

前置条件

  • Kratos docker docker-compose 正确安装

启动

  1. make initdb // 初始化环境
  2. make run app=yourServerName // 运行服务，服务需要先搭建完毕才能启动
  3. docker文件位于/deploy目录下，路径不对的自行切换

新增服务

  • 新增payment服务: make app name=yourServerName
以上脚本仅仅帮助我们创建目录，具体的go文件需要我们自己处理，官方也并不提供相关的工具
关于每个目录的作用，可以参考user || shop 服务,临时的脚本，后面再优化

错误处理

  1. 基础服务需要根据业务抛出合适的错误，在pkg/errors/normal中自定义kratos错误；基础服务应该返回的是kratos错误类型
  2. BFF层解析kratos错误得到具体底层抛出的错误信息:e := errors.FromError(err)
  3. 应该在错误 第一次产生的地方 输出对应的日志信息（处理），底层错误往上传递的过程中无需再处理（即同一错误只需处理一次即可）

服务拆分 （按照业务拆分，服务间通过接口通讯）

  1. 示例服务仅包含一个user服务
  2. shop服务充当BFF聚合层，没有DB没有复杂业务操作
  3. 以上是Demo功能列表（没有全部实现）
设计指导**：
对于外网的请求来说，我们通常在 API Gateway 
进行统一的认证拦截，一旦认证成功，我们会使
用 JWT 方式通过 RPC 元数据传递的方式带到
BFF 层，BFF 校验 Token 完整性后把身份信息
注入到应用的 Context 中，BFF 到其他下层的微
服务，建议是直接在 RPC Request 中带入用户
身份信息(UserID)请求服务。
----
经过实践发现，接口请求的业务相关的参数显式由Request传递则扩展性更优（可同时更好支持http与rpc调用），更清晰
  • 依赖倒置
    • 使用wire维护依赖注入 (/service/cmd/server/wire.go)
    • 可以观察/service/cmd/server/wire_gen.go 中的代码。 看到各个依赖之间的调用顺序
模块权责

  • .vscode

    • 个人配置喜好，已经添加到.gitignore，只上传首次

  • /api

    • 与app目录的服务一一对应，维护各个服务的proto文件与生成的源码
    • 内部服务一般只需定义rpc接口，BFF 服务则需要定义option (google.api.http)
    • 也可以去掉/api目录，就像kratos提供的单例服务layout一样，将api/放到app目录内独立维护

  • /app/${server_name}/service/internel/

    • 需要在不同模块中注入不同的依赖(ProviderSet)
    • BIZ， 业务组装，定义数据操作方法，供Service层调用
    • Data，实现数据库/缓存等能力，实现Biz定义的接口，供BIZ层调用
    • Conf，解析../../configs内的yaml配置文件，供Data Server使用（这两个目录会进行一些服务初始化需要用到配置信息，内含监听配置文件简单用法）
    • Server，服务注册，提供服务初始化依赖注入
    • Service，校验数据，调用BIZ组装好的用例，实现GRPC接口
    • 各个模块不能乱跨模块调用: Service实现RPC ==> Biz定义数据操作方法并组装业务 ==> Data数据操作

  • /deploy

    • 存放一些自动化脚本
    • 本地测试使用起来挺方便

  • pkg

    • 存放项目下所有服务均可使用的公共代码，这也是集中式管理的好处之一
    • 在这里添加公共代码需要按照规范分好目录层级（语意化），不能一坨放一起

  • third_party

    • 存放三方依赖，目前是一些proto文件
    • 查看third_party/google/app/http.proto可以了解到接口的配置跟参数匹配机制

  • app_makefile

    • app目录下每个服务根路径都会有一个Makefile文件，内部 include ../../../app_makefile
    • 最好不要私自改动app_makefile,需要添加功能可以在自己维护的服务内的Makefile中添加

  • Makefile

    • 整个项目根目录的Makefile
    • 维护一些全局的Makefile 命令

  • 其他目录自行了解

其他

  • 目前有配套后台管理的consul nacos

  • 服务注册与发现使用Nacos，记录Nacos单例模式后台地址:http://127.0.0.1:8848/nacos/ login = nacos:nacos

  • 生产推荐 gitlab+k8s+lens

  • 测试工具

Commit 规范

格式如下

  • 例：type(scope):本次提交概述 git commit -m "docs(README.md):添加编码规范"

  • type: 本次 commit 的类型，诸如 bugfix docs style 等，参考如下:

    • feat：添加新功能
    • fix：修补缺陷
    • docs：修改文档
    • style：修改格式
    • refactor：重构
    • perf：优化
    • test：增加测试
    • chore：构建过程或辅助工具的变动
    • revert：回滚到上一个版本
    • merge：合并

  • scope: 本次 commit 波及的范围

  • subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点：

    1. 使用祈使句
    2. 首字母不要大写
    3. 结尾无需添加标点
分支记录
  • dev：开发版 prod：发布版 stage：稳定版
  • 命令记录：
git checkout -b dev   // 新建分支
git push origin dev   // 推送新分支到线上
git branch -d dev     // 删除本地分支
git push origin :dev  // 删除远程分支,需要设置权限

git checkout pro // 切换到发布分支
git  merge dev   // 再合并开发分支