Beego的MVC架構

經過文字來描述以下：

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