这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
今天来梳理一下自己对这个大项目的理解，正好为下一阶段的开发做一个总结
这里丢一个飞书文档：f522v7rdpa.feishu.cn/docx/VUESdX…
这是我自己写的，给队内队友参考的文档，其中包含了分工、项目设计与问题解决
如果你愿意对文档进行优化，欢迎提供一些帮助！
技术选型
Web与RPC框架
和学长们探讨了一下，再结合我自身的过往项目开发经历，RPC和HTTP的框架可以选择如下：
Kratos
这是Bilibili的微服务框架
这个框架是我在学校考核时写项目选用的一个微服务框架，他直接结合了HTTP和gRPC
也就是说，正常开发的话，可以只用这一个框架就能开发出一个完整的项目，同时，他还兼顾：
- 资料较多
- 官方文档齐全
- 自己写了demo视频，从零开始写demo，对代码指导提供了很大帮助
但是，他同时也是有缺点的
- 这个框架我已经使用过了
- 个人感觉可操控性感觉不大，框架限定比较死
- 更适合无网关的单微服务项目？
go-zero
这个是工作室内现役成员推荐的，他的一个最大的特性就是
历史相对悠久，同时资料齐全
也就是说上手难度低
实际上，在我个人理解上，go-zero与Kratos相似度还是比较大的
Kitex + Hertz
这是字节跳动的RPC框架与Web框架
我们组最终选定了使用Kitex + Hertz来开发。
Kitex与Hertz出现较晚，目前网上的资料很少，主要以看官方文档为主要的学习途径
工作室在字节实习的学长分析，在内部使用时会遇到不少的问题，但是可以通过内网搜索或者直接call技术来解决
对于我们没有内网权限的人来说就是技术资料少、bug可能需要自己解决。
综上，优点如下
- 字节跳动开发的框架，对于字节自己的青训营来说可能有优势
- 分析框架可以发现，字节的这两个框架性能较为优秀
- 可以夯实自己的学习
但是，他也具有这些缺点
- 资料很少，以官方文档资料为主
- 可能会有隐藏的Bug
- 对Windows兼容性很差
我自己是macOS的系统，但是队内队友是windows，我们最后各自发表了一下自己的观点：大家都想把这个项目好好做完，而不是当作一个作业
所以我们拍板了，资料就算少我们也要用Kitex和Hertz实现项目！即使到后面出现了部分队友放弃、摆烂的情况，但这也是可预料内的情况。
不过吐槽一下，Kitex在Win下的兼容的确是不太好的。。
ORM
我们选择了gorm，这是一个蛮优秀的框架，同时考虑到队友大多是java转go，如果学习其他的框架的话，成本过高（因为前面已经选择了字节的Kitex与Hertz），这部分大家还是相对一致的使用了gorm
其他选型
鉴权
我们选择了jwt-token，比较常见，网上资料也较多
IDL
我们选择了Protobuf3，而不是字节的Thrift，综合考量下来，Protobuf3的资料相对来说还是更多的，同时我（队长）本人也在先前的考核中使用过Protobuf，对Protobuf还是相对熟悉的
服务发现
使用etcd，队友这部分不熟悉，只能由我来布置任务，考虑到队友不熟，工作室成员对etcd比较熟，我就拍板etcd了
数据库ID
我们使用雪花算法，我对项目内置了Snowflake类，同时也给队友提供了参考代码实现，这部分还是比较统一的
项目结构
这里以tree的形式来表示
tiktok/
├── api-gateway // 网关
├── idl // IDL
├── pkg // 库代码
│ ├── errno // 错误处理
│ ├── configs // 初始化配置
│ ├── constants // 全局常量
│ ├── utils // 通用函数
├── services // 服务模块
│ ├── video // 视频模块
│ ├── comment // 评论 & 点赞模块
│ ├── user // 用户模块
│ ├── follow // 关注模块
│ └── chat // 聊天模块
├── postman // Postman配置
├── docs // 文档（待补充）
├── docker-compose.yaml // Docker开发环境配置
└── README.md // 项目介绍（待补充）
结构其实相对还是简单的，这里可以以文本和图片的描述来给出整个项目的运行
服务原理
也就是说，客户端发送HTTP请求，会在中间网关部分完成过滤筛选，网关再把服务分发给其他微服务来执行
阶段总结
目前我们实现了基本的框架配置，在未来几天重心就是继续开发好服务，然后完善网关与服务的对接
最终就是联调，实现项目的可运行化
