是的，为了更好的支持微服务，我们从PHP迁移到了Go

起初，我们认为坚持一门熟悉的语言是负责任的事情——我们是一个小团队，却已经冒了两次险：切换到微服务和完全重写我们的 Web 应用程序（高流量游戏平台）。

微服务和 PHP：概念性错配

我们熟悉的语言是 PHP，它支撑了我们现有的应用程序，有两个模糊的论据可以支持我们继续这么做下去：

• 我们熟悉 PHP，它开发很快题。为什么要放弃对我们有用的东西？

• 市面上有很多 PHP 开发人员。 选择 PHP 让我们更容易扩充团队。

这听起来非常合理，但是当我们清楚 PHP 真的不是我们的正确选择时，我们很快就放弃了这些想法。

1、PHP 具有较高启动开销

PHP 曾经被设计成（或长成）为运行短命令的脚本，因此持久并不是这个语言适合支持的特性。这意味着对于每个请求，数据库连接和类都必须重新被实例化，这增加了不必要的延迟开销。

当然熟悉这方面读者都知道，有解决方案，例如通过 PHP-FPM 或 Apache 的连接池或 C 绑定等方法，可以支持与 Redis 的持久连接。

但是，由于我们追求高性能，这些依赖使我们对选择 PHP 作为合适的工具存在疑虑。

2、容器化 PHP 是一个雷区

PHP 需要 Nginx 和 PHP-FPM（或类似工具）来实现进程和连接池管理等功能。这意味着对于每个部署的微服务，PHP-FPM 和 Nginx 也必须一起运行。这浪费了资源，也降低了扩展的效率。

还有优化配置的问题。优化单 PHP 实例已经很头大了，因为需要了解和配置 PHP，PHP-FPM 和 Nginx 这一堆组合，我们无法想象最终在弹性的 Kubernetes 环境中配置多个 PHP 栈的痛苦情形，您完全不知道在同一台机器上运行了哪些服务。

微服务器的复杂性在架构中：您正在处理一个由简单服务组成并且相互之间作用的复杂系统。既然我们已经致力于这