gin 源碼閱讀 -3- - gin 路由的實現剖析

hi, 大家好，我是 hhf。

上面兩篇文章基本講清楚了 Web Server 如何接收客戶端請求，以及如何將請求流轉到 gin 的邏輯。

gin 原理剖析說到這裏，就完全進入 gin 的邏輯裏面了。gin 已經拿到 http 請求了，第一件重要的事情肯定就是重寫路由了，所以本節內容主要是分析 gin 的路由相關的內容。

什麼是路由？

這個其實挺容易理解的，就是根據不同的 URL 找到對應的處理函數即可。

目前業界 Server 端 API 接口的設計方式一般是遵循 RESTful 風格的規範。當然我也見過某些大公司爲了降低開發人員的心智負擔和學習成本，接口完全不區分 GET/POST/DELETE 請求，完全靠接口的命名來表示。

舉個簡單的例子，如："刪除用戶"

RESTful:    DELETE  /user/hhf
No RESTful: GET     /deleteUser?name=hhf

這種 No RESTful 的方式，有的時候確實減少一些溝通問題和學習成本，但是隻能內部使用了。這種不區分 GET/POST 的 Web 框架一般設計的會比較靈活，但是開發人員水平參差不齊，會導致出現很多 “接口毒瘤”，等你發現的時候已經無可奈何了，如下面這些接口：

GET /selectUserList?userIds=[1,2,3] -> 參數是否可以是數組？
GET /getStudentlist?skuIdCntMap={"200207366":1} -> 參數是否可以是字典？

這樣的接口設計會導致開源的框架都是解析不了的，只能自己手動一層一層 decode 字符串，這裏就不再詳細鋪開介紹了，等下一節說到 gin Bind 系列函數時再詳細說一下。

繼續回到上面 RESTful 風格的接口上面來，拿下面這些簡單的請求來說：

GET    /user/{userID} HTTP/1.1
POST   /user/{userID} HTTP/1.1
PUT    /user/{userID} HTTP/1.1
DELETE /user/{userID} HTTP/1.1

這是比較規範的 RESTful API 設計，分別代表：

可以看到同樣的 URI，不同的請求 Method，最終其他代表的要處理的事情也完全不一樣。

看到這裏你可以思考一下，假如讓你來設計這個路由，要滿足上面的這些功能，你會如何設計呢？

gin 路由設計

如何設計不同的 Method ?

通過上面的介紹，已經知道 RESTful 是要區分方法的，不同的方法代表意義也完全不一樣，gin 是如何實現這個的呢？

其實很簡單，不同的方法就是一棵路由樹，所以當 gin 註冊路由的時候，會根據不同的 Method 分別註冊不同的路由樹。

GET    /user/{userID} HTTP/1.1
POST   /user/{userID} HTTP/1.1
PUT    /user/{userID} HTTP/1.1
DELETE /user/{userID} HTTP/1.1

如這四個請求，分別會註冊四顆路由樹出來。

func (engine *Engine) addRoute(method, path string, handlers HandlersChain) {
    //....
    root := engine.trees.get(method)
    if root == nil {
        root = new(node)
        root.fullPath = "/"
        engine.trees = append(engine.trees, methodTree{method: method, root: root})
    }
    root.addRoute(path, handlers)
    // ...
}

其實代碼也很容易看懂，

gin 路由的註冊過程

func main() {
    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })
    r.Run() // listen and serve on 0.0.0.0:8080
}

這段簡單的代碼裏，r.Get 就註冊了一個路由 /ping 進入 GET tree 中。這是最普通的，也是最常用的註冊方式。

不過上面這種寫法，一般都是用來測試的，正常情況下我們會將 handler 拿到 Controller 層裏面去，註冊路由放在專門的 route 管理裏面，這裏就不再詳細拓展，等後面具體說下 gin 的架構分層設計。

