大家好,我是渔夫子。本号新推出「Go工具箱」系列,意在给大家分享使用go语言编写的、实用的、好玩的工具。同时了解其底层的实现原理,以便更深入地了解Go语言。
路由,就是url地址到业务处理代码的映射。当用户输入一个url地址时,服务器该知道该用户返回什么内容。比如,当用户点击登录时,服务器应该做登录相关的事情,并给用户返回登录成功或失败的页面。当用户点击退出时,服务器应该做和退出相关的事情(比如清理用户登录的数据),并返回给用户退出之后的页面。
一个url到一个具体的处理函数之间的映射叫做一条路由。
多条路由组成路由表。路由表主要用于路由查找,根据不同的路由表的组织形式,可以有不同的查找方法。最简单的路由表就是使用map。直接以key-value的形式进行匹配即可。
给定一个url,找到对应的处理函数的过程叫做路由查找。路由器就是用来管理路由表以及进行路由查找的。
所以,在web系统中一个路由系统由路由、路由表、路由匹配三部分功能组成。
go内建标准包net/http中路由的实现是基于映射表实现的。也是最简单的路由实现。本节我们就来看来http请求的处理流程以及内建包默认的路由实现原理。
首先,我们来看下http包是如何处理请求的。通过以下代码我们就能启动一个http服务,并处理请求:
import (
"net/http"
)
func main() {
// 指定路由
http.Handle("/", &HomeHandler{})
// 启动http服务
http.ListenAndServe(":8000", nil)
}
type HomeHandler struct {}
// 实现ServeHTTP
func (h *HomeHandler) ServeHTTP(response http.ResponseWriter, request *http.Request) {
response.Write([]byte("Hello World"))
}
当我们输入http://localhost:8000/的时候,就会走到HomeHandler的ServeHTTP方法,并返回Hello World。
那这里为什么要给HomeHandler定义ServeHTTP方法呢?或者说为什么会走到ServeHTTP方法中呢?
我们顺着http.ListenAndServe方法的定义:
func ListenAndServe(addr string, handler Handler) error
发现第二个参数是个Handler类型,而Handler是一个定义了ServeHTTP方法的接口类型:
type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}
似乎有了一点点关联,HomeHandler类型也实现了ServeHTTP方法。但我们在main函数中调用http.ListenAndServe(":8000", nil)
的时候第二个参数传递的是nil,那HomeHandler里的ServeHTTP方法又是如何被找到的呢?
我们接着再顺着源码一层一层的找下去可以发现,在/src/net/http/server.go的第1930行有这么一段代码:
serverHandler{c.server}.ServeHTTP(w, w.req)
有个serverHandler结构体,包装了c.server。这里的c是建立的http连接,而c.server就是在http.ListenAndServe(":8000", nil)函数中创建的server对象:
func ListenAndServe(addr string, handler Handler) error {
server := &Server{Addr: addr, Handler: handler}
return server.ListenAndServe()
}
server中的Handler就是http.ListenAndServe(":8000", nil)传递进来的nil。
好,我们进入 serverHandler{c.server}.ServeHTTP(w, w.req)
函数中再次查看,就可以发现如下代码:
func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) {
handler := sh.srv.Handler
if handler == nil {
handler = DefaultServeMux
}
...
handler.ServeHTTP(rw, req)
}
/src/net/http/server.go的第2859行到2862行,就是获取到server中的Handler,如果是nil,则使用默认的DefaultServeMux,然后调用了hander.ServeHTTP方法。
继续再看DefaultServeMux中的ServeHTTP方法,在/src/net/http/server.go中的第2416行,发现有一行h,_ := mux.Handler(r)和h.ServeHTTP方法。这就是通过请求的路径查找到对应的handler,然后调用该handler的ServeHTTP方法。
func (mux *ServeMux) ServeHTTP(w ResponseWriter, r *Request) {
if r.RequestURI == "*" {
if r.ProtoAtLeast(1, 1) {
w.Header().Set("Connection", "close")
}
w.WriteHeader(StatusBadRequest)
return
}
h, _ := mux.Handler(r)
h.ServeHTTP(w, r)
}
在一开始的实例中,就是我们的HomeHandler的ServeHTTP方法。也就是说ServeHTTP方法是net/http包中规定好了要调用的,所以每一个页面处理函数都必须实现ServeHTTP方法。
同时也说明,net/http包中的路由是在DefaultServeMux对象中实现的,该对象是一个ServeMux结构体类型,接下来我们看ServeMux路由的具体实现。
在net/http包中实现路由的机构提是ServeMux,其结构定义如下。
type ServeMux struct {
mu sync.RWMutex
m map[string]muxEntry
es []muxEntry // slice of entries sorted from longest to shortest.
hosts bool // whether any patterns contain hostnames
}
结构体字段很简单,我们重点看m变量,是一个map类型,即key-value结构,就是我们所说的路由表。key就是路由的路径,value是一个muxEntry对象,muxEntry结构如下:
type muxEntry struct {
h Handler
pattern string
}
pattern是对应的路径,h就是对应的处理函数。当我们调用http.Handle("/", &HomeHandler{})�
进行路由注册时候,实质上就是将路径和HomeHandler对象构建成一个muxEntry对象,然后加入到ServeMux的m中。
image.png
接下来我们再看路由的查找,既然路由表是有map实现的,那么路由的查找过程自然就是通过路径从map中查找对应的muxEntry,然后获取对应的handler即可。该实现就是在/src/net/http/server.go中的第2416行的mux.Handler(r)进行的。
以上就是net/http包中自己路由的实现。非常简单,同时也意味着功能有限。比如不能对路由进行分组、不能限定路由的请求方法(GET、POST或其他)、不能对路由加中间件等等。 这也就给第三方包提供了再次实现的机会。
该包是基于正则表达式实现的路由。该路由支持分组、restful风格路径的定义、绑定路由请求的方法(GET、POST等)、限定路径使用http还是https协议等功能。我们看下其基本情况。
gorilla/mux小档案 | |||
---|---|---|---|
star | 17.8k | used by | 88.7k |
contributors | 97 | 作者 | gorilla |
功能简介 | 一个强大的http路由。支持路由分组、restful风格路径定义、限定请求方法及http协议、处理静态文件等功能。 | ||
项目地址 | https://github.com/gorilla/mux |
由于该包支持的路由规则比较多,所以我们先从最简单的例子开始看一下基本使用,然后再通过分析其实现原理看各种规则是如何支持的。
package main
import (
"fmt"
"net/http"
"github.com/gorilla/mux"
)
func main() {
r := mux.NewRouter()
r.HandleFunc("/", HomeHandler)
r.HandleFunc("/products", ProductsHandler)
//定义restful风格的路径,例如/product/12345
r.HandleFunc("/product/{id:[0-9]+}", ProductHandler)
http.ListenAndServe(":8000", r)
}
func HomeHandler(response http.ResponseWriter, request *http.Request) {
response.Write([]byte("Hi, this is Home page"))
}
func ProductsHandler(response http.ResponseWriter, request *http.Request) {
response.Write([]byte("Hi, this is Product page"))
}
func ProductHandler(response http.ResponseWriter, request *http.Request) {
vars := mux.Vars(request)
// 获取产品的ID值。
id := vars["id"]
response.Write([]byte("Hi, this is product:" + id))
}
首先我们通过mux.NewRouter()方法返回了一个Router结构体对象。该结构体对象也实现了ServeHTTP方法,在该方法中实现了对路由的匹配和转发。所以覆盖作为http.ListenAndServe的第二个参数,替代了默认的路由分发对象DefaultServeMux。以下展示了Router的ServeHTTP方法对路由的匹配和分发部分的代码,其他代码省略。
func (r *Router) ServeHTTP(w http.ResponseWriter, req *http.Request) {
...
var match RouteMatch
var handler http.Handler
// 路由匹配
if r.Match(req, &match) {
handler = match.Handler
req = requestWithVars(req, match.Vars)
req = requestWithRoute(req, match.Route)
}
...
// 路由分发
handler.ServeHTTP(w, req)
}
本质上是和默认的路由分发器DefaultServeMux的实现是一样的。不同的是路由的管理以及匹配上。
接下来我们看下Router结构体。如下:
这里我们只列出来核心的字段,省略了一些辅助字段。这里有几个主要的字段:
routeRegexp结构体中的主要字段分别如下:
r.HandleFunc("/product/{id:[0-9]+}", ProductHandler)
中,则是"/product/{id:[0-9]+}"
r.HandleFunc("/product/{id:[0-9]+}", ProductHandler)
就是路径匹配regexpTypePath。而r.Host("www.example.com")
就是域名匹配regexpTypeHost。稍后我们会一一介绍。"/product/{id:[0-9]+}"
为例,最终构造的正则表达式是 ^/product/(?P<v0>[0-9]+)$�
"/product/{id:[0-9]+}"
为例,varsN则等于[]{"id"}
。[]{"^[^/]+�"}
的正则表达式。根据路由表及路由的结构,具体的路由匹配查找基本过程如下: 第一步,从Router.routes开始依次循环 第二步,从每个路由中的matchers中循环,看请求的路径是否符合matchers中的每一项规则,如果都匹配,则说明找到了该路由,否则继续步骤1。
image.png
接下来,我们看看该路由是如何支持各种功能的。
r := mux.NewRouter()
// Only matches if domain is "www.example.com".
r.Host("www.example.com")
// Matches a dynamic subdomain.
r.Host("{subdomain:[a-z]+}.example.com")
我们先看r.Host("www.example.com")的路由。在routeRegexp结构体中,regexp值会是正则表达式"^www\.example\.com$
,regexpType字段是regexpTypeHost。同时赋值给routeRegexpGroup中的host字段。
从路由表Router.routes中依次匹配本次请求的时候,发现route.regexpType字段是域名的正则,则从请求中获取当前的host,然后跟routeRegexp.regexp正则表达式进行匹配。如果匹配成功则继续匹配后面的路由,否则直接匹配失败。
再来看匹配子域名r.Host("{subdomain:[a-z]+}.example.com")的情况。在routeRegexp结构体中,regexp值会是正则表达式"^(?P<v0>[a-z]+)\.example\.com$
,regexpType字段是regexpTypeHost。同时赋值给routeRegexpGroup中的host字段。匹配过程和上述过程一样,不再重复介绍。
r.PathPrefix("/products/")
顾名思义,就是只有路径中是以/products为前缀的才能匹配到该路由。该路由的设置最终编译成的正则表达式是^/products
。这里注意该表达式中结尾并没有结尾符号 $
。其匹配过程和上述一致。
r.Methods("GET", "POST")
对请求方法的限制 是不经过正则,而是将允许的方法(GET、POST)转换成一个methodMatcher�类型,该类型本质上是一个字符串切片,并且实现了Match方法,也就是matcher接口。然后将其加入到该路由的matchers中,在路由匹配时看当前的请求是否满足该路由的这条规则。其定义如下:
type methodMatcher []string
func (m methodMatcher) Match(r *http.Request, match *RouteMatch) bool {
return matchInArray(m, r.Method)
}
userRouter := r.PathPrefix("/user").Subrouter()
userRouter.HandleFunc("/info", HomeHandler)
通过.Subrouter()函数就能实现一个子路由表,在该子路由表下注册的所有路由都会遵循子路由上的公共设置,比如前缀。如上述例子/info的完整路径就是/user/info指向HomeHandler。
我们查看Subrouter函数的源码,实际上是新建了一个Router结构体,而Router结构体实现了Match函数,即matcher,所以也会将该matcher加入到r.PathPrefix这个路由的matchers中。相当于在路由中有建了一个专属的路由表。以下是Router的Match函数实现,我们看到循环到该matcher时,循环子路由表的routes,再对每个子路由依次进行匹配:
func (r *Router) Match(req *http.Request, match *RouteMatch) bool {
for _, route := range r.routes {
if route.Match(req, match) {
// Build middleware chain if no error was found
if match.MatchErr == nil {
for i := len(r.middlewares) - 1; i >= 0; i-- {
match.Handler = r.middlewares[i].Middleware(match.Handler)
}
}
return true
}
}
...//省略代码
}
// 定义中间件
func loggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// Do stuff here
log.Println(r.RequestURI)
// Call the next handler, which can be another middleware in the chain, or the final handler.
next.ServeHTTP(w, r)
})
}
r := mux.NewRouter()
r.HandleFunc("/", HomeHandler)
// 使用中间件
r.Use(loggingMiddleware)
func HomeHandler(response http.ResponseWriter, request *http.Request) {
response.Write([]byte("Hi, this is Home page"))
}
在该示例中,首先定义了一个中间件loggingMIddleware,然后使用Use函数将中间件加入到了Router中。
中间件的实现原理实际上是将原本要执行的handler包装到中间件的handler中。先执行中间件的handler逻辑,然后再执行原本的handler。以上述代码为例,会将HomeHandler传递给loggingMiddleware的next参数。执行的时候从第4行开始执行,最后才是第7行,即HomeHandler的代码逻辑。如下图:
接下来我们看看中间件是如何实现一层层包裹的。
我们先看r.Use函数的定义:
func (r *Router) Use(mwf ...MiddlewareFunc) {
for _, fn := range mwf {
r.middlewares = append(r.middlewares, fn)
}
}
发现中间件的类型是MiddlewareFunc,该类型的定义如下:
type MiddlewareFunc func(http.Handler) http.Handler
中间件本质上是一个函数类型,输入和输出都是一个http.Handler,同时MiddlewareFunc中实现了一个Middleware的方法:
func (mw MiddlewareFunc) Middleware(handler http.Handler) http.Handler {
return mw(handler)
}
我们再看路由匹配时,执行中间件的逻辑:
func (r *Router) Match(req *http.Request, match *RouteMatch) bool {
for _, route := range r.routes {
if route.Match(req, match) {
// Build middleware chain if no error was found
if match.MatchErr == nil {
for i := len(r.middlewares) - 1; i >= 0; i-- {
match.Handler = r.middlewares[i].Middleware(match.Handler)
}
}
return true
}
}
...//省略代码
}
在第7行,执行中间件的Middleware函数。以r.HandleFunc("/", HomeHandler)
使用loggingMiddleware中间件为例,match.Handler是HomeHandler,loggingMiddleware.Middleware即为loogingMIddleware(HomeHandler),该函数返回的是一个新的handler:
http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// Do stuff here
log.Println(r.RequestURI)
// Call the next handler, which can be another middleware in the chain, or the final handler.
next.ServeHTTP(w, r)
})
那么,在具体执行的时候,就是先执行该handler的业务逻辑,即log.Println(r.RequestURI),然后执行next.ServerHTTP逻辑,即HomeHandler.ServeHTTP的逻辑。
这就是中间件对handler的包装及执行过程。其他更多功能可自行查看gorilla/mux包的源码。
大名鼎鼎的gin框架采用的就是前缀树结构实现的路由。我们先来看一下gin框架中路由是如何定义的。
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
g := gin.New()
g.POST("/abc/info", InfoHandler)
g.POST("/abc/info/detail", InfoHandler)
g.POST("/abc/list", HomeHandler)
g.Run(":8000")
}
func HomeHandler(ctx *gin.Context) {
ctx.Writer.Write([]byte("Hi, this is Home page"))
}
func InfoHandler(ctx *gin.Context) {
ctx.Writer.Write([]byte("Hi, this is info"))
}
很简单,首先通过gin.New()初始化一个gin对象g,然后通过g.POST或g.GET等方法就可以注册路由。很明显,路由注册过程也限制了请求的方法。 当然,还有一个方法是允许任何请求方法都能访问该路径的,就是Any:
g.Any("/", HomeHandler)
Any方法本质上是定义了一组方法名,然后依次调用对应的方法将该路由进行注册,如下:
var anyMethods = []string{
http.MethodGet, http.MethodPost, http.MethodPut, http.MethodPatch,
http.MethodHead, http.MethodOptions, http.MethodDelete, http.MethodConnect,
http.MethodTrace,
}
// Any registers a route that matches all the HTTP methods.
// GET, POST, PUT, PATCH, HEAD, OPTIONS, DELETE, CONNECT, TRACE.
func (group *RouterGroup) Any(relativePath string, handlers ...HandlerFunc) IRoutes {
for _, method := range anyMethods {
group.handle(method, relativePath, handlers)
}
return group.returnObj()
}
接下来,我们分析下路由实现以及匹配的过程。
相比较map/hash字典实现的优点:利用字符串公共前缀来减少查询时间,减少无谓的字符串比较
我们先看gin框架中的路由是如何对请求方法做限制的。 在gin框架中,路由树的构建是基于方法的。每种方法一棵路由树。如下:
type methodTree struct {
method string
root *node
}
type methodTrees []methodTree
例如,上述示例中的g.POST("/abc/info", InfoHandler)
路由,只会注册到POST方法的路由树中。若通过GET方法请求该路径,则在搜索的时候,在GET方法的路由树中就找不到该路由。这样就起到了通过路由限制请求方法的作用。
而g.Any方法注册的路由,相当于在所有的方法路由中都注册了一遍,因此,使用任何方法都能找到对应的路由。
前缀树中的路由都是基于这个node数据结构来进行构建的。其中包含了一个路由中的基本元素:路径fullPath、对应的处理函数handlers。其中handlers包含了中间件处理函数,因此这里使用一个handlersChain表示。
另外一个关键字段是children,具有相同路径前缀的子节点通过children节点来构成父、子关系。
接下来我们路由树是如何基于node节点进行构建的。
首先,我们看第一个路由的注册。
g.POST("/abc/info", InfoHandler)
因为是第一个路由注册,路由树是空的。所以直接构建一个node节点,然后将该node节点作为POST方法路由树的根节点插入即可。如下图:
好,我们接着看接着注册第二个路由:
g.POST("/abc/info/detail", DetailHandler)
我们发现,这个路由的特点是和路由"/abc/info"有共同的前缀,所以会将该路由作为第一个路由的子节点放到children中。如下图:
这里主要有三个变化:一个是根节点的priority由1变成了2;一个是children中多了一个子节点路由;最后一个是indices字段的值变成了"/",这个是第一个子节点的path字段的第一个字符,用于匹配时索引使用。在子节点中,要注意的是path的值,因为前缀是"/abc/info"了,所以这里path是"/detail"。但fullPath依然是注册时完整的路径。
接下来,我们再注册第三个路由:
g.POST("/abc/list", ListHandler)
这个路由的特点是和前两个路由有共同的前缀"/abc/",所以首先会将现在的根节点进行拆分,拆分成"/abc/" 和"info"。而info和原来的"/abc/info/detail" 又有共同的前缀info,所以原来的"/abc/info/detail"就变成了info的子节点。而"/abc/list"除去前缀"/abc/"后,剩余"list"子节点,作为"/abc/"的子节点。如下:
那么,按节点组成的路由树就如下所示:
这里,我们首先看根节点的变化:
其次,是从原根节点中拆分出一个info节点。最后是detail节点成为info节点的子节点。
以上就是路由树的构建过程。更细节的构造,有兴趣的同学可以查看源码进一步了解。
本文总结了3中路由的实现。路由本质上就是将请求的路径和对应的处理函数一一对应。通过路径查找到处理函数的过程。不同框架基于不同的数据结构实现了路由表以及匹配过程。希望本文对大家理解web框架的路由有所帮助。
---特别推荐---
特别推荐:一个专注go项目实战、项目中踩坑经验及避坑指南、各种好玩的go工具的公众号,「Go学堂」,专注实用性,非常值得大家关注。点击下方公众号卡片,直接关注。关注送《100个go常见的错误》pdf文档。