共计 756 个字符,预计需要花费 2 分钟才能阅读完成。
Swoole4 之后, 协程化支持已经完善, 并且支持大量的 PHP 扩展自动协程化. 一些基于 Swoole4 的框架也蓬勃发展, 光看着文档就让人跃跃欲试.
但是对于现有旧项目如何引入并启用 Swoole 协程成了实际场景中的客观问题, 由于协程性质及生命周期等原因, 这并非想象的那么容易.
本文整理了在现有项目中引入 Swoole4 并开启协程的一些步骤及需要注意的问题, 期望可以为有需要的人提供帮助.
前置要求
请阅读 Swoole 文档中环境依赖的章节, 本文只针对代码部分的调整. 下文默认已成功编译安装了 Swoole4 扩展.
框架代码部分
首先请查阅所用框架是否有结合 Swoole 的开源方案, 如 laravel- s 等. 如有可按需选用, 如没有也参照业务代码部分对框架代码进行改造.( 这会导致升级框架版本变困难 )
业务代码部分
- 首先阅读 Swoole 文档中协程编程须知的章节.
- 对单例对象按协程 ID 做隔离, 防止单例对象跨协程使用. 对 Mysql,Redis 等连接资源需要 defer 进行回收复用或关闭, 防止连接数持续增加.
- 对全局变量及常量做评估, 所有可能引起问题的地方全部按协程 ID 做隔离.
- 对项目内直接 echo,print 之类输出的位置做修改, 或使用 ob_start 方法进行获取输出内容进行处理.
- 对项目内使用不支持自动协程化的库做修改, 采用协程客户端进行替换.(如:curl).
- 对项目内使用 exit,die 的地方做修改.
- 对 static 静态类, 属性或变量及引用传递进协程的变量都要小心操作, 尽量避免这种情况, 只使用局部变量.
- 对每次修改做好单元测试, 做好备份及回滚措施.
- 可从某些单一场景下入手逐步进行修改.(如: 某个单一业务模块, 某个简单 PHP 脚本等).
总结
上述修改看似内容不多, 但是在一个现有的项目中进行修改并保证服务正常运行却并非易事, 希望大家小心操作, 早日成功.
正文完