更优的框架中间件实现
前言
前几个周前前后后阅读了4个go框架(iris、gin、echo、beego)的生命周期,阅读过程中对它们在框架中间件的实现颇有印象,总觉着实现的都不是很完美。为什么呢?
- 使用起来有成本,当你实现一个新的中间件需要人为手动的在业务代码中添加一行
ctx.Next()
代码,目的去执行下一个中间件。 - 阅读代码起来存在障碍,使人不容易理解。感觉第一次想要去了解实现的人,基本会在这个代码实现上懵一会。
- 中间件都是匿名函数的类型,不够面向对象
为什么我会像上面这样说呢?因为,简单说来,这个框架中间件其实就是一个链式调用的过程。然而一想起链式调用的场景,往往我的脑海第一反应就是设计模式中的责任链模式。借助责任链模式的话,一来,我们实现一个新的中间件无需关心手动在业务代码里加上一个Next()
手动调用下一个对象;二来,代码逻辑简单清晰。
首先我们来看看主流go框架中间件实现,再来对比我的框架中间件设计思路。
主流go框架中间件实现分析
beego框架中间件的实现
首先我们来看看beego框架中间件的实现方式,beego对于框架中间件的实现最与众不同(天生的MVC框架),所以我们先来看beego,大家都知道beego在controller接口里定义了一个Prepare()
的发方法,beego提供了一个基础的controller结构,然后实际的业务controller会合成复用这个基础的controller,然后我们再去复写Prepare()
就可以了,通过这个预执行方法可以达到中间件的目的。代码如下:
// 控制器接口 |
但是除了上面之外大家常用的Prepare()
,beego里其实还有一个RunWithMiddleWares
的方法,我们可以当作注册启动前中间件的地方,代码如下:
// 注册中间件 |
iris框架中间件的实现
iris就是很标准的框架中间件,我们来总结下他的具体实现方式。
定义所有中间件的类型:
// 定义了一个Handler类型 匿名函数类型 |
匿名函数注册到类型为slice的中间件属性里:
func (api *APIBuilder) Use(handlers ...context.Handler) { |
http.ServeHTTP执行索引是0的第一个中间件(context.Handler):
// http.ServeHTTP 也就是每次请求都会调这个Do |
第一个匿名函数(中间件)会调用显示的执行ctx.Next()
来下一个中间件,从而构成一个链式调用过程,我摘取了其中一个中间件的部分代码如下,我们可以看见匿名函数最后执行了ctx.Next()
:
return func(ctx context.Context) { |
接着我们来看看ctx.Next()
的具体实现:
// 其实最终ctx.Next()执行的这里 |
gin框架中间件的实现
gin的中间件设计思路大体思路和iris一致,只是具体实现的细节上的和iris不一样,总的来说,一样的地方:
- 中间件实际的类型也是定义的匿名函数
- 中间件的载体也是切片
区别:使用的for循环来判断是否已经执行完所有中间件,而iris是通过if判断。
具体代码如下:
// 同样的匿名函数 注册到类型为slice的中间件属性里 |
echo框架中间件的实现
echo的中间件实现大体思路虽然也是同iris、gin一致,但是呢,是这几个框架里唯一一个构成了所谓的调用链。怎么讲这个区别呢?我们先来回归下iris、gin的中间件:
执行了一个中间件后调用ctx.Next() 通过全局索引去找下一个待执行的中间件并执行
所以说呢,iris、gin的中间件并没有先构成链再执行。而echo的中间件实现做到了这个事情,其实也很简单,echo先通过for循环把下一个待执行匿名函数注入到了当前的匿名函数里,最后再依次执行。我们看下面的代码:
// 第一次遍历返回的匿名函数类型 |
上面我们看完了iris、gin、echo、beego框架中间件的实现方式,最后才开始了本篇文章的正题:
责任链模式下框架中间件的实现
责任链模式的部分概念:把一系列处理对象构成一个链,传递被处理对象的设计。我们借鉴的就是这个设计。
责任链模式的实现很简单,一个对象(Handler)执行(Run())完成自身的业务(Do())之后,判断是否存在下一个对象(nextHandler),如果存在则执行下一个对象(nextHandler.Do())。除此之外我们这个Handler还应该拥有一个设置下一个对象的成员方法。所以,我们这个Handler的uml结构如下:
建模成员 | 成员类型 | 含义 | 抽象程度 | 复用方式 |
---|---|---|---|---|
nextHandler | 成员属性 | 下一个对象 | 具体不变 | 统一定义复用,比如直接继承父类 |
Do | 成员方法 | 自身的业务 | 不同对象不同实现 | 需要抽象(是个抽象方法) |
SetNext | 成员方法 | 设置下一个对象的方法 | 具体不变 | 统一定义复用,比如直接继承父类 |
Run | 成员方法 | 执行当前&下一个对象 | 具体不变 | 统一定义复用,比如直接继承父类 |
理论上按照上面的建模过程,我们可以抽象出一个抽象类,具体的Handler继承这个抽象类,再实现具体的抽象方法Do
即可,无需在再在业务代码中手动调用下一个对象(优雅、低接入成本)。但是由于go中没有继承的概念,又无法满足我们的需求,然而我们可以通过合成复用的方式来尽可能的实现(如果像看可以继承的实现的方式,可以看我的php代码实现https://github.com/TIGERB/easy-tips/blob/master/patterns/chainOfResponsibility/test.php),最终Go合成复用版本的uml图如下:
- 所有业务Handler实现Handler接口
- Next结构体实现了具体的
nextHandler
成员属性、SetNext
成员方法、Run
成员方法 - 业务Handler实现具体的
Do
成员方法,业务Handler合成复用Next的nextHandler
成员属性、SetNext
成员方法、Run
成员方法
所以最终我们要实现的一个新的业务Handler只需要1. 合成复用Next 2.实现具体的Do
,是不是很简单和优雅。接着我们用实际的代码来证明这个的简单、清晰、优雅。
// Context Context |
接着我们看看如何把责任链模式用做框架中间件的实现方式,我们还是用上面的代码实现好的结构体,具体代码如下:
// 初始化一个框架中间件切片 |
总结
框架中间件 | 优点 | 不足 |
---|---|---|
beego’s middleware | 符合php开发者使用框架的习惯 | 中间件概念不够突出,概念不够抽象、隔离 |
iris’s middleware | 执行过程中链式调用、去耦合、复用性高 | 手动Next()、实现不够优雅、执行前未先构成调用链 |
gin’s middleware | 同iris | 同iris、此外用了for循环(for循环里递归代码阅读起来是个坑) |
echo’s middleware | 同iris、先构成链再执行 | 同iris |
我的middleware | 面向对象、链式调用逻辑清晰简单、成本低无需业务代码中手动插入Next()、优雅 | go中无继承概念需要单独实现一个什么也不做的空业务对象,作为链的开端和载体 |