它来了它终于来了- Beego 1.12.2

不久前，我们发文说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 在征集社区意见。欢迎大家参与进来，出谋划策。