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

翻看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开发者，想要跳槽也都在转语言，这是事实。