它來了它終於來了- Beego 1.12.2

它來了它終於來了- Beego 1.12.2

作者：鄧明 from beego-dev

不久前，我們發文說 Beego 重新組建了一個團隊，再次開始維護了。

經過這一段時間的努力，我們終於完成了重啟之後的第一個版本。這個版本，我們集中精力修復了很多陳年 issue，同時也嘗試支援了一下 promethues 。歡迎大家使用。 Release Note

Prometheus 支援

一個沒有觀測性支援的框架是沒有靈魂的。這一個版本，我們走出瞭解決 metric 問題的第一步，使用 Prometheus 開發了一個 Web Middleware ，使用者可以在開啟了 admin 服務之後嚐個鮮了。

例子

Prepare Statement 快取優化

在 v1.12.0 的時候，我們引入了 Prepare Statement 的快取機制。Beego 內部所有的查詢都會通過 Prepare Statement 來執行，以提高安全性和效能。

但是在快取 Prepare Statement 的時候，存在兩個問題：

1. 未能設定快取的 Prepare Statement 的數量限制，使用者使用不當的時候，會導致 "Can't create more than max_prepared_stmt_count statements" 的錯誤；
2. 任何一個 Prepare Statement 被建立出來以後，我們並沒有主動關閉，而是依賴於會話結束之後自然釋放；

這一次，我們也改進了這些缺點：

1. 我們採用了 LRU 來快取 Prepare Statement ，當一個 Prepare Statement 被 LRU 淘汰的時候，我們主動關閉 Prepare Statement ；
2. 為了解決 Prepare Statement 被 LRU 淘汰之後，還存在使用者使用繼續使用該 Prepare Statement 的問題，我們引入了計數功能，會等到所有使用者都釋放了 Prepare Statement 之後再關閉。

這個優化應該算是走在了 ORM 框架的前列。我們看過一些開源框架的程式碼，它們要麼沒有快取 Prepare Statement ，要麼如優化之前那樣，沒有主動關閉；要麼則是將關閉的決策交給了使用者，依賴於使用者主動找到未被使用的 Prepare Statement 而後自己關閉，而使用者其實也很難判斷出來 Prepare Statement 有沒有被別的使用者使用。

靜態快取檔案優化

社群裡面一直反饋的一個問題是，Beego 快取的靜態檔案的功能，會消耗大量的記憶體，而 Beego 並沒有限制記憶體的使用。 這個功能比較常用的是將 Beego 作為下載伺服器。

這一次我們通過三個角度的優化來徹底解決這個問題：

1. 採用 LRU 來做快取，淘汰長期未使用的快取下來的檔案；
2. 大檔案不再快取。我們通過引數的形式，允許使用者設定一個閾值，超過這個閾值的檔案將不會被快取下來；
3. 限制快取的檔案數量。結合前面的檔案大小限制，使用者可以準確預估，在當前配置下，Beego 靜態檔案快取將會最多佔用多少記憶體；

如果檔案以小檔案為主，那麼這個快取效果將會十分好。

手機全號碼段校驗支援

我們再一次更新了手機號碼校驗的正規表示式，現在已經可以支援全號碼段的手機號碼校驗了。

效能優化

這一次，我們合併了多個跟優化相關的 PR。優化集中在鎖優化，包括縮小鎖的範圍，儘量使用讀鎖等；Redis 採用 Scan 命令來取代 Keys 命令...

更多

我們還修復了其餘的問題，比如說遺漏加鎖導致的併發問題，還有熱更新模組，在設定了某些選項下主執行緒依舊存活的問題……

在經過這個版本以後，我們接下來的核心工作是 Beego v2，目前我們出了一個 V2 RoadMap 在徵集社群意見。歡迎大家參與進來，出謀劃策。