微服务和PHP或许“并不是”错误的搭配 

发布于 2023-03-25  1 次阅读


翻看18年的日志,发现了以前的思考

微服务和PHP或许是个错误的搭配

向微服务架构迁移,是希望大流量的基础架构(每日200万+活跃用户)具备可扩展性。
从长远来看,随着1000万甚至更多用户发展的时候,基础设施也应该能相应地进行扩大。

PHP无法满足这些需求,因为:
PHP的启动成本很高。 PHP一开始是为短生命周期脚本的运行而设计的,因此持久性并不是其原生特性。这意味着对于每个请求、数据库连接和类都必须实例化,这增加了不必要的开销。当然,这也是有办法解决的,例如通过PHP-FPM或Apache来创建连接池,或者绑定C以获得与Redis的长连接。但是,由于需要追求高性能,对于这个系统来说,这些依赖可能使PHP并不是一个合适的工具。

容器化的PHP是一个雷区。 PHP需要借助Nginx和PHP-FPM(或类似的软件)来进行进程管理和连接池管理。这意味着对于部署的每个微服务来说,PHP-FPM和Nginx必须同时运行。这既浪费了资源,又降低了效率。对运行在服务器上的PHP实例进行优化也是相当困难的,因为需要同时熟悉PHP、PHP-FPM和Nginx的配置。在弹性Kubernetes环境上配置多个PHP栈是十分痛苦的,开发人员甚至不知道在这同一台机器上还运行了其他什么东西。

对微服务来说,其复杂性存在于架构中,因为要处理的是一个复杂的交互系统。既然已经确定采用微服务架构,那么因为编程语言导致的消耗显然就不值得。

相比之下,向Golang转变显然是一种更为合适和明智的选择。

性能: Go的二进制文件会生成一个长时间运行的进程,这意味着每个请求和数据库连接的启动成本很低。这使得Go在处理大量的并发请求时能保证极快的速度,因为Go语言(goroutines模块)专为网络和多核计算而设计。

Go可以编译出一个小巧便携的二进制文件。这使得Go非常适合在Docker容器中使用。部署我们的Go容器只需几秒钟,因为它们的体积很小(大多数是4-5MB),并且由于是静态链接,因此在容器内不需要OS或运行时依赖。

Go是类型严格的。这让代码中的内部通信更为可靠,也有助于在构建期间捕获异常,而不是在运行期间。

现在我的想法变了。

Go的优势无可比拟,在长链接大流量高并发的场景中,可以说是压倒性的优势,但是这并不能否定PHP存在的意义。

诚然,App小程序发展壮大的同时,web端市场的萎缩日益明显,PHP和WEB的关系决定了一荣俱荣一损俱损。

之前陷入了一个误区,“PHP是万能的”,如果抱着这种想法,PHP的缺点再明显不过了,又要马儿不吃草又要马儿跑,显然是不可能的

PHP就应该存活在WEB的世界,协程很美好,编译很美好,但是PHP真的需要吗?能在WEB开发领域做到NO.1,还要什么自行车?

对于附属基础建设的依赖,可以通过制度和架构去分离,容器化PHP正是为了解决过于依赖nginx的问题。

容器化以后Pod之间的隔离可以让运维清晰高效地定位和处理问题,这样的资源浪费是在可容忍的必要开销。

当然,作为混职场的coder,目标如果是大厂开发岗,PHP确实已经没啥前途了,大厂需要的不是低成本高效开发,而是高速稳定运行。

不缺资金的大厂,没有人就去招,服务器慢就去买,coder个人独立开发的能力已经被压缩到单一职能,对于PHP是浪费,也是一种负担。

且大厂即使出现PHP的招聘消息,要求也都是远高于同级别的其他语言岗位。暂时屈就于小厂的PHP开发者,想要跳槽也都在转语言,这是事实。

如果作为独立开发者来讲,我还是觉得PHP真香,至少还能打十年,况且JIT现在也实装了,依我看,不止十年。


君子慎独,不欺暗室。卑以自牧,含章可贞。