Swoole 下的 Hyeprf 框架，现在的维护计划怎么样？

[wh469012917]

我们的业务，是在 2020 年从 Laravel 迁移到 Hyperf 的，当时迁移的原因是 Laravel 的性能，当时是没有 Octane 组件的，迁移后确实眼前一亮。
目前 5 年多过去了，Hyeprf 虽然还在更新，但是明显能感觉到作者积极性不如以前了，github 上提的 issue ，几乎都不鸟你，能理解这种开源项目没有收入，长时间的付出没有回报，积极性下降是必然的。

所以不知道有没有人了解，hyperf 框架未来的发展计划怎么样？我们的业务是机构公益性质的，所以不存在业务倒闭的情况，目前有考虑考虑迁移到 go 语言，但是得完全重写，投入的时间精力是否值得？

[justfindu]

我们也有想法想要迁移, 虽然有 Octane , 但是性能上还是差一点. 有没有什么坑需要填的

[wh469012917]

@justfindu 你们是用的 Laravel 吗？如果是 laravel 迁移到 hyperf 不推荐，目前看 hyperf 维护很不积极，迁移到 go 倒是可以

[lait123]

在用着 hyperf 后台框架 Mineadmin,感觉还行.hyperf 维护确实比较懈怠这个无解的. 但是大问题确实没有啥. 毕竟 php 热度都下降这么多了. 用爱发电的人肯定少. 生态肯定不能和 laravel 比. 转 go 考虑成本就行.

至于其他 php 框架推荐啥的,建议直接看 https://packagist.org/ 的下载量对比就知道了.php 语言下 没有太多选择了. 现在就是 laravel tp hyperf. 至于 webman 只能说下载量摆着.

如果你是员工 推荐转 go 给同事们多一条路子走. php 就用来搞钱吧.

[justfindu]

转 go 根本不是路子, 跨度太大, 除非新业务.

[wh469012917]

目前维护比较懈怠是一回事，随着时间推移，未来肯定是会越来越懈怠，就怕有一天重走 easyswoole 这些老路，直接删库跑路了。对我们的业务长远来说，转 go 应该是最佳的路，但就是投入的精力问题，目前其实算是独立开发者，没有员工

[wh469012917]

@justfindu 对我个人来说问题不大，工作上目前主要也是 go 了，php 就剩一下 hyeprf 框架在维护。如果你们用的是 laravel ，强烈不建议迁移 hyperf ，很有可能，还没迁移完，hyperf 就结束了

[liqinliqin]

Swoole 正在准备一个大招 PHP AOT,让任意 PHP 代码直接生成二进制，比如 WordPress ，直接一个命令行./wordpres

[jason56]

我们不用框架，直接裸 swoole 写，然后生成二进制分发

[BeforeTooLate]

所以问题在于怕没人维护跑路了，后期没法修复 bug ，性能上面我感觉不太可能瓶颈再语言上吧，大部分再 IO,数据库。

[nicoljiang]

@liqinliqin swoole 真是好东西，但我认为独木难支是迟早的事情。PHP 已经被 laravel 带得太坏了。

[fuchish112]

不是计划年底发 3.2 嘛

[liqinliqin]

@nicoljiang #10 我要给他再掰直，就用这个 aot

[liqinliqin]

@fuchish112 #11 我给他计划改了，必须掰直

[wh469012917]

@BeforeTooLate 性能其实问题不大，主要怕没人维护跑路，最近我提了好几个 issue ，全都没结果。甚至连是不是框架 bug 都不知道，只能自己想办法解决

[wh469012917]

@jason56 swoole 今年，其实也只发了 2 个 bug fix 的版本

[wh469012917]

@fuchish112 看样子是凉了

[zhumengyang]

年度发布 3.2

[fuchish112]

@wh469012917 #16 那不至于，swoole6.1 预计国庆发

[Smileh]

在维护啊， 还有专门的 swoole 群 里面大佬都在

[wh469012917]

@Smileh hyperf 维护肯定还有，但积极性大不如前了

[jason56]

@wh469012917 听说 swoole-cli 6.1 windows 和 macos 的兼容性会得到极大改善,团队做了大量单元测试。

[lakeme]

hyperf 该有的也都有了, 没什么需要更新的了

[pegziq]

@nicoljiang PHP 已经被 laravel 带得太坏了。
这个为什么？

[ferock]

迁移吧，别说 swoole 了，php 整体氛围都很懈怠

java 、go 都可以适合你

[elevioux]

新业务新方法。旧业务，放着咯，别出问题就行，撑不住再说。

[wh469012917]

@lakeme 倒不是功能上的问题，功能其实都能满足业务开发了，就是对未来维护上的担忧

[wh469012917]

@elevioux 我是自己的业务，不是企业里面的，所以肯定得上心

[wh469012917]

@ferock 考虑过很久，就是得完全重写，时间成本极高，第一次就是从 laravel 迁移到 hyperf ，都花了不少时间

[lxqxqxq]

机构公益性质, 独立开发者
时间成本极高 ，对未来维护上的担忧

大可不必

