Context请求控制器
添加上下文 设置超时时间
从主流程中我们知道(第三层关键结论),HTTP 服务会为每个请求创建一个 Goroutine 进行服务处理
在服务处理的过程中,有可能就在本地执行业务逻辑,也有可能再去下游服务获取数据
逻辑链条中,每个本地处理逻辑,或者下游服务请求节点,都有可能存在超时问题。而对于 HTTP 服务而言,超时往往是造成服务不可用、甚至系统瘫痪的罪魁祸首
系统瘫痪也就是我们俗称的雪崩,某个服务的不可用引发了其他服务的不可用
如果服务超时,导致请求处理缓慢甚至不可用,加剧了 Goroutine 堆积,同时也造成了服务的请求堆积,Goroutine 堆积,瞬时请求数加大,
导致服务都不可用,整个系统瘫痪。
最有效的方法就是从源头上控制一个请求的“最大处理时长”,所以,对于一个 Web 框架而言,“超时控制”能力是必备的。
观察官方库提供的函数
go doc context | grep "^func"
// 创建退出 Context
func WithCancel(parent Context) (ctx Context, cancel CancelFunc)
// 创建有超时时间的 Context
func WithDeadline(parent Context, d time.Time) (Context, CancelFunc)
// 创建有截止时间的 Context
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)
WithCancel 直接创建可以操作退出的子节点,
WithTimeout 为子节点设置了超时时间(还有多少时间结束),
WithDeadline 为子节点设置了结束时间线(在什么时间结束)。
通过定时器来自动触发终结通知”,WithTimeout 设置若干秒后通知触发终结,WithDeadline 设置未来某个时间点触发终结。
为一个父节点生成一个带有 Done 方法的子节点,并且返回子节点的 CancelFunc 函数句柄
Context数据结构分析
type Context interface {
Deadline() (deadline time.Time, ok bool)
// 当 Context 被取消或者到了 deadline,返回一个被关闭的 channel
Done() <-chan struct{}
Err() error
Value(key interface{}) interface{}
}
//函数句柄
type CancelFunc func()
context 标准库设计思路
在整个树形逻辑链条中,用上下文控制器 Context,实现每个节点的信息传递和共享
用 Context 定时器为整个链条设置超时时间,时间一到,结束事件被触发,链条中正在处理的服务逻辑会监听到,从而结束整个逻辑链条,让后续操作不再进行。
一个节点其实有两个角色:一是下游树的管理者;二是上游树的被管理者
一个是能让整个下游树结束的能力,也就是函数句柄 CancelFunc;
另外一个是在上游树结束的时候被通知的能力,也就是 Done() 方法。同时因为通知是需要不断监听的,所以 Done() 方法需要通过 channel 作为返回值让使用方进行监听
CancelFunc 是主动让下游结束,而 Done 是被上游通知结束。
context是怎样产生得
Context 在哪里产生?它的上下游逻辑是什么?
每个连接的 Context 最终是放在 request 结构体中的
Context 已经有多层父节点。因为,在代码中,每执行一次 WithCancel、WithValue,就封装了一层 Context
Context 从哪里产生这个问题,我们就解决了,但是如果我们想要对 Context 进行必要的修改,还要从上下游逻辑中,找到它的修改点在哪里。
生成最终的 Context 的流程中,net/http 设计了两处可以注入修改的地方,都在 Server 结构里面,一处是 BaseContext,另一处是 ConnContext。
BaseContext 是整个 Context 生成的源头,如果我们不希望使用默认的 context.Backgroud(),可以替换这个源头。
而在每个连接生成自己要使用的 Context 时,会调用 ConnContext ,第二个参数是 net.Conn,能让我们对某些特定连接进行设置,比如要针对性设置某个调用 IP。
要自定义,不是想直接使用标准库的 Context,因为它完全是标准库 Context 接口的实现,只能控制链条结束,封装性并不够。但是只有先搞清楚了 context 标准库的设计思路,才能精准确定自己能怎么改、改到什么程度合适
type Server struct {
// BaseContext 用来为整个链条创建初始化 Context
// 如果没有设置的话,默认使用 context.Background()
BaseContext func(net.Listener) context.Context{}
// ConnContext 用来为每个连接封装 Context
// 参数中的 context.Context 是从 BaseContext 继承来的
ConnContext func(ctx context.Context, c net.Conn) context.Context{}
}
简单的网络获取解析
返回查询字符串和请求实体
//解析所有请求数据
r.ParseForm()
//获取所有请求数据
r.Form()
//是一个包含所有请求数据的字典类型(map),包含 URL 查询字符串和 POST 请求数据
//request 对象上的 Form 可以获取所有请求参数,包括查询字符串和请求实体,并且不限请求类型。如果你想要进一步要获取指定的参数值,可以以索引方式获取指定参数对应的值,也可以通过 Form 提供的 Get 方法,就像我们从一个普通字典类型获取键值一样
id1 := r.Form["id"] //字符串切片
id2 := r.Form.Get("id") //字符串值
只想获得请求实体(只包含了 POST 表单请求数据,不包含 URL 查询字符串)
func EditPost(w http.ResponseWriter, r *http.Request) {
r.ParseForm()
fmt.Println("form data:", r.PostForm)
}
获取用户请求数据
FormValue/PostFormValue
func EditPost(w http.ResponseWriter, r *http.Request) {
fmt.Println("post id:", r.FormValue("id"))
fmt.Println("post title:", r.PostFormValue("title"))
fmt.Println("post title:", r.PostFormValue("content"))
io.WriteString(w, "表单提交成功")
}
获取用户请求数据,使用它们的好处是不再需要单独调用 ParseForm 对表单数据进行解析,
不过使用这两个方法的时候只能获取特定请求数据,不能一次获取所有请求数据
FormValue/PostFormValue 的区别和 Form/PostForm 一样,
这里通过命名就可以看出来,前者可以获取所有 GET/POST 请求数据(即查询字符串和请求实体),后者只能获取 POST 请求实体数据
只能解析通过 application/x-www-form-urlencoded 编码的数据。
封装一个Context
我们需要有更强大的 Context,除了可以控制超时之外,常用的功能比如获取请求、返回结果、实现标准库的 Context 接口,也都要有。
未自定义的控制器代码
// 控制器
func Foo1(request *http.Request, response http.ResponseWriter) {
obj := map[string]interface{}{
"data": nil,
}
// 设置控制器 response 的 header 部分
response.Header().Set("Content-Type", "application/json")
// 从请求体中获取参数
foo := request.PostFormValue("foo")
if foo == "" {
foo = "10"
}
fooInt, err := strconv.Atoi(foo)
if err != nil {
response.WriteHeader(500)
return
}
// 构建返回结构
obj["data"] = fooInt
byt, err := json.Marshal(obj)
if err != nil {
response.WriteHeader(500)
return
}
// 构建返回状态,输出返回结构
response.WriteHeader(200)
response.Write(byt)
return
}
调用了 http.Request 和 http.ResponseWriter ,实现 WebService 接收和处理协议文本的功能。
但这两个结构提供的接口粒度太细了,需要使用者非常熟悉这两个结构的内部字段
将这些内部实现封装起来,对外暴露语义化高的接口函数,易用性就会提升
// 控制器
func Foo2(ctx *framework.Context) error {
obj := map[string]interface{}{
"data": nil,
}
// 从请求体中获取参数
fooInt := ctx.FormInt("foo", 10)
// 构建返回结构
obj["data"] = fooInt
// 输出返回结构
return ctx.Json(http.StatusOK, obj)
}
controller.go 实现
封装标准的Context库
标准库的 Context 通用性非常高,基本现在所有第三方库函数,都会根据官方的建议,将第一个参数设置为标准 Context 接口。
所以我们封装的结构只有实现了标准库的 Context,才能方便直接地调用。
自己封装的 Context 最终需要提供四类功能函数:
base 封装基本的函数功能,比如获取 http.Request 结构
context 实现标准 Context 接口
request 封装了 http.Request 的对外接口
response 封装了 http.ResponseWriter 对外接口
context.go实现
为单个请求设置超时
封装了自定义的 Context,从设计层面实现了标准库的 Context。为单个请求提供超时逻辑
继承 request 的 Context,创建出一个设置超时时间的 Context;
创建一个新的 Goroutine 来处理具体的业务逻辑;
设计事件处理顺序,当前 Goroutine 监听超时时间 Contex 的 Done() 事件,和具体的业务处理结束事件,哪个先到就先处理哪个。