为什么要从PHP转向Go.docxVIP

为什么要从PHP转向Go 2021-06-29 以下是译文。 在最后的时候，我们自认为应当使用本人生疏的编程言语，由于我们是一个小团队，而且已经做了两项冒险的举动：将我们的大流量玩耍平台切换到微服务和完全重建Web应用程序。 不过，最终，我们还是打算放弃PHP，转向Go。在这篇文章中，我们将解释为什么要这样做。我们还将共享一些微服务架构中有关数据库的观点。 微服务和PHP：错误的搭配 我们生疏的言语是PHP，它驱动着我们现有的应用程序，有两个模糊的理由支撑着我们使用PHP： 我们生疏PHP和它的怪特性，而且原来的程序运转得很好，我们为什么要放弃？ 外面有很多的PHP开发人员，PHP可以让我们的团队更简约地成长起来。 这些听起来都很正确，但是当我们清楚地生疏到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栈的苦痛，我们甚至不晓得在这同一台机器上还运转了其他什么东西。 对微服务来说，其简单性存在于架构中，由于你正在处理的是一个简单的交互系统。既然我们已经确定接受微服务架构，那么由于错误的选择了编程言语导致的消耗明显就不值得。 聘请的要求是什么？我们发觉这个所谓的要求对于我们现在这种情况是毫无意义的。像微服务一样，我们认为开发人员应当是编程言语无关的。我们宁愿聘请一位聪慧的并情愿为了完成工作而学习新的编程言语的开发人员，而不是一位坚持己见的专家。因而，从这个意义上来说，放弃PHP对我们来说是一种解放。 拥抱Go 我们次要偏向使用Node.js和Golang这两种言语。在做了一些争辩之后，我们最终打算放弃Node，使用Go。 那么为什么要使用Go呢？ 功能：?Go的二进制文件会生成一个长时间运转的进程，这意味着每个恳求和数据库连接的启动成本很低。这使得Go在处理大量的并发恳求时能保证极快的速度，由于Go言语（goroutines模块）专为网络和多核计算而设计。 Go可以编译出一个小巧便携的二进制文件。这使得Go格外适合在Docker容器中使用。部署我们的Go容器只需几秒钟，由于它们的体积很小（大多数是4-5MB），并且由于是静态链接，因而在容器内不需要OS或运转时依靠。例如，当使用Node Alpine Linux镜像时，我们的前端容器大约为55MB。 Go是类型严格的。这让代码中的内部通信更为牢靠，也有助于在构建期间捕获特别，而不是在运转期间。 Go的工具链的规模很大。虽然工具是很多编程言语关注的问题，但Google从一开头就处理了这个问题，他供应了大量常用的工具作为言语安装时的一部分。 我们也考虑到Go有这些缺点： Go不附带依靠管理器。不过Google正在努力实现这个功能。现在，你可以问一下你的供应商，或者看一下Glide这个工具。 太多的公式化代码。这是Go优雅和简约的另一面。 然而，我们必需接受这一点：用Go程序的确需要花上一些功夫，但它能提高代码质量，并让我们能够时辰晓得代码实际是如何运转的。 这并不是说全部的代码我们都用Go来写。对于服务器端渲染，我们使用Node，由于它允许我们在前端和后端之间共用代码规律。我们也可以使用Java来处理特定的问题，由于它已经存在了很长时间，并且拥有大量的库。我们期望能使用最合适的工具，对于大多数情况而言，Go是我们的首选。 巨大的囊地鼠(Gyga8K) 探究NoSQL 当我们开头使用Go言语来编写我们的第一个服务时，我们也开头考虑数据库的选择。我们习惯了过去为我们服务的MySQL，但它经常会成为功能的瓶颈。 在我们的传统架构中，我们使用了大量的Redis来进行缓存，它的功能