从PHP迁移到Java后又返回:不玩微服务啦 · allegro.tech


五年前,我们开始对Allegro平台进行重大技术改造。从那时起,我们已经从一个单片的1000万行代码PHP应用程序转变为一个800多个基于JVM的微服务系统。然而,这种新的架构结果却是一个死胡同,我们再也无法承受。今天,2019年4月1日,我们宣布回到我们的源头,希望在今年年底之前将所有JVM微服务重写为单个PHP应用程序。

现在的情况
经过5年的微服务,我们现在有800多个服务在生产中运行。其中大多数是用Java或Kotlin编写的,基于Spring Boot。我们每天都会制作数十种产品。然而,这些技术指标并未捕捉到我们的系统变得多么复杂。为了保持在竞争激烈的电子商务市场的顶端,我们需要一些根本简单的东西。我们需要PHP的简单性和可靠性。

改变的理由
我们目前的JVM微服务架构最令人失望的是单个功能落实到生产中到为用户服务正常运行需要的时间。我们主要归咎于Java和Kotlin的静态类型。它使代码冗长,并鼓励创建许多特定于域的类型。由于电子商务的上市时间很短的特点,我们开始重视PHP的表现力。
此外,PHP社区不太关注自动测试。因此,工程师花费更少的时间在编写测试代码上,而花更多的时间编写实际最终生成的代码。根据我们的经验,技术债务就像金融债务一样 - 只要你没有还清债务之前就有动力,这不是问题。
金丝雀部署现在是标准,PHP通过设计实现了这种做法。它就像通过SSH访问生产机器和修改终端中的文件一样简单。编写代码后,最终用户可以进行更改。这个敏捷过程允许我们的工程师在将更改提交到主存储库之前快速验证他们的想法。可以使用相同的过程在生产中应用快速修复。Java和Kotlin没有给我们这么强大的工具。
放弃微服务架构以支持monolith也将大大简化我们的基础架构。这意味着需要管理的应用程序更少,因此需要更少的业务流程,并且运行系统的人员也更少。这意味着更多的工程师正在进行实际的高效工作 - 为我们的网站制作表格并为我们的API制作JSON。

迁移
我们决定从小做起。3个月前,我们选择了7个工程团队,他们正在将他们的JVM微服务转换为单个PHP应用程序。我们通过为他们提供专门的培训来帮助我们的工程师适应新技术,旨在摆脱JVM世界的不良习惯。
其中一个培训课程我们称之为测试排毒。我们发现许多Java和Kotlin工程师都沉迷于自动测试覆盖他们的代码,发现很难不参与强制性的测试编写。在测试排毒会话期间,他们练习在没有单个测试用例的情况下创建大量代码,并要亲眼看看有无任何不好的事情发生。领导人需要确保所有工程师都能获得他们所需的支持。
我们还通过为工程师组织团队冥想,帮助从微服务转变为单片架构。它使他们能够融入他们在日常工作中迫切需要的团结和团结精神。
整体而言,迁移进展顺利。我们在前3个月内迁移了35个微服务,很快将确保每个工程团队采用新方法。

积极的影响
我们已经看到在新架构中工作对几个团队产生了很多积极影响。首先,让大量工程师投入一个存储库有助于将责任传播到我们的文化中。这导致工程师不会过分关注他们的产品并使他们保持放松和高效。
我们的工程师也变得更有效率,因为他们现在可以在像vim或emacs这样的轻量级编辑器中开发代码,而不是使用像IntelliJ这样的内存消耗工具。这允许他们在同时打开需要内存的Slack通信器的同时进行编码!
我们的用户似乎也对这一变化感到满意。他们过去常常每周都有几个新功能。现在他们每月获得一次稳定版本,这意味着更少的认知负担和安全感。我们希望将来能够在更长的迭代中发布。

最后,通过采用在初创公司中如此普及的PHP,我们希望证明,当我们说我们拥有创业文化时,我们的确意味着它。

结论
我们已经开始回到PHP monolith,并对结果感到兴奋。我们相信这将成为一种趋势,因为越来越多的公司对微服务和JVM语言感到失望。随着谷歌致力于支持PHP云功能的传言,PHP monolith似乎是未来的技术选择。​​​​​​​