基于kitex和hertz的微服务demo搭建（上）| 青训营笔记

这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天，记录一下基于 kitex 和 hertz 的微服务 demo 搭建流程。

技术选型

组件	选型	原因
api 网关	nginx	部署方便，性能高
注册中心	nacos	部署方便，kitex 支持
配置中心	nacos	不用额外再部署新的配置中心
RPC 调用	kitex	功能强大，有较多的扩展
HTTP 服务	hertz	性能高，有较多的扩展

关于服务治理与监控的相关组件暂时先不考虑，后续会逐步添加进来。

项目结构

 |-- service_demo            // 具体的服务模块
     |-- user                // 用户模块
     |-- media               // 媒体模块
     |-- hello               // 测试模块
     ...                     // 其他模块
 |-- service_demo_common     // 公共模块
 |-- service_demo_idls       // rpc调用的idl以及kitex生成的代码
     |-- user                // 用户模块的idl
     |-- media               // 媒体模块的idl
     |-- hello               // 测试模块的idl
     ...                     // 其他模块的idl

其中测试模块没有业务逻辑，只是简单的串联各个组件，类似于一个模板。

公共模块

公共模块主要是一些工具函数以及公共的结构体，比如统一的 http 返回结构体。

 type Response struct {
     Code uint `json:"code"`
     Msg string `json:"msg"`
     Data any `json:"data"`
 }
 ​
 func SuccessResponse(data any) *Response {
     return &Response{0, "success", data}
 }

Idl 模块

这里为了方便，把所有模块的 idl 都放到了一个 github 仓库中了。每个模块都有自己的 go.mod 文件，发布 release 版本时，版本号前面需要带上模块名，这样就可以通过 go get 拉取特定的模块了。如 hello 模块的 go.mod 文件中定义了module github.com/joker-star-l/service_demo_idls/hello，则发布 release 的一个版本号可以是hello/v0.0.1（详见代码仓库）。

这里本来是想只存储 idl 的，kitex 生成的代码借助 github 的 ci/cd 功能来做。但是 go mod 不像 java 的 maven 或者 js 的 npm 一样可以有脱离于 github 的仓库，生成的代码还是要放在 github 上，因此这里没有使用 github 的 ci/cd，而是本地生成后推上去的。

服务模块

每个服务可能会同时存在 http 的服务端以及 kitex 的服务端，http 服务端处理客户端（经过 gateway）发来的请求，kitex 的服务端处理服务间的 rpc 调用。