这是一个创建于 46 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们的业务，是在 2020 年从 Laravel 迁移到 Hyperf 的，当时迁移的原因是 Laravel 的性能，当时是没有 Octane 组件的，迁移后确实眼前一亮。
目前 5 年多过去了，Hyeprf 虽然还在更新，但是明显能感觉到作者积极性不如以前了，github 上提的 issue ，几乎都不鸟你，能理解这种开源项目没有收入，长时间的付出没有回报，积极性下降是必然的。
所以不知道有没有人了解，hyperf 框架未来的发展计划怎么样？我们的业务是机构公益性质的，所以不存在业务倒闭的情况，目前有考虑考虑迁移到 go 语言，但是得完全重写，投入的时间精力是否值得？
目前 5 年多过去了，Hyeprf 虽然还在更新，但是明显能感觉到作者积极性不如以前了，github 上提的 issue ，几乎都不鸟你，能理解这种开源项目没有收入，长时间的付出没有回报，积极性下降是必然的。
所以不知道有没有人了解，hyperf 框架未来的发展计划怎么样？我们的业务是机构公益性质的，所以不存在业务倒闭的情况，目前有考虑考虑迁移到 go 语言，但是得完全重写，投入的时间精力是否值得？
 |
1
justfindu 46 天前
我们也有想法想要迁移, 虽然有 Octane , 但是性能上还是差一点. 有没有什么坑需要填的
|
 |
2
wh469012917 OP @justfindu 你们是用的 Laravel 吗？如果是 laravel 迁移到 hyperf 不推荐，目前看 hyperf 维护很不积极，迁移到 go 倒是可以
|
 |
3
lait123 46 天前
在用着 hyperf 后台框架 Mineadmin,感觉还行.hyperf 维护确实比较懈怠这个无解的. 但是大问题确实没有啥. 毕竟 php 热度都下降这么多了. 用爱发电的人肯定少. 生态肯定不能和 laravel 比. 转 go 考虑成本就行.
至于其他 php 框架推荐啥的,建议直接看 https://packagist.org/ 的下载量对比就知道了.php 语言下 没有太多选择了. 现在就是 laravel tp hyperf. 至于 webman 只能说下载量摆着. 如果你是员工 推荐转 go 给同事们多一条路子走. php 就用来搞钱吧. |
|
4
justfindu 46 天前
转 go 根本不是路子, 跨度太大, 除非新业务.
|
|
5
wh469012917 OP 目前维护比较懈怠是一回事，随着时间推移，未来肯定是会越来越懈怠，就怕有一天重走 easyswoole 这些老路，直接删库跑路了。对我们的业务长远来说，转 go 应该是最佳的路，但就是投入的精力问题，目前其实算是独立开发者，没有员工
|
|
6
wh469012917 OP @justfindu 对我个人来说问题不大，工作上目前主要也是 go 了，php 就剩一下 hyeprf 框架在维护。如果你们用的是 laravel ，强烈不建议迁移 hyperf ，很有可能，还没迁移完，hyperf 就结束了
|
 |
7
liqinliqin PRO Swoole 正在准备一个大招 PHP AOT,让任意 PHP 代码直接生成二进制，比如 WordPress ，直接一个命令行./wordpres
|
 |
8
jason56 46 天前
我们不用框架，直接裸 swoole 写，然后生成二进制分发
|
 |
9
BeforeTooLate 46 天前
所以问题在于怕没人维护跑路了，后期没法修复 bug ，性能上面我感觉不太可能瓶颈再语言上吧，大部分再 IO,数据库。
|
 |
10
nicoljiang PRO @liqinliqin swoole 真是好东西，但我认为独木难支是迟早的事情。PHP 已经被 laravel 带得太坏了。
|
 |
