项目基于 kratos-mono 结构，对现有公司项目“在线教育系统”进行微服务架构改造。系统以学员购买课程，完成学习任务， 统计分析学习数据为主，以课程、班级营销运营为辅，分为用户、课程、班级、题库、资料库、虚拟仿真库、运营、营销、订单、线下活动等 10 个核心模块以及虚拟仿真客户端。
.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数据操作
- 需要在不同模块中注入不同的依赖(
/app/${server_name}/admin运营管理后端微服务/app/${server_name}/job异步工作流服务/app/${server_name}/task任务调度服务/app/${server_name}/interfaceBFF 层，封装组合数据/deploy- 存放一些自动化脚本
- 本地测试使用起来挺方便
pkg- 存放项目下所有服务均可使用的公共代码
- 在这里添加公共代码需要按照规范分好目录层级（语意化），不能一坨放一起
third_party- 存放三方依赖，目前是一些
proto文件 - 查看
third_party/google/app/http.proto可以了解到接口的配置跟参数匹配机制
- 存放三方依赖，目前是一些
app_makefileapp目录下每个服务根路径都会有一个Makefile文件，内部include ../../../app_makefile- 最好不要私自改动
app_makefile,需要添加功能可以在自己维护的服务内的Makefile中添加
Makefile- 整个项目根目录的
Makefile - 维护一些全局的
Makefile命令
- 整个项目根目录的
- 其他目录自行了解
make initdb// 初始化环境make run app=<theServerName>// 运行服务，服务需要先搭建完毕才能启动docker文件位于/deploy目录下，路径不对的自行切换
例：type(scope):本次提交概述 git commit -m "Docs(README.md):添加编码规范"
type: 本次 commit 的类型，诸如 Bugfix Docs Style 等，参考如下:Init：初始化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 // 再合并开发分支在 API Gateway 进行统一的认证拦截，一旦认证成功，我们会使用 JWT 方式通过 RPC 元数据传递的方式带到 BFF 层。BFF 校验 Token 完整性后把身份信息注入到应用的 Context 中，BFF 到其他下层的微服务，建议是直接在 RPC Request 中带入用户身份信息(UserID)请求服务。
user服务：用户信息服务order服务：订单服务course服务：课程服务classroom服务：班级服务questionBank服务：题库服务simulation服务：仿真服务materialLib服务：资料库服务- ....
- 基础服务需要根据业务抛出合适的错误，在
pkg/errors/normal中自定义kratos错误；基础服务应该返回的是kratos错误类型 - BFF层处理(记录日志等操作)具体的错误并返回请求，解析
kratos错误得到具体底层抛出的错误信息:e := errors.FromError(err)
info：记录提示信息
debug：记录调试信息
error: 记录错误信息
fatal: 记录灾难性错误信息
- 配置中心：zookeeper
- 注册中心：
Nacos，记录Nacos单例模式后台地址:http://127.0.0.1:8848/nacos/login = nacos:nacos - 日志系统：ELK
- 链路追踪：jaeger，docker run --rm --name jaeger -p14268:14268-p16686:16686 jaegertracing/all-in-one
- trace: endpoint: http://127.0.0.1:14268/api/traces
- 消息队列：kafka
- 生产推荐
gitlab+k8s+lens - Grpc 测试工具
[bloomrpc](https://github.com/bloomrpc/bloomrpc)[grpcui](https://github.com/fullstorydev/grpcui#installation)(推荐)
- Http 接口测试工具
# courses 课程表
# users 用户表
# orders 订单表 - 记录用户下单，课程、班级都都可看做订单的商品。
# pay_cashflows 支付流水表 - 记录用户支付详情。
# course_members 课程成员表- 用户下单支付成功后，加入到课程成员表中，才有资格访问课程资源
# user_learn_stats 用户学习数据统计，统计用户加入多少课程，完成多少课时任务
# operation 操作记录表，主要用在 admin 后台修改数据的流水信息，用于业务数据"对账"
user/interface addr: 0.0.0.0:8001 -> BFF 分别从 service 和其它服务组合数据，起来返回给调用者
user/service addr: 0.0.0.0:8002 -> 用户主体的微服务 ，获取用户信息等
user/admin addr: 0.0.0.0:8003 -> 运营管理后端服务 修改用户，并保存修改记录
course/interface addr: 0.0.0.0:8011 -> BFF 分别从 service 和其它服务组合数据，起来返回给调用者
course/service addr: 0.0.0.0:8012 -> 课程主体的微服务 ，获取课程列表，获取课程详情，课程学习等
course/admin addr: 0.0.0.0:8013 -> 运营管理后端服务 修改课程，并保存修改记录
order/interface addr: 0.0.0.0:8021 -> BFF 分别从 service 和task 查 用户的订单和支付数据，组合起来返回给调用者
order/service addr: 0.0.0.0:8022 -> 订单主体的微服务 ，查订单，下订单 等
order/admin addr: 0.0.0.0:8023 -> 运营管理后端服务 修改订单，并保存修改记录
order/job addr: 0.0.0.0:8024 -> 从kafka 中捞取订单，把用户加入到课程成员表中
order/task addr: 0.0.0.0:8025 -> 计划任务处理过期未支付订单
由于工作时间原因，只能先搭个架子了，后续会继续完善下去
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent