PHP转Go系列 | 如何将 PHP 项目快速迁移到 Go 上？

大家好，我是码农先森。

最近在闲逛 v2ex 社区时，看到有个讨论 PHP 项目能否直接迁移到 Go 语言上的话题。我大概简述一下提问v友的原话，他们因为项目性能的问题在 2020 年时，从 Laravel 框架迁移到了 Hyperf 框架，在完成迁移之后，性能确实提升了一大截。但这位v友发现 Hyperf 框架的作者，对该框架的积极性已经不高，这一点体现在他近期遇到的技术问题，在 Github 上提 Issue 几乎已经不在被回答了。由此引发了他的焦虑，他怕 Hyperf 框架后面停止更新，假设遇到致命的 Bug 无法解决，那么项目的结果将彻底黄了。

因此，他开始着想能不能把项目直接迁移到 Go 语言上，但又担忧用 Go 语言全部重写，时间成本和技术成本又太高了。其实很多v友对这个话题都很感兴趣，大家也提了很多的建议给他。因为我自己也是从 PHP 转到 Go 的，深知 PHP 的一些技术瓶颈和天生的缺陷。

不仅是这位v友遇到这个问题，我相信大多数的PHP程序员，都会遇到同样的问题。 在刚开始遇到性能问题时，会优先考虑 Swoole、Workerman 之类的框架，如果在使用了这些框架也无法满足其性能的情况下。便会开始考虑其他的语言，近年来 Go 语言风靡全球，因此很多人都会优先选择 Go 语言。

那由此就产生了一个很棘手的问题，在业务快速发展，又不能停机的情况下，如何能快速的将项目迁移到 Go 语言上呢？在这个问题上，我个人有这三方面的建议，希望能对大家有所帮助。

首先，一开始不要想着一口吃成大胖子直接全部重写，这样操作带来的复杂度和时间周期会很长。一旦时间拉的很长，大家开发的积极性，便会逐渐地降低。我遇到过很多类似的情景，刚开始时大家都满怀激情，但随着时间的推移，大家的耐心便一点点被消磨掉了，在这种状态下重写的项目会产生很多的问题，如果达不到预期的话，会很打击大家的信心。因此，我们要准确的分析现有项目中的问题，到底是业务逻辑的问题，还是数据库的问题，还是语言本身的问题。如果是语言的问题，需要拆解出具体的接口，把这个接口的业务单独用 Go 语言来实现，然后上线之后再用流量分发的方式，将一部分的流量转发到 Go 语言上，如果稳定之后便可以直接把这个接口流量全部切换到 Go 语言。采用这种单点迁移的方式，能够很快的验证 Go 语言所带来的性能价值，这样做短期内就能看到效果，能让大家最直接的感受到性能的跃身，对后期的工作开展也会很顺利。

其次，迁移项目是一个系统性工程，我们在刚开始尝到甜头时，都会比较兴奋与得意。我觉得可以得意，但是不能忘本。大家本意上还是想提高整个项目的性能，不能遇到一个就单点解决一个。做好一个长期的规划，这一点尤其重要。还有就是要认识到 Go 语言并不是万能的，别妄想任何问题都能通过 Go 语言来解决。每一门语言或技术，都有自身擅长的领域和方向。比如 Go 语言在生态和轮子方面并没有那么多，如果长期习惯了 PHP 的拿来主义，用 Go 可能很不顺手。这一点需要自己有个清晰的认知，否则会很打击自信心。

最后，大家要做一名长期主义者，不要三天打鱼两天晒网，我见过很多的人，今天觉得 Go 语言好，便用 Go 语言。明天又觉得 Java 好，然后又开始尝试。如果遇到点问题，解决不了，一旦听别人说 Rust 简单好用性能高，结果又跑到 Rust 的领域去了。其实，每门语言的本质都是相通的，不要总是认为这个好那个好，我们要能够看透本质。在电影教父里面有这样一句话，花一分看懂事物本质的人和花一辈子的人，两者的命运会截然不同。

从近些年来看经济的不景气，造成了不仅是互联网行业，其他行业也都面临着停滞的问题。在我们编程行业里，尤其表现在很多的开源项目都停止了更新，毕竟大家也不能靠爱发电。俗话说背靠大树好乘凉，我们在选择一些开源项目时，尽可能选一些有背景大公司的，像一些个人开发者要尽可能的避坑。大环境我们改变不了，我们能做的是让自己做一些正确的选择。著名作家罗曼·罗兰曾说过：世界上只有一种真正的英雄主义，就是认清了生活的真相后还依然热爱它。借此我也想把这句话送给大家，让大家对编程依然保持热爱，而不是只为了吃饱饭，做一名热爱编程的长期理想主义者。

感谢大家阅读，个人观点仅供参考，欢迎在评论区发表不同观点。

说个题外话，由于近年来大环境不好，我开始研究了些副业，也分享给大家，如果有需要的朋友可以在公众号内私信「副业」不喜略过哈。

欢迎关注、分享、点赞、收藏、在看，我是微信公众号「码农先森」作者。

本作品采用《CC 协议》，转载必须注明作者和本文链接