11
fuchish112 46 天前
不是计划年底发 3.2 嘛
|
|
12
liqinliqin PRO  1
@nicoljiang #10 我要给他再掰直，就用这个 aot
|
|
13
liqinliqin PRO @fuchish112 #11 我给他计划改了，必须掰直
|
|
14
wh469012917 OP @BeforeTooLate 性能其实问题不大，主要怕没人维护跑路，最近我提了好几个 issue ，全都没结果。甚至连是不是框架 bug 都不知道，只能自己想办法解决
|
|
15
wh469012917 OP @jason56 swoole 今年，其实也只发了 2 个 bug fix 的版本
|
|
16
wh469012917 OP @fuchish112 看样子是凉了
|
 |
17
zhumengyang 46 天前
年度发布 3.2
|
|
18
fuchish112 46 天前
@wh469012917 #16 那不至于，swoole6.1 预计国庆发
|
 |
19
Smileh 46 天前
在维护啊， 还有专门的 swoole 群 里面大佬都在
|
|
20
wh469012917 OP @Smileh hyperf 维护肯定还有，但积极性大不如前了
|
|
21
jason56 46 天前
@wh469012917 听说 swoole-cli 6.1 windows 和 macos 的兼容性会得到极大改善,团队做了大量单元测试。
|
 |
22
lakeme 46 天前
hyperf 该有的也都有了, 没什么需要更新的了
|
 |
23
pegziq 46 天前
@nicoljiang PHP 已经被 laravel 带得太坏了。
这个为什么？ |
 |
24
ferock PRO 迁移吧，别说 swoole 了，php 整体氛围都很懈怠
java 、go 都可以适合你 |
 |
25
elevioux 46 天前
新业务新方法。旧业务，放着咯，别出问题就行，撑不住再说。
|
|
26
wh469012917 OP @lakeme 倒不是功能上的问题，功能其实都能满足业务开发了，就是对未来维护上的担忧
|
|
27
wh469012917 OP @elevioux 我是自己的业务，不是企业里面的，所以肯定得上心
|
|
28
wh469012917 OP @ferock 考虑过很久，就是得完全重写，时间成本极高，第一次就是从 laravel 迁移到 hyperf ，都花了不少时间
|
 |
29
lxqxqxq 46 天前
机构公益性质, 独立开发者
时间成本极高 ，对未来维护上的担忧 大可不必 |
 |
30
codersdp1 46 天前
我们也是 20 年从 laravel 转型到 go ，现在全公司都用 go 了.
|
|
31
codersdp1 46 天前
@wh469012917 #5 曾今何时，easyswoole 也是 php 之光
|
|
32
wh469012917 OP @lxqxqxq 就以我们目前来说，遇到的一个问题，负载一高就死锁，然后 worker 进程挂掉，master 进程主动退出，Pod 死掉，等待集群再次拉起。一直都没解掉
|
 |
33
javalaw2010 46 天前 1
渐进式迁移，当时我从 PHP 迁移到 go 的时候是这么做的，在 go 里面实现了一个反向代理，go 项目里如果路由匹配不到，就把请求代理给反向代理的后端。然后就是一个接口一个接口的慢慢迁移咯。
|
 |
34
canteon 46 天前
那个框架不是搞 kpi 的产物吗？这敢用
|
 |
36
hiqxy 46 天前
公司还能撑很久的话 就转吧，不然没必要
|
 |
37
slowgen 46 天前
现在只是为当时的选择还债而已，5 年前就应该迁移到 go 了，再不济迁移到 nodejs 也好过继续 php 。
你现在迁移到 go 有个好处就是 AI 写 go 的能力几乎是溢出的，比其它语言准确性高很多，在 AI 加持下迁移应该很快 |
 |
40
kxg3030 45 天前
最早是 swoft 后来是 hyperf 都很好用 swoft 更顺手简单一些 瑕不掩瑜
|
|
41
wh469012917 OP @hiqxy 我是自己的项目，不用担心项目死掉的问题，服务器都是按照 5 年起买
|
|
42
wh469012917 OP @kxg3030 想问下你们 300 并发的话，机器的配置怎么样？我们是 2 台的 4 核 8G 的机器，并发稍微高一些，就大量的死锁出现，然后服务奔溃
|
|
43
wh469012917 OP @shuimugan ai 写问题不大，ai 出来的主要是代码的风格不好把控，风格得以我们的习惯为主
|
|
44
kxg3030 45 天前
@wh469012917 能出现死锁 只能说代码质量堪忧 4H8G 中规中矩
|
|
45
wh469012917 OP @javalaw2010 go 有选用什么框架吗？按目前情况看，我应该也会考虑迁移，后台管理的接口就继续用 hyperf ，前台的 api 接口的话切换到 goframe 了
|
 |
