Gin源码解析和例子——路由
Gin是一个基于golang的net包实现的网络框架。从github上，我们可以看到它相对于其他框架而言，具有优越的性能。本系列将从应用的角度来解析其源码。（转载请指明出于breaksoftware的csdn博客）
本文我们将分析其路由的原理。先看个例子（源于github)
func main() {
// Disable Console Color
// gin.DisableConsoleColor()
// Creates a gin router with default middleware:
// logger and recovery (crash-free) middleware
router := gin.Default()
router.GET("/someGet", getting)
router.POST("/somePost", posting)
router.PUT("/somePut", putting)
router.DELETE("/someDelete", deleting)
router.PATCH("/somePatch", patching)
router.HEAD("/someHead", head)
router.OPTIONS("/someOptions", options)
// By default it serves on :8080 unless a
// PORT environment variable was defined.
router.Run()
// router.Run(":3000") for a hard coded port
}可以说，这种写法非常的优雅。第7行新建了一个路由器；第9~15行定义了路由规则；第19行启动该路由器。如此整个服务就跑起来了。
我们将重心放在路由规则这段，可以很清晰的看到或者猜测到：
- 这儿看到的Get、Post、Put等都是Http的协议
- 向http://host/someGet发送Get请求将由getting方法处理
- 向http://host/somePost发送Post请求将由posting方法处理
- ……
现在我们开始分析路由器是怎么将请求和处理方法(handler)关联起来的。
第7行创建的对象叫做路由器（router），但是其底层名称却是“引擎”（Engine）
// Default returns an Engine instance with the Logger and Recovery middleware already attached.
func Default() *Engine {
debugPrintWARNINGDefault()
engine := New()
engine.Use(Logger(), Recovery())
return engine
}关注下第5行，这儿有个中间件（midlleware）的概念。目前我们只要把它看成一个函数对象（也是handler）即可。
每个引擎（Engine）都有一个路由集合（RouterGroup）。每个路由集合都有一个默认中间件集合。
type Engine struct {
RouterGroup
……// HandlerFunc defines the handler used by gin middleware as return value.
type HandlerFunc func(*Context)
// HandlersChain defines a HandlerFunc array.
type HandlersChain []HandlerFunc
// RouterGroup is used internally to configure router, a RouterGroup is associated with
// a prefix and an array of handlers (middleware).
type RouterGroup struct {
Handlers HandlersChain
basePath string
engine *Engine
root bool
}Use方法就是将Logger和Recovery中间件加入到默认的中间件集合中。之后我们会看到针对每个需要被路由的请求，这些中间件对应的handler都会被调用。
func (engine *Engine) Use(middleware ...HandlerFunc) IRoutes {
engine.RouterGroup.Use(middleware...)
engine.rebuild404Handlers()
engine.rebuild405Handlers()
return engine
}
func (group *RouterGroup) Use(middleware ...HandlerFunc) IRoutes {
group.Handlers = append(group.Handlers, middleware...)
return group.returnObj()
}我们再回到GET、POST这些方式上来，其底层都是调用了路由集合（RouterGroup）的handle方法
router.GET("/someGet", getting)
……
func (group *RouterGroup) GET(relativePath string, handlers ...HandlerFunc) IRoutes {
return group.handle("GET", relativePath, handlers)
}
func (group *RouterGroup) handle(httpMethod, relativePath string, handlers HandlersChain) IRoutes {
absolutePath := group.calculateAbsolutePath(relativePath)
handlers = group.combineHandlers(handlers)
group.engine.addRoute(httpMethod, absolutePath, handlers)
return group.returnObj()
}第8行通过相对路径获取绝对路径；第9行将该路径对应的handlers和之前加入的中间件（Logger()和Recovery()返回的是一个匿名函数，即handler。之后我们会看到）的handlers合并；第10行将对absolutePath路径Get请求对应的处理方法（handlers)加入到引擎的路由中。
我们看下combineHandlers的实现。它生成一个新的handler切片，然后先把中间件的handler插入到头部，然后把用户自定义处理某路径下请求的handler插入到尾部。最后返回的是这个新生成的切片，而引擎中之前设置的中间件handlers（group.Handlers）并没改变。所以针对每个需要被路由的请求，之前注册的中间件对应的handler都会被调用。
func (group *RouterGroup) combineHandlers(handlers HandlersChain) HandlersChain {
finalSize := len(group.Handlers) + len(handlers)
if finalSize >= int(abortIndex) {
panic("too many handlers")
}
mergedHandlers := make(HandlersChain, finalSize)
copy(mergedHandlers, group.Handlers)
copy(mergedHandlers[len(group.Handlers):], handlers)
return mergedHandlers
}再看下addRoute干了什么
func (engine *Engine) addRoute(method, path string, handlers HandlersChain) {
……
root := engine.trees.get(method)
if root == nil {
root = new(node)
engine.trees = append(engine.trees, methodTree{method: method, root: root})
}
root.addRoute(path, handlers)
}引擎的trees是一个多维切片。每个请求方法都有对应的一个methodTree，比如Get类型请求就只有一个methodTree与其对应。
每种请求方式（Get、Post等）又有很多路径与其对应。每个路径是一个node结构，该结构的handlers保存了如何处理该路径下该请求方式的方法集合。
所以第3~7行先尝试获取请求方式的结构体。没找到就创建一个。最后在第8行将路径和处理方法的对应关系加入到该请求方式结构之下。
type node struct {
path string
indices string
children []*node
handlers HandlersChain
priority uint32
nType nodeType
maxParams uint8
wildChild bool
}
type methodTree struct {
method string
root *node
}
type methodTrees []methodTree我们看到node结构下还有一个node的切片，这意味着这是一个递归结构。当然，我们通俗的称为叶子节点可能更容易理解点。为什么会有叶子节点这个概念？举个例子
r.GET("/pi", func(c *gin.Context) {
c.String(http.StatusOK, "po")
})
r.GET("/pin", func(c *gin.Context) {
c.String(http.StatusOK, "pon")
})
r.GET("/ping", func(c *gin.Context) {
c.String(http.StatusOK, "pong")
})/ping的父节点的path是/pin，/pin的父节点的path是/pi。如果我们再增加一个/pingabc，那么它的父节点path就是/ping。这些节点都有对应的handlers。
方式、路径和处理函数方法的映射准备好后，我们再看看Gin是如何驱动它们运行的。这个时候我们就要看
func (engine *Engine) Run(addr ...string) (err error) {
defer func() { debugPrintError(err) }()
address := resolveAddress(addr)
debugPrint("Listening and serving HTTP on %s\n", address)
err = http.ListenAndServe(address, engine)
return
}Gin的底层使用了net/http包。只是它封装了Engine结构体，并且让它实现了Handler接口
type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}
// ServeHTTP conforms to the http.Handler interface.
func (engine *Engine) ServeHTTP(w http.ResponseWriter, req *http.Request) {
c := engine.pool.Get().(*Context)
c.writermem.reset(w)
c.Request = req
c.reset()
engine.handleHTTPRequest(c)
engine.pool.Put(c)
}ServeHTTP方法会在serve方法中调用，serve会被Serve调用。在Serve中，我们看到接受请求和处理请求的逻辑了。Serve最终会在ListenAndServe中被调用，而它就是在引擎（Engine）的Run中被调用了的。这样我们只要关注引擎（Engine）的handleHTTPRequest实现即可。
// Serve a new connection.
func (c *conn) serve(ctx context.Context) {
……
serverHandler{c.server}.ServeHTTP(w, w.req)
……
}
func (srv *Server) Serve(l net.Listener) error {
……
for {
rw, e := l.Accept()
……
tempDelay = 0
c := srv.newConn(rw)
c.setState(c.rwc, StateNew) // before Serve can return
go c.serve(ctx)
}
}
func (srv *Server) ListenAndServe() error {
if srv.shuttingDown() {
return ErrServerClosed
}
addr := srv.Addr
if addr == "" {
addr = ":http"
}
ln, err := net.Listen("tcp", addr)
if err != nil {
return err
}
return srv.Serve(tcpKeepAliveListener{ln.(*net.TCPListener)})
}handleHTTPRequest方法会找到当前请求方式对应methodTree。然后找到路径对应的处理方法
func (engine *Engine) handleHTTPRequest(c *Context) {
httpMethod := c.Request.Method
path := c.Request.URL.Path
……
// Find root of the tree for the given HTTP method
t := engine.trees
for i, tl := 0, len(t); i < tl; i++ {
if t[i].method != httpMethod {
continue
}
root := t[i].root
// Find route in tree
handlers, params, tsr := root.getValue(path, c.Params, unescape)
if handlers != nil {
c.handlers = handlers
c.Params = params
c.Next()
c.writermem.WriteHeaderNow()
return
}
……第17行Next方法，将驱动相应的处理函数执行
func (c *Context) Next() {
c.index++
for s := int8(len(c.handlers)); c.index < s; c.index++ {
c.handlers[c.index](c)
}
}这儿我们注意下，处理函数的参数是Context指针！！调用Next是这个Context，然后handler处理的还是这些Context。比较反常的是，handler内部还可能调用该Context的Next方法！！！是不是感觉绕到一个循环里去了。我们回顾下之前中间件Logger
func Logger() HandlerFunc {
return LoggerWithWriter(DefaultWriter)
}
func LoggerWithWriter(out io.Writer, notlogged ...string) HandlerFunc {
……
return func(c *Context) {
……
// Process request
c.Next()
……
}
}是不是有点混乱？
其实不会出错，因为Next方法没有使用局部变量去遍历计数handlers的，它使用了和Context的成员变量index。这样就可以保证某些情况下Next()函数不会触发任何handler的调用。