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

  • Andrew Morgan
  • 盖磊

2017 年 11 月 2 日

话题:DevOps语言 & 开发架构

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

DevOps语言 & 开发架构