内容简介：作者：邓明 from beego-dev 不久前，我们发文说 Beego 重新组建了一个团队，再次开始维护了。 经过这一段时间的努力，我们终于完成了重启之后的第一个版本。这个版本，我们集中精力修复了很多陈年 issue，同时也尝...
作者：邓明 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 的时候，存在两个问题：
- 未能设置缓存的
Prepare Statement的数量限制，用户使用不当的时候，会导致 "Can't create more than max_prepared_stmt_count statements" 的错误； - 任何一个
Prepare Statement被创建出来以后，我们并没有主动关闭，而是依赖于会话结束之后自然释放；
这一次，我们也改进了这些缺点：
- 我们采用了 LRU 来缓存
Prepare Statement，当一个Prepare Statement被 LRU 淘汰的时候，我们主动关闭Prepare Statement； - 为了解决
Prepare Statement被 LRU 淘汰之后，还存在用户使用继续使用该Prepare Statement的问题，我们引入了计数功能，会等到所有用户都释放了Prepare Statement之后再关闭。
这个优化应该算是走在了 ORM 框架的前列。我们看过一些开源框架的代码，它们要么没有缓存 Prepare Statement ，要么如优化之前那样，没有主动关闭；要么则是将关闭的决策交给了用户，依赖于用户主动找到未被使用的 Prepare Statement 而后自己关闭，而用户其实也很难判断出来 Prepare Statement 有没有被别的用户使用。
静态缓存文件优化
社区里面一直反馈的一个问题是，Beego 缓存的静态文件的功能，会消耗大量的内存，而 Beego 并没有限制内存的使用。 这个功能比较常用的是将 Beego 作为下载服务器。
这一次我们通过三个角度的优化来彻底解决这个问题：
- 采用 LRU 来做缓存，淘汰长期未使用的缓存下来的文件；
- 大文件不再缓存。我们通过参数的形式，允许用户设置一个阈值，超过这个阈值的文件将不会被缓存下来；
- 限制缓存的文件数量。结合前面的文件大小限制，用户可以准确预估，在当前配置下，Beego 静态文件缓存将会最多占用多少内存；
如果文件以小文件为主，那么这个缓存效果将会十分好。
手机全号码段校验支持
我们再一次更新了手机号码校验的正则表达式，现在已经可以支持全号码段的手机号码校验了。
性能优化
这一次，我们合并了多个跟优化相关的 PR。优化集中在锁优化，包括缩小锁的范围，尽量使用读锁等；Redis 采用 Scan 命令来取代 Keys 命令...
更多
我们还修复了其余的问题，比如说遗漏加锁导致的并发问题，还有热更新模块，在设置了某些选项下主线程依旧存活的问题……
在经过这个版本以后，我们接下来的核心工作是 Beego v2，目前我们出了一个 V2 RoadMap 在征集社区意见。欢迎大家参与进来，出谋划策。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
