Beego的MVC架構

經過文字來描述以下:session
- 在監聽的端口接收數據,默認監聽在 8080 端口。
- 用戶請求到達 8080 端口以後進入 beego 的處理邏輯。
- 初始化 Context 對象,根據請求判斷是否爲 WebSocket 請求,若是是的話設置 Input,同時判斷請求的方法是否在標準請求方法中(GET、POST、PUT、DELETE、PATCH、OPTIONS、HEAD),防止用戶的惡意僞造請求攻擊形成沒必要要的影響。
- 執行 BeforeRouter 過濾器,固然在 beego 裏面有開關設置。若是用戶設置了過濾器,那麼該開關打開,這樣能夠提升在沒有開啓過濾器的狀況下提升執行效率。若是在執行過濾器過程當中,responseWriter 已經有數據輸出了,那麼就提早結束該請求,直接跳轉到監控判斷。
- 開始執行靜態文件的處理,查看用戶的請求 URL 是否和註冊在靜態文件處理 StaticDir 中的 prefix 是否匹配。若是匹配的話,採用
http
包中默認的 ServeFile 來處理靜態文件。
- 若是不是靜態文件開始初始化 session 模塊(若是開啓 session 的話),這個裏面你們須要注意,若是你的 BeforeRouter 過濾器用到了 session 就會報錯,你應該把它加入到 AfterStatic 過濾器中。
- 開始執行 AfterStatic 過濾器,若是在執行過濾器過程當中,responseWriter 已經有數據輸出了,那麼就提早結束該請求,直接跳轉到監控判斷。
- 執行過過濾器以後,開始從固定的路由規則中查找和請求 URL 相匹配的對象。這個匹配是全匹配規則,即若是用戶請求的 URL 是
/hello/world
,那麼固定規則中 /hello
是不會匹配的,只有徹底匹配纔算匹配。若是匹配的話就進入邏輯執行,若是不匹配進入下一環節的正則匹配。
- 正則匹配是進行正則的全匹配,這個正則是按照用戶添加 beego 路由順序來進行匹配的,也就是說,若是你在添加路由的時候你的順序影響你的匹配。和固定匹配同樣,若是匹配的話就進行邏輯執行,若是不匹配進入 Auto 匹配。
- 若是用戶註冊了 AutoRouter,那麼會經過
controller/method
這樣的方式去查找對應的 Controller 和他內置的方法,若是找到就開始執行邏輯,若是找不到就跳轉到監控判斷。
- 若是找到 Controller 的話,那麼就開始執行邏輯,首先執行 BeforeExec 過濾器,若是在執行過濾器過程當中,responseWriter 已經有數據輸出了,那麼就提早結束該請求,直接跳轉到監控判斷。
- Controller 開始執行 Init 函數,初始化基本的一些信息,這個函數通常都是 beego.Controller 的初始化,不建議用戶繼承的時候修改該函數。
- 是否開啓了 XSRF,開啓的話就調用 Controller 的 XsrfToken,而後若是是 POST 請求就調用 CheckXsrfCookie 方法。
- 繼續執行 Controller 的 Prepare 函數,這個函數通常是預留給用戶的,用來作 Controller 裏面的一些參數初始化之類的工做。若是在初始化中 responseWriter 有輸出,那麼就直接進入 Finish 函數邏輯。
- 若是沒有輸出的話,那麼根據用戶註冊的方法執行相應的邏輯,若是用戶沒有註冊,那麼就調用 http.Method 對應的方法(Get/Post 等)。執行相應的邏輯,例如數據讀取,數據賦值,模板顯示之類的,或者直接輸出 JSON 或者 XML。
- 若是 responseWriter 沒有輸出,那麼就調用 Render 函數進行模板輸出。
- 執行 Controller 的 Finish 函數,這個函數是預留給用戶用來重寫的,用於釋放一些資源。釋放在 Init 中初始化的信息數據。
- 執行 AfterExec 過濾器,若是有輸出的話就跳轉到監控判斷邏輯。
- 執行 Controller 的 Destructor,用於釋放 Init 中初始化的一些數據。
- 若是這一路執行下來都沒有找到路由,那麼會調用 404 顯示找不到該頁面。
- 最後全部的邏輯都匯聚到了監控判斷,若是用戶開啓了監控模塊(默認是開啓一個 8088 端口用於進程內監控),這樣就會把訪問的請求連接扔給監控程序去記錄當前訪問的 QPS,對應的連接訪問的執行時間,請求連接等。
歡迎關注本站公眾號,獲取更多信息