46
promiser3d 45 天前
你们公益性质的产品，访问量如果不是特别大的话，Laravel 本身也没啥问题吧。
|
|
47
wh469012917 OP @kxg3030 可以帮忙看看这两个 issue ，都是我提的关于死锁的问题，目前还是没定位原因：
https://github.com/hyperf/hyperf/issues/7517 https://github.com/hyperf/hyperf/issues/7432 看看是不是我们代码质量垃圾导致的死锁 |
|
48
wh469012917 OP @promiser3d 日活跃用户 3000 左右，访问量不多的 50w 左右，整体算很低
|
|
49
wh469012917 OP @kxg3030 你们有用 resource 组件吗？目前调试发现，resource 组件需要创建大量对象，所以性能及其拉垮，暂时没想到好的办法解决
|
|
50
kxg3030 45 天前
@wh469012917 已经说的很清楚了 所有协程都阻塞在等待数据 阻塞了就默认是死锁 revAll 应该不会自动让出时间片 这在 go 里面也是一样的 所有协程都阻塞了不就死锁了么 这是你使用方式的问题
|
|
51
wh469012917 OP @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); } ``` 想请教下，我这样是哪里使用方法有问题？ |
|
54
kxg3030 45 天前
@wh469012917 DailySentenceResource 这啥玩意
|
|
55
wh469012917 OP @kxg3030 可以看下这个 issue： https://github.com/hyperf/hyperf/issues/7541
|
 |
57
BeautifulSoap 45 天前
PHP 的官方异步（ True Async ）已经在路上了什么时候，与其考虑转 go ，真不如再等等官方的异步。官方异步出来之后基于官方异步的网络框架肯定维护是不用担心的，swoole 这些异步可能真的会受到很大影响
https://wiki.php.net/rfc/true_async |
 |
58
maigebaoer 45 天前 via Android
Go 写接口远不如 PHP 爽
|
 |
59
youyang 45 天前
@maigebaoer 是啊。。php 最好的语言。
|
 |
60
changz 45 天前 via Android
这框架用了两年了，给我坑得不要不要的，只能说算是 toy 级别的
|
|
61
wh469012917 OP @maigebaoer 单纯写 API 接口，go 没有一个框架能比 laravel 来的方便快捷
|
 |
62
infreboot 45 天前 via iPhone
真要折腾，不如上 java ，方案是成套的。
|
|
63
infreboot 45 天前 via iPhone
@wh469012917 不要用这种 resource 智障组建了，直接返回 Json 好了。直接封装一下类就行。我记得我用 laravel 的时候，最初没这种东西，都是直接返回 json ，自己封装了基础的响应体。 这估计是哪个傻插拖裤子方式的设计，我用 spring boot 3.0 都没见过这种东西。。。直接返回类的好嘛
|
|
64
infreboot 45 天前 via iPhone
就这种东西响应封装组建还要弄对象池，把我整得一愣一愣的，说明框架本身就是乱设计，从来没人想过 laravel 设计 resources 的不合理性，反正它有我就的有。没见过响应并发要在代码上做对象池，一般都是他妈的上缓存啊，还要跟框架做斗争。建议直接换最成熟框架和设计 spring boot 3 。go 性能好要上也行，自己折腾吧，好多年没写
|
 |
65
wen20 45 天前
没什么好考虑的， 一个往上走，一个往下走。 而且你担心的不维护问题，时间越久可能概率越大。
而且，大概率熟悉 go 以后，你会逐渐放弃目前的后台技术栈。 |
|
66
wh469012917 OP @Stevenv 如果简单的列表数据那其实问题不大，复杂的列表数据，会使得控制器和渲染层耦合的很厉害，会有大量的处理业务逻辑之后的数据，而这时候 resource 的作用就出来了。
比如我一个用户列表，要对手机号脱敏、头像加签名、创建时间格式化，不用 resource 就得在控制器里面循环列表写一大堆的代码，职责不清晰。 resource 并不智障，他是一个很好的包装器模式，但带来的就是性能及其低下，很难搞。laravel 在设计上很多都是优先考虑代码质量，其次才是性能。 |
|
67
wh469012917 OP @wen20 go 写了 5 年了，整体上还是很熟悉的，切换语言整体要考虑的很多，主要是迁移上的时间成本。按目前来看 hyperf 未来不维护的概率只会越来越大，除非 php 本身能焕发新一春
|
 |
68
glitter1105 45 天前
自己封装一个 Transformer 类，抛弃 Resources 。
|
 |
69
Dlad 45 天前
frankenphp
|
 |
70
caola 45 天前
如果是 go 的话，还还是比较喜欢用 goravel ,和 laravel 的结构很像
|
 |
71
wogogoing PRO |
 |
72
QlanQ 45 天前
@wh469012917 #15 hyperf 在目前的 php 框架中，算是积极的了
swoole 今年不是发了 大的版本了么现在是发了 6.0 了吧 hyperf 现在已经是 很贴近 php 的最新版了 考虑到 有些包不支持最新的版本，才没有急着发 3.2 的 目前 框架整体已经很成熟了，各个方面 也都有官方对应的方案 hyperf 整体很好用，性能也很高，前公司，日活几十万，3 台机器，就没有遇到过性能问题，倒是有一部分 切成 Java 后，服务器费用直线上升，一个 Java 微服务的服务器成本，比整个 php 项目 还高 resource 这个东西没用过 |
|
73
javalaw2010 45 天前
@wh469012917 #45 没有，建议自己手撸，现在有 AI ，撸个脚手架撸个组件什么的分分钟，或者习惯 laravel 的话可以试试 goravel
|
|
74
wh469012917 OP @glitter1105 改造成本得全量接口都改，不如重写得了
|
|
75
wh469012917 OP @QlanQ 3 台机器配置怎么样？如果接口响应的数据比较复杂，有没有代码借我参考看看，怎么写会优雅一些？
|
|
76
wh469012917 OP @QlanQ 也可以帮忙看看 github 上的那个死锁问题，目前困扰我们最大的就是这个了。socketio 服务使用 nsq 作为驱动，0 访问量也会出现死锁
|
|
77
infreboot 45 天前
@wh469012917 你所谓的代码质量，是交给一个看起来很优雅但是实际性能很拉胯的包装类。既然发现了复杂数据性能差，那为什么不自己实现 Transform 类呢, 一定要用 laravel 自带的吗？要这样的优雅干啥，不要为了优雅而优雅。既然 resource 性能有问题，那就针对部分复杂数据做 Transform ，不需要全量改代码把。简单的继续保持呗。
|
|
78
wh469012917 OP @Stevenv 问题就在这里，在使用 resource 组件之前，其实是不知道性能拉垮的，而是在我们用了之后，过了很长一段时间，业务慢慢起来了，发现有性能问题，排查才发现是 resource 组件，但这时候所有的接口已经都用上了。
|
|
79
wh469012917 OP @Stevenv 也可以帮忙看看 socketio 在使用 nsq 服务的时候为什么会出现死锁问题？我们研发的水平确实只能说中规中矩，还请指教
|
 |
80
shebaoting 43 天前
@justfindu 我目前的充电桩平台，高峰期同时 1 万人充电。并发几百。QPS 几十。使用的 Octane 。16 核 CPU 。高峰期 CPU 的负载基本不超过 1%。
这个性能，我觉得对于大部分中小型项目，都够了。大项目换其他语言就可以。 |
|
81
wh469012917 OP @shebaoting 那你们这个，其实可以降到 8 核试试看
|
 |
82
harlen 42 天前
@wh469012917 你改好了，往上提 mq 就有人维护了，社区项目，不能全靠作者维护啊
|
|
83
wh469012917 OP @harlen 我只是个伸手党，没精力去提 mr 的
|
Select Language