GoTo 2017 哥本哈根大会：Shopify 如何支撑在线商务

Shopify 高级产品工程主管 Simon Eskildsen 在 GoTo 2017 哥本哈根大会上做报告，概述了 Shopify 是如何构建支持大规模销售的架构。报告内容涉及使用 OpenResty 配置 NGINX 实例、商店和 Pod 的隔离架构、故障转移策略等。

据 Eskildsen 介绍，Shopify 为大量的在线商务提供服务，正支持超过 50 万家商户。其中不少商户只提供在线商店，它们的一个主要需求就是能将销售快速地交付给它们的客户。尽管驾驭销售流量本身并非难事，但是所面对的主要挑战在于创建一种可应付突发大流量的架构。

据 Eskildsen 介绍，Shopifys 的首个优化调整就是在 DNS 层。对单个域在 DNS 层的流量优化是很容易实现的，但是对于多个域则是难以企及的。Shopify 面对正是这样的问题，多个客户域都指向其 IP。Spotify 的做法是使用 TCP/ICP 任播（Anycast）技术，这是一种“gossip 算法，其中每个 ISP 告知其近邻的所有 ISP 它知道如何路由的 IP 情况”。这基本上导致了流量总是会选择最近的 IP。

Shopify 也大量地使用了 OpenResty。该工具允许使用 Lua 编写所需 NGINX 负载均衡器实现的任何功能。Eskildsen 强调，就 Shopify 的使用情况来看，OpenResty 是非常强大的。他相信，总体说来 OpenResty 并未在行业中得到充分的利用。他列出了在 Shopify 使用的一些模块：

• Rule banner：通过查看不规则刷新、可疑 IP 地址等异常模式发现僵尸程序（bot），进而禁止这些异常模式。该模块的目的是关闭二级市场。
• Edge cache：对缓存做优化，允许在负载均衡层而非应用层的缓存提供内容。
• Checkout throttle：节流机制通过对一些商户进行排队，实现对这些商户在异常负载情况下的写入操作，从而防止一家商户变成同一片上其余商户的嘈杂邻居。

Eskildsen 还介绍了 Shopify 引入的“Pod”概念。Pod 用于应用层或数据层上，是一种完全隔离的 Shopify 实例，其中包含了很多的商店。在设计上是不允许 Pod 间和商店间通信，因为关键在于客户间的隔离。“商店隔离原则，所有的商店必须相互隔离”。

尽管每个 Pod 都包含了自身的有状态服务（例如数据库），无状态服务也是共享的。Eskildsen 解释说，这样做的主要原因是自动扩展引入了过量的瓶颈问题。相比于新架构所考虑到的情况，流量尖峰会来得更快。

Eskildsen 还概要地介绍了 Pod 负载均衡器。Pod 负载均衡器用于均衡 Pod 间的商店，并确保负载的平均分布。为快速实现此目标，同时不损失数据的一致性，Shopify 使用了 MySQL 的二进制日志，使数据库更改事件从旧实例流到新的实例。

对于跨区域迁移，Shopify 还提供了一个称为“Pod Mover”的组件，以最小的宕机时间实现 Pod 的跨区域移动。当一个区域不工作时，就激活迁移。但是 Eskildsen 解释说，他们的最终目标是给出一个 Slack 命令，这样就可以在任一时刻触发此类故障迁移。

完整的演讲可在线观看，其中对这一架构做了更详细的解释。

查看英文原文： GoTo Copenhagen 2017: How Shopify Powers Online Commerce