这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
前言
在上一篇文章中，我简单的说明了一下我们这次项目的架构：
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 // 项目介绍（待补充）
但是这是整个项目的整体框架，今天这篇文章我梳理了一下具体到网关和微服务部分的目录设计
这个目录设计我参考了我先前写的golang项目，以及字节跳动Kitex的官方demo，还有Hertz的官方demo
但是个人认为还是有很大的上升空间，我感觉在一些请求包装处理上可以做的更好
网关
这部分是负责HTTP与微服务之间的衔接
网关部分在我认为需要满足这些要求：
- 与微服务建立通信
- 限流
- 拆封请求，打包返回数据
- 负载均衡
在网关部分，我的设计暂时如下
tiktok/
├── api-gateway // 网关
│ ├── biz // 核心
│ ├── handler // HTTP处理
│ ├── model // 模型
│ ├── router // 路由
│ ├── rpc // RPC
├── main.go // 程序入口
├── Makefile // 常用指令
├── router.go
├── router_gen.go
通常来说，对于一个HTTP请求，首先会到达路由，路由分发到handler，再由handler拆解请求与rpc服务进行通讯
可以注意到我这里是没有鉴权部分的，我参考了某些公司会使用到的用户中台，也就是说，把用户鉴权、信息、注册登录等融合成一个项目，其他项目会与这个项目进行交互
结合到RPC部分，我就把鉴权部分丢给了user服务，让user服务当作一个小的”用户中台“
微服务
我们队伍由我担任队长，我是负责网关部分的设计，其余队友负责实现微服务
因此微服务部分目录结构没有做到完全统一，但是大部分差距不大
这里以我参与度较高的user服务为例，因为涉及到鉴权部分，我对user服务做了一些个人修改，也就是说，这个不是队友自己写的
user/
├── kitex_gen // Kitex生成代码，后续迁移到根目录
├── client // 客户端测试代码，会在开发完毕后删除
├── configs // 微服务启动配置，包括数据库连接
├── service // 微服务实际处理模块
├── model // 自定义结构体
├── script // 编译指令
├── main.go // 程序入口
├── handler.go // 请求处理
├── kitex.yaml // kitex配置
├── Makefile // 常用指令
这是大部分微服务的结构吧
请求首先会在handler.go部分进行处理，handler部分先对请求进行处理，然后把请求转发到service层，在service层完成数据库交互/token生成等内容
总体请求思路
HTTP <-> API Gateway <-> Microservices
然后在Gateway和Microservices层再对请求做分层拆封处理
网关和微服务应该是各自分了3层，也就是一个请求应该会经过6个层面
其实并不清楚分层的原因究竟是什么，但是我分层后代码结构明显清晰了非常多，而且写起来效率更高。
还是要继续学习啊
