Shopify如何将店面响应速度提高4倍

2019年1月，我们着手重写驱动Shopify平台上所有在线店面的关键软件，以提供尽可能快的在线购物体验，完全从头开始，且无需停机。Storefront渲染器是一个服务器端应用程序，它加载Shopify商家的店面液体主题以及服务请求所需的数据(例如，产品数据、集合数据、库存信息和图像)，并将HTML响应返回给您的浏览器。将响应时间缩短几毫秒会给平台上的商家带来巨大的收益，因为买家越来越希望页面能快速加载，而未能提供性能可能会阻碍销售，更不用说其他重要的信号了，比如搜索引擎优化(SEO)。上一个店面实施的开发始于15年前，当时Tobi推出了Snowdeder，就住在Shopify的Ruby on Rails巨石中。多年来，我们意识到Shopify的“店面”部分与整体的其他部分有很大的不同：它有更严格的性能要求，可以接受更复杂的实施方式来提高性能，而其他组件(如支付处理)需要提高正确性和可读性。除了这种范式上的差异之外，随着我们看到平台上的店面流量增加，店面请求的计算速度逐渐变慢。这种性能下降直接影响了我们的商家店面的性能，其中来自Shopify服务器的第一个字节的时间指标随着时间的推移而缓慢上升。下面是以前的体系结构：旧的店面实施之前，Rails单体处理几乎所有类型的流量：结账、管理、API和店面。对于新的实施，流量路由看起来如下：新的店面实施Rails单体仍然处理结账、管理和API流量，但是店面流量是由新的实现来处理的。从头开始设计新的店面实现使我们能够考虑我们可以提供的保证：我们利用这个长青项目的机会，将我们设置在将来可以扩展的强大的原语上，而在旧的实现中改造这些原语会困难得多。这些基础的一个例子是决定在主动-主动复制设置的基础上设计新的实施。因此，新实现始终从专用读取副本读取，从而提高性能并减轻主写入方的负载。类似地，通过在专用应用程序中重新构建和提取与店面相关的代码，我们抓住机会考虑构建尽可能最佳的开发人员体验：出色的调试工具、简单的入职设置、欢迎文档等等。最后，将提高性能作为优先事项，我们致力于提高高负载情况下的弹性和容量(想想闪电销售：大量买家突然开始在特定在线店面购物的事件)。最终结果是一个快速、有弹性、用途单一的应用程序，可以尽可能快地为Shopify平台上的商家提供高吞吐量的在线店面流量。定义我们的成功标准一旦我们清楚地概述了我们试图解决的问题并确定了项目的范围，我们就定义了三个主要的成功标准：建立功能对等：对于给定的输入，两个实施都会生成相同的输出。提高性能：新的实施在主动-主动复制设置上运行，并最大限度地减少服务器响应时间。提高恢复能力和容量：我们需要一种方法来确保我们构建的任何东西都将以与现有实现相同的方式运行。因此，我们构建了一个验证器机制，该机制比较两种实现的输出，并根据比较结果返回肯定或否定的结果，该验证机制运行在生产中的店面流量上，并跟踪验证结果，以便我们可以识别需要修复的输出差异。在生产流量上运行验证器机制(除了通过正式规范和测试套件在本地比较实现)，使我们能够确定修复问题时要处理的最有效的领域，并使我们专注于奖励：尽快达到功能对等。它的可取性有多个原因：给我们一个进度的概念，并将风险分散在大量的时间上-缩短Shopify的开发人员一次使用两个并发实现的时间，尽快为Shopify商家提供价值。整个验证器机制的实现有两个部分：a