[codersdp1]

我们也是 20 年从 laravel 转型到 go ，现在全公司都用 go 了.

[codersdp1]

@wh469012917 #5 曾今何时，easyswoole 也是 php 之光

[wh469012917]

@lxqxqxq 就以我们目前来说，遇到的一个问题，负载一高就死锁，然后 worker 进程挂掉，master 进程主动退出，Pod 死掉，等待集群再次拉起。一直都没解掉

[javalaw2010]

渐进式迁移，当时我从 PHP 迁移到 go 的时候是这么做的，在 go 里面实现了一个反向代理，go 项目里如果路由匹配不到，就把请求代理给反向代理的后端。然后就是一个接口一个接口的慢慢迁移咯。

[canteon]

那个框架不是搞 kpi 的产物吗？这敢用

[xiuming]

@canteon swoole 搞的 kpi 产物 那有段时间一下涌现很多基于 swoole 框架 估计想打造一个爆款 现在感觉没一个爆款

[hiqxy]

公司还能撑很久的话 就转吧，不然没必要

[slowgen]

现在只是为当时的选择还债而已，5 年前就应该迁移到 go 了，再不济迁移到 nodejs 也好过继续 php 。
你现在迁移到 go 有个好处就是 AI 写 go 的能力几乎是溢出的，比其它语言准确性高很多，在 AI 加持下迁移应该很快

[Danswerme]

@shuimugan 请教下为什么说“ AI 写 go 的能力几乎是溢出的”呢？是因为 go 的开源代码非常多吗？

[kxg3030]

@canteon 没用过就不要开黄腔 我们公司 4000 个人 一直都用的全是 hyperf webman 最高并发也就 300 稳定的一匹

[kxg3030]

最早是 swoft 后来是 hyperf 都很好用 swoft 更顺手简单一些 瑕不掩瑜

[wh469012917]

@hiqxy 我是自己的项目，不用担心项目死掉的问题，服务器都是按照 5 年起买

[wh469012917]

@kxg3030 想问下你们 300 并发的话，机器的配置怎么样？我们是 2 台的 4 核 8G 的机器，并发稍微高一些，就大量的死锁出现，然后服务奔溃

[wh469012917]

@shuimugan ai 写问题不大，ai 出来的主要是代码的风格不好把控，风格得以我们的习惯为主

[kxg3030]

@wh469012917 能出现死锁 只能说代码质量堪忧 4H8G 中规中矩

[wh469012917]

@javalaw2010 go 有选用什么框架吗？按目前情况看，我应该也会考虑迁移，后台管理的接口就继续用 hyperf ，前台的 api 接口的话切换到 goframe 了

[promiser3d]

你们公益性质的产品，访问量如果不是特别大的话，Laravel 本身也没啥问题吧。

[wh469012917]

@kxg3030 可以帮忙看看这两个 issue ，都是我提的关于死锁的问题，目前还是没定位原因：
https://github.com/hyperf/hyperf/issues/7517
https://github.com/hyperf/hyperf/issues/7432

看看是不是我们代码质量垃圾导致的死锁

[wh469012917]

@promiser3d 日活跃用户 3000 左右，访问量不多的 50w 左右，整体算很低

[wh469012917]

@kxg3030 你们有用 resource 组件吗？目前调试发现，resource 组件需要创建大量对象，所以性能及其拉垮，暂时没想到好的办法解决

[kxg3030]

@wh469012917 已经说的很清楚了 所有协程都阻塞在等待数据 阻塞了就默认是死锁 revAll 应该不会自动让出时间片 这在 go 里面也是一样的 所有协程都阻塞了不就死锁了么 这是你使用方式的问题

[wh469012917]

@kxg3030 就以这段代码为例子，daily_sentence 、category 表总数据量低于 20 条，也会出现死锁，出现死锁的时候 mysql 和 redis 的资源利用率不超过 20%，：
```php
#[GetMapping(path: '')]
public function getSpecifyDailySentence(RequestInterface $request)
{
$date = $request->input('publish_at', date('Y-m-d'));
$dailySentence = DailySentence::where('publish_at', $date)->with(['category'])->first();
if (!$dailySentence) {
$dailySentence = DailySentence::orderBy('publish_at', 'desc')->with(['category'])->first();
}
return new DailySentenceResource($dailySentence);
}
```

想请教下，我这样是哪里使用方法有问题？

[canteon]

@kxg3030 对不起从来没用过，本来就是内部 kpi 产物，你用就用么。从来也没见过选型选 kpi 产物的

[kxg3030]

@canteon 目光短浅 我都懒得跟你解释

[kxg3030]

@wh469012917 DailySentenceResource 这啥玩意

[wh469012917]

@kxg3030 可以看下这个 issue： https://github.com/hyperf/hyperf/issues/7541

[canteon]

@kxg3030 嗯确实目光短浅

[BeautifulSoap]

PHP 的官方异步（ True Async ）已经在路上了什么时候，与其考虑转 go ，真不如再等等官方的异步。官方异步出来之后基于官方异步的网络框架肯定维护是不用担心的，swoole 这些异步可能真的会受到很大影响
https://wiki.php.net/rfc/true_async