//controller/somePost.go
func SomePostFunc(ctx *gin.Context) {
    // do something
    context.String(http.StatusOK, "some post done")
}
```go
// route.go
router.POST("/somePost", controller.SomePostFunc)

使用 RouteGroup

v1 := router.Group("v1")
{
    v1.POST("login", func(context *gin.Context) {
        context.String(http.StatusOK, "v1 login")
    })
}

RouteGroup 是非常重要的功能，舉個例子：一個完整的 server 服務，url 需要分爲鑑權接口和非鑑權接口，就可以使用 RouteGroup 來實現。其實最常用的，還是用來區分接口的版本升級。這些操作, 最終都會在反應到 gin 的路由樹上

gin 路由的具體實現

func main() {
    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })
    r.Run() // listen and serve on 0.0.0.0:8080
}

還是從這個簡單的例子入手。我們只需要弄清楚下面三個問題即可：

1. GET/POST/DELETE/.. 的最終歸宿

func (group *RouterGroup) GET(relativePath string, handlers ...HandlerFunc) IRoutes {
   return group.handle(http.MethodGet, relativePath, handlers)
}

在調用POST, GET, HEAD等路由 HTTP 相關函數時, 會調用handle函數。handle 是 gin 路由的統一入口。

// routergroup.go:L72-77
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()
}

2. 生成路由樹

下面考慮一個情況，假設有下面這樣的路由，你會怎麼設計這棵路由樹？

GET /abc 
GET /abd
GET /af

當然最簡單最粗暴的就是每個字符串佔用一個樹的葉子節點，不過這種設計會帶來的問題：佔用內存會升高，我們看到 abc, abd, af 都是用共同的前綴的，如果能共用前綴的話，是可以省內存空間的。

gin 路由樹是一棵前綴樹. 我們前面說過 gin 的每種方法 (POST, GET ...) 都有自己的一顆樹，當然這個是根據你註冊路由來的，並不是一上來把每種方式都註冊一遍。gin 每棵路由大概是下面的樣子

這個流程的代碼太多，這裏就不再貼出具體代碼裏，有興趣的同學可以按照這個思路看下去即可。

3. handler 與 URL 關聯

type node struct {
    path      string
    indices   string
    wildChild bool
    nType     nodeType
    priority  uint32
    children  []*node // child nodes, at most 1 :param style node at the end of the array
    handlers  HandlersChain
    fullPath  string
}

node 是路由樹的整體結構

當收到客戶端請求時，如何找到對應的路由的 handler？

《gin 源碼閱讀 (2) - http 請求是如何流入 gin 的?》第二篇說到 net/http 非常重要的函數 ServeHTTP，當 server 收到請求時，必然會走到這個函數里。由於 gin 實現這個 ServeHTTP，所以流量就轉入 gin 的邏輯裏面。

// gin.go:L439-443
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)
}

所以，當 gin 收到客戶端的請求時, 第一件事就是去路由樹裏面去匹配對應的 URL，找到相關的路由, 拿到相關的處理函數。其實這個過程就是 handleHTTPRequest 要乾的事情。

func (engine *Engine) handleHTTPRequest(c *Context) {
    // ...
    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
        value := root.getValue(rPath, c.params, unescape)
        if value.params != nil {
            c.Params = *value.params
        }
        if value.handlers != nil {
            c.handlers = value.handlers
            c.fullPath = value.fullPath
            c.Next()
            c.writermem.WriteHeaderNow()
            return
        }
        if httpMethod != "CONNECT" && rPath != "/" {
            if value.tsr && engine.RedirectTrailingSlash {
                redirectTrailingSlash(c)
                return
            }
            if engine.RedirectFixedPath && redirectFixedPath(c, root, engine.RedirectFixedPath) {
                return
            }
        }
      break
    }
  // ...
}

從代碼上看這個過程其實也很簡單：

總結

說到這裏，基本上把 gin 路由的整個流程說清楚了，不過關於路由樹的詳細實現說的比較籠統，歡迎有興趣的同學入羣詳聊（加我好友，我拉你入羣）。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/PldVh8Wk6oxCFIcWVx3hrQ

猜你喜歡