PHP工程师三年技术栈重构实录

去年劳动节，我盯着电脑屏幕上那套用了三年的PHP框架代码——Laravel 5.5的路由文件里躺着217个闭包函数，Composer.json锁定的依赖版本还停留在2019年，连PHPStan的静态分析都报了142个"可能未定义变量"的警告。这哪是技术栈？分明是堆在阁楼里的旧家具，挪一下都怕散架。

重构的导火索是客户突然要求支持WebAssembly。那天下午，我翻出三年前写的PHP-FFmpeg视频转码模块——用system()调用ffmpeg命令行，转个4K视频能卡半小时，内存占用峰值飙到1.2GB。更要命的是，新来的前端用Vue3写的播放器，要求后端必须支持分片上传和断点续传，而当前这套基于Guzzle 5.x的HTTP客户端，连PUT请求的Content-Length头都要手动拼凑。这活儿，不重构根本没法接。

我选的技术栈挺"激进"：PHP 8.1+Swoole 4.8的协程架构，用RoadRunner做进程管理，数据库从MySQL迁移到TiDB（别问我为啥不用ClickHouse，客户要求分布式事务），缓存层用Redis 7.0的模块系统塞了个自定义的布隆过滤器。最狠的是把视频处理模块全换成FFmpeg的PHP绑定库FFI调用——直接操作内存，转码速度比之前快5倍，内存占用降到300MB以内。但代价也大：Swoole的协程调度在PHP 8.1的JIT下偶尔会死锁，RoadRunner的配置文件改了23版才跑通，TiDB的分布式事务在高并发时延迟能飙到200ms。

有个失败案例特别典型——为了用上PHP 8.1的纤程（Fibers），我把所有阻塞IO都改成了协程版。结果呢？第三方库里有个用cURL的旧代码没改彻底，导致整个协程池卡死。那天凌晨三点，我在生产环境抓包，发现某个请求的TCP连接保持了17分钟——原来是cURL的CURLOPT_TIMEOUT设成了0（无限等待），而Swoole的协程调度器又不会中断这种阻塞操作。最后只能回滚到同步模式，白改了3000行代码。

文章配图，仅供参考

主观判断：PHP工程师搞技术栈重构，必须得"狠"——别怕踩坑，新技术带来的性能提升和开发效率，远超过重构的成本。我见过太多人守着Laravel 5.x的"稳定"，结果被新需求逼着写补丁代码，最后系统臃肿得连自己都看不懂。当然，我这套架构也不是银弹——TiDB的运维成本比MySQL高不少，Swoole的调试工具链还不如Go完善，但至少现在，我能拍着胸脯说："这系统再扛三年没问题"。

下一步准备把PHP的FFI调用换成Rust写的扩展——FFmpeg的API太复杂，PHP的FFI绑定总漏掉些细节。另外，RoadRunner最近出了5.0版，支持PHP的Fibers原生协程，得赶紧测试下能不能解决之前的死锁问题。至于局限？嗯，团队里那个只会写PHP 5.6的老人，现在看我的代码跟看天书似的——重构这事儿，有时候得先解决人的问题。

（编辑：92站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!