本文介绍了 Shopify 构建弹性平台的方法。这篇文章不仅读起来有意思，而且你可以把它运用到实践中，构建自有的弹性平台。
电商解决方案提供商 Shopify 每个月的独立访问用户大约有 3 亿。注意，这些用户访问并不是均匀分布的。
其中一个最大的挑战是“闪购”，即最流行的那些网店在特定时间内的销售活动。
例如， Kanye West 开卖新款鞋子。加上 Kim Kardashian ，他们在 Twitter 上有 5,000 万粉丝。
有些客户还在超级碗上打广告。因此， Shopify 根本无法预期届时有多大的访问流量。想想这种情况：在 3 点， 200,000 访客一涌而入，参与几小时后就会结束的特卖活动。
Shopify 该如何扩展，以应对突然增加的访问？即使扩展后不能很好地应对某一场特卖，那么怎么确保这场特卖不会影响其它网店呢？在下一节，我们首先介绍 Shopify 的应用架构，然后以此为背景，深入地讨论上述问题。
去年， Shopify 全面采用 Docker ，但是仍然采用单体的应用架构。 Simon 告诉我，之所以这么做，是因为转向微服务架构的代价不低。当然，由于全面采用 Docker ，如果他们将来决定转向微服务架构，也比较容易。
总之， Shopify 的架构大致是这样的：应用请求首先发送到 Nginx ，然后再转发到服务器应用集群，每个服务器应用是一个运行 Rails 应用的 Docker 容器。
在数据层，他们用到了：
- Memcached
- Redis
- ElasticSearch
- MySQL
- Kafka
- ZooKeeper
大部分软件运行自有的硬件上，少部分运行在 AWS 上。
为了减少成本， Shopify 运营了一个多租户平台，即不同的网店可能运行在同一台服务器上——例如， shopA.com 和 shopB.com 运行在一台服务器上。
虽然全面转向 Docker 并非一帆风顺，但是最终获得了下列好处：
只需大约 5 分钟，就能运行完数十万行 Ruby 代码的持续集成（没用 Docker 之前需要 15 分钟），部署到横跨 3 个数据中心的 300-400 台服务器上只需 3 分钟（以前需要 15 分钟）。多么令人印象深刻的成效。
平台最好自己就能处理访问的激增。不过，这还没完全实现，在每次大型售卖之前，他们运行一系列的性能检测。
以上面的 Kanye West 为例，他们提前花了两周的时间，把平台的关键部分组合在一起，进行广泛的被动负载测试和性能优化。
为了运行不同的测试，他们用到了弹性矩阵：
摘自 Simon 的大会报告
在某项服务失效时，弹性矩阵有助于搞清楚系统出了什么问题。
假设 Redis 服务不可用了。从弹性矩阵可以看出， Redis 是买单服务的一部分。这时候，是不是要整个网站下线，进入维护状态呢？当然不，可以让每个用户登出网站，仍然允许他们在没有客户账户的情况下继续买单。然后，一旦 Redis 服务恢复了，将电子邮件地址与客户账户关联，据此补上此前缺少的信息。
依次下线每一个服务（像网店前端、管理面板、API等等），看看此时系统的运行情况——这是否影响到系统的其它部分？尽量去掉服务之间的依赖，整个应用的弹性会因此显著地增加。这好比一条拉链，最弱的那一环决定了应用的健壮程度。
Shopify 开源了与之相关的两个工具： Toxiproxy 和 Semian 。
Toxiproxy 能够控制系统的延迟。
Semian 用于检验系统是否存在单点失效。
更多细节，请看 Simon 的大会报告（https://speakerdeck.com/sirupsen/dockercon-2015-resilient-routing-and-discovery），非常有意思的一个报告。
在弹性平台之上，由于 Shopify 拥有自己的硬件，它能够做到超额配置。对他们而言，这种解决方案很便宜，但是还是比在云上运行花费高。请仔细比较相应的代价和收益，确定这种方案是否适合你的需求。
数据存储的扩展是另外一个巨大的挑战。由于 Shopify 处理的是金融交易，他们的数据库必须保持同步。解决方案是什么呢？ 两年前 Shopify 就开始实施 MySQL 分片了。他们非常激进，力求经过一段时间后把数据库切分成更多更小的切片。
Simon 随即说道，数据库的扩展尤其是切片是相当难的。不到最后，别采用数据库切片，尽可能地利用缓存。采用切片后的一个好处是有助于事故的隔离。如果在某个切片中某个客户的数据发生灾难，也只会影响整个平台的一小部分。
说到对弹性的测试， Simon 强调说有了弹性平台和自动灾后恢复机制，大部分数据库扩展问题都已经被解决了。
接下来， Shopify 团队正在审视应用之间的隔离问题。另外一个主要问题是如何让网店同时运行在位于不同大洲的多个数据中心上。这不仅非常有利于保证数据本地性，也能避免意外事件的影响。
我访问 Jeremy Edberg 时，他说过 Netflix 也投入很多资源研究如何避免意外事件的影响。
除此之外，他们也在研究如何实现一天内的多次灾后恢复。在访谈 Simon 的页面，你能了解到他们如何在整个数据中心进行灾后恢复测试。
目前，如果要实现整个数据中心的灾后恢复，就不得不临时关闭买单服务。他们正在寻找相关的解决方案。
本文的目的是为读者提供行动指南。现在，你能做什么呢？是避免切片，更多地使用缓存吗？由于成本的原因，你可能无法超额配置，但是总可以检查一下弹性矩阵吧？即使现在还没有资源做这些事情，构建一个弹性矩阵，或者仅仅思考一下弹性的问题，也是有帮助的。