原创分享 它来了它终于来了- Beego 1.12.2

wbofeng for beego · 2020年07月01日 · 2162 次阅读
本帖已被设为精华帖!

它来了它终于来了- Beego 1.12.2

作者:邓明 from beego-dev

不久前,我们发文说 Beego 重新组建了一个团队,再次开始维护了。

经过这一段时间的努力,我们终于完成了重启之后的第一个版本。这个版本,我们集中精力修复了很多陈年 issue,同时也尝试支持了一下 promethues 。欢迎大家使用。 Release Note

Prometheus 支持

一个没有观测性支持的框架是没有灵魂的。这一个版本,我们走出了解决 metric 问题的第一步,使用 Prometheus 开发了一个 Web Middleware ,用户可以在开启了 admin 服务之后尝个鲜了。

例子

image.png

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 在征集社区意见。欢迎大家参与进来,出谋划策。

image.png image.png

更多原创文章干货分享,请关注公众号
  • 加微信实战群请加微信(注明:实战群):gocnio
astaxie 将本帖设为了精华贴 07月01日 22:37
_Lin GoCN 每日新闻 (2020-07-02) 中提及了此贴 07月02日 13:55
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册