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]

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

[shuimugan]

现在只是为当时的选择还债而已，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 级别的