请求context规划
约 646 字大约 2 分钟
2025-04-30
概述
在网关的核心流程中, 会涉及到很多的上下文信息, 这些上下文信息会在整个流程中传递, 因此需要一个统一的上下文信息来管理这些上下文信息。提前规划好请求context的数据结构, 可以方便后续的规划与扩展
context涉及的内容
- 原始请求context: 原始请求的上下文信息，本内容是基于gin实现, 所以便是
*gin.Context - 请求Meta信息: 包含请求的基本信息,
请求方法、请求类型、请求uri、请求Body、请求Header、请求Query、请求cookie, 这一部分数据均是基于原始请求context解析得到的 - 网关接口配置: 网关接口的配置信息, 即核心数据模型总结部分
数据结构汇总, 是网关接口的完整配置
综上, 我们可以得到请求context的数据结构:
// GatewayRequestContext 网关请求上下文
type GatewayRequestContext struct {
RawContext *gin.Context `json:"-" dc:"原始请求上下文"`
RequestMeta *GatewayRequestMeta `json:"request_meta" dc:"请求Meta信息"`
GatewayApiConfig *GatewayApiConfig `json:"gateway_api_config" dc:"网关接口配置,参照前文总结,不额外赘述"`
}
// GatewayRequestMeta 请求Meta信息
type GatewayRequestMeta struct {
Method string `json:"method" dc:"请求方法"`
ContentType string `json:"content_type" dc:"请求类型"`
Uri string `json:"uri" dc:"请求uri"`
Body map[string]any `json:"body" dc:"请求Body"`
Header map[string]any `json:"header" dc:"请求Header"`
Query map[string]any `json:"query" dc:"请求Query"`
Cookie map[string]any `json:"cookie" dc:"请求cookie"`
}关于 header/cookie/query 类型说明
大家都有常识,这三处的数据被程序独到的一定是string数据类型,那么为什么使用map[string]any类型呢?
原因在于, 后续会对这些数据进行验证转换, 原始类型是string, 但是按照 gateway_api_param 表中的数据类型, 可能是int, float, bool, 所以需要使用map[string]any类型来存储, 方便后续的验证转换。
举例: 我们常见内部接口通信中, 可能在header中携带一个X-User-Id字段, 这个只是通过某一算法，如雪花等生成的ID, 从Header独到的数据一定是字符串, 但是 gateway_api_param 表中配置的是 uint64 类型, 则最终存储uint64。
注意
当前GatewayRequestContext是核心数据结构, 是绝对不可确实的配置, 后续随着进度演进, 可能会增加一些字段, 但是绝对不可删除本文中列出字段, 否则会导致网关无法正常运行。