[maigebaoer]

Go 写接口远不如 PHP 爽

[youyang]

@maigebaoer 是啊。。php 最好的语言。

[changz]

这框架用了两年了，给我坑得不要不要的，只能说算是 toy 级别的

[wh469012917]

@maigebaoer 单纯写 API 接口，go 没有一个框架能比 laravel 来的方便快捷

[Stevenv]

真要折腾，不如上 java ，方案是成套的。

[Stevenv]

@wh469012917 不要用这种 resource 智障组建了，直接返回 Json 好了。直接封装一下类就行。我记得我用 laravel 的时候，最初没这种东西，都是直接返回 json ，自己封装了基础的响应体。 这估计是哪个傻插拖裤子方式的设计，我用 spring boot 3.0 都没见过这种东西。。。直接返回类的好嘛

[Stevenv]

就这种东西响应封装组建还要弄对象池，把我整得一愣一愣的，说明框架本身就是乱设计，从来没人想过 laravel 设计 resources 的不合理性，反正它有我就的有。没见过响应并发要在代码上做对象池，一般都是他妈的上缓存啊，还要跟框架做斗争。建议直接换最成熟框架和设计 spring boot 3 。go 性能好要上也行，自己折腾吧，好多年没写

[wen20]

没什么好考虑的， 一个往上走，一个往下走。 而且你担心的不维护问题，时间越久可能概率越大。
而且，大概率熟悉 go 以后，你会逐渐放弃目前的后台技术栈。

[wh469012917]

@Stevenv 如果简单的列表数据那其实问题不大，复杂的列表数据，会使得控制器和渲染层耦合的很厉害，会有大量的处理业务逻辑之后的数据，而这时候 resource 的作用就出来了。
比如我一个用户列表，要对手机号脱敏、头像加签名、创建时间格式化，不用 resource 就得在控制器里面循环列表写一大堆的代码，职责不清晰。
resource 并不智障，他是一个很好的包装器模式，但带来的就是性能及其低下，很难搞。laravel 在设计上很多都是优先考虑代码质量，其次才是性能。

[wh469012917]

@wen20 go 写了 5 年了，整体上还是很熟悉的，切换语言整体要考虑的很多，主要是迁移上的时间成本。按目前来看 hyperf 未来不维护的概率只会越来越大，除非 php 本身能焕发新一春

[glitter1105]

自己封装一个 Transformer 类，抛弃 Resources 。

[Dlad]

frankenphp

[caola]

如果是 go 的话，还还是比较喜欢用 goravel ,和 laravel 的结构很像

[wogogoing]

我也是曾经的 laravel 爱好者。几年前转 go 了。

https://github.com/keepchen/go-sail

欢迎大佬们一起贡献❤️

[QlanQ]

@wh469012917 #15 hyperf 在目前的 php 框架中，算是积极的了
swoole 今年不是发了 大的版本了么现在是发了 6.0 了吧
hyperf 现在已经是 很贴近 php 的最新版了
考虑到 有些包不支持最新的版本，才没有急着发 3.2 的
目前 框架整体已经很成熟了，各个方面 也都有官方对应的方案
hyperf 整体很好用，性能也很高，前公司，日活几十万，3 台机器，就没有遇到过性能问题，倒是有一部分 切成 Java 后，服务器费用直线上升，一个 Java 微服务的服务器成本，比整个 php 项目 还高
resource 这个东西没用过

[javalaw2010]

@wh469012917 #45 没有，建议自己手撸，现在有 AI ，撸个脚手架撸个组件什么的分分钟，或者习惯 laravel 的话可以试试 goravel

[wh469012917]

@glitter1105 改造成本得全量接口都改，不如重写得了

[wh469012917]

@QlanQ 3 台机器配置怎么样？如果接口响应的数据比较复杂，有没有代码借我参考看看，怎么写会优雅一些？

[wh469012917]

@QlanQ 也可以帮忙看看 github 上的那个死锁问题，目前困扰我们最大的就是这个了。socketio 服务使用 nsq 作为驱动，0 访问量也会出现死锁

[Stevenv]

@wh469012917 你所谓的代码质量，是交给一个看起来很优雅但是实际性能很拉胯的包装类。既然发现了复杂数据性能差，那为什么不自己实现 Transform 类呢, 一定要用 laravel 自带的吗？要这样的优雅干啥，不要为了优雅而优雅。既然 resource 性能有问题，那就针对部分复杂数据做 Transform ，不需要全量改代码把。简单的继续保持呗。

[wh469012917]

@Stevenv 问题就在这里，在使用 resource 组件之前，其实是不知道性能拉垮的，而是在我们用了之后，过了很长一段时间，业务慢慢起来了，发现有性能问题，排查才发现是 resource 组件，但这时候所有的接口已经都用上了。

[wh469012917]

@Stevenv 也可以帮忙看看 socketio 在使用 nsq 服务的时候为什么会出现死锁问题？我们研发的水平确实只能说中规中矩，还请指教