Kratos-Mono-Repo
前置条件
Kratosdocker docker-compose正确安装
启动
make initdb// 初始化环境make run app=yourServerName// 运行服务，服务需要先搭建完毕才能启动docker文件位于/deploy目录下，路径不对的自行切换
新增服务
- 新增
payment服务:make app name=yourServerName
以上脚本仅仅帮助我们创建目录，具体的go文件需要我们自己处理，官方也并不提供相关的工具
关于每个目录的作用，可以参考user || shop 服务,临时的脚本，后面再优化
错误处理
- 基础服务需要根据业务抛出合适的错误，在
pkg/errors/normal中自定义kratos错误；基础服务应该返回的是kratos错误类型 - BFF层解析
kratos错误得到具体底层抛出的错误信息:e := errors.FromError(err) - 应该在错误 第一次产生的地方 输出对应的日志信息（处理），底层错误往上传递的过程中无需再处理（即同一错误只需处理一次即可）
服务拆分 （按照业务拆分，服务间通过接口通讯）
- 示例服务仅包含一个
user服务 shop服务充当BFF聚合层，没有DB没有复杂业务操作- 以上是
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_makefileapp目录下每个服务根路径都会有一个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的主旨，在原文中特意强调了几点：- 使用祈使句
- 首字母不要大写
- 结尾无需添加标点
分支记录
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 // 再合并开发分支