Shopify构建弹性平台的架构实践

发表于 2015-11-10 09:27:18

马上注册，结交更多数据大咖，获取更多知识干货，轻松玩转大数据

您需要登录才可以下载或查看，没有帐号？立即注册

x

译者：施聪羽

原文地址：https://scaleyourcode.com/blog/article/23

「

Shopify

构建弹性平台的架构实践

」

本文分享了电商解决方案提供商Shopify是如何使他们的平台弹性可扩展，这不仅是非常有趣的，它也是非常实用的，你的应用可以从中借鉴。以下为翻译正文。

>>>>Shopify的扩展性挑战

Shopify的电商系统解决方案，处理约3亿独立访客每月（这些用户访问并不是均匀分布的）。但是正如你所能看到的，这些3亿用户并没有以一种很分散的方式访问。

其中最大的挑战是被他们称之为“闪购”，指的是那些极端受欢迎的商店在特定时间进行促销。

例如，Kanye West在销售他们的鞋子时，加上Kim Kardashian，他们带来了50万的Twiter独立用户

他们还有来自Superbowel广告的用户。因为这样，他们对于流量没有一个准确的预估。有可能是200000用户同时在3:00参与特别销售，持续几个小时。

那么Shopify是如何应对这些流量的瞬间增长呢？尽管他们没有很好的处理特卖，那又如何保证不会影响到其他的商店？这些我们将在下一部分讨论，在我们简单的介绍了Shopify的架构后。

>>>>Shopify架构

尽管Shopify去年迁移到了Docker，他们却还是单体应用。我曾问过Simon，他告诉我他们并不想管理微服务。因为这样将来需要迁移或转型时更方便。

无论如何，他们的架构看起来像：一个请求通过Nginx转发到后端的服务集群，服务是运行在Docker上的Rails应用。

对于数据层，是有以下： - Memcached - Redis - ElasticSearch - MySQL - Kafka - Zookeper

最重要的是运行在各自的硬件上。当然有一些是运行在AWS。

为了减少开支，Shopify运行着一个多租的平台。这意味着不同的商店在同一个服务上例如：--shopA.com和shopB.com都是来自同一个服务上。

尽管迁移到Docker并不是那么容易，但他们还是从中受益：

迁移到Docker使得Shopify可以使用成百上千行Ruby代码在5分钟内运行集持续集成（在Docker之前是15分钟），并在3分钟内部署到300-400个节点，跨3个数据中心（以前是15分钟）。这些提升令人印象深刻。

>>>>如何处理通讯峰值

理想情况下，平台能够自动处理高峰值。但是这功能还并未实现。所以，他们在大规模销售活动前运行性能检查。

在Kanye West的例子中，他们用了2周的时间对平台关键部件做了大规模被动负载测试和性能优化。

为了运行不同的测试，他们列了一份表格称之为弹性矩阵。

这个弹性矩阵可以有助于我们判断系统服务故障的原因。

假如Redis服务宕机，Redis将作为内部检查的一部分。你是不是会将整个网站关闭并进入维护模式?当然不，你可以将所有用户登出，但仍然允许他们在没有登陆用户的情况下进行结帐。然后一旦Redis恢复，通过关联邮箱地址来填补用户账户的操作。

列出你的系统的清单(如storefronts，admin dashboards，API，等等...)然后设想一下如果某个服务挂掉 -- 系统中哪些部分将会受到影响?尝试去除掉这些依赖，将会使你的应用弹性得到极大的提升。这就像是一条链，你的系统健壮性将由链中最薄弱的决定。

为了进一步改善，Shopify团队开源了Toxiproxy和Semain。

Toxiproxy可以控制你系统各个部分的延迟。

Semain可以用于验证系统是否有单点故障。

关于弹性化更多的内容，请查看Simon相关的分享，介绍了很多细节，非常有趣。

除了这些弹性化的工作，Shopify还能够过度分配一些硬件资源。对于他们来说，相当便宜。但是如果你运行在云端，这并不便宜。仔细对比下收益与开销，看看过度配置是否有益与你。

另一个巨大的挑战是数据的可伸缩。自从Shopify支持金融交易，他们的数据库就必须实时同步。解决方案?Shopify在两年前使用Mysql shard方式。他们积极的使用更多的shard，更细粒度的，基于时间的shard。

Simon说数据库的伸缩是非常艰难的 -- 特别是sharding方案。不到迫不得已尽量不要使用。你可以尽量使用缓存，在你不得不使用shard之前。但是shard的好处之一是可以隔离事故。如果一个shard上的某些客户做了一些疯狂的事情，只有非常小的一部分用户会受此影响。

我们回到弹性测试，Simo强调大部分的数据库伸缩问题依赖于弹性化工作以及自动故障恢复。

>>>>
进一步的计划

继续向前，Shopify团队在探索应用服务之间的隔离层。另一个挑战是同时运行在不同地区的不同数据中心。这将会涉及到数据本地化以及异常事件隔离。

异常事件隔离可以参考Netflix的经验，更多文章可以参考Jeremy Edberg的访谈。

除了这些计划，他们还计划将自动化故障恢复更容易的在一天内多次执行。如果你对如何在多数据中心执行故障恢复测试，可以看Simon的访谈。

就目前而言，他们暂时没法在不零时停止交易系统的时候恢复整个数据中心。然而，他们目前正在努力克服这个问题。

>>>>可以采取的行动

关于本篇文章，我的目的是，介绍一些容易理解的知识，帮助你采取行动。你现在能做什么呢？嗯，你可能想避免分片，通过缓存更多来解决？由于成本问题不想使用过高的配置，通过检查弹性矩阵？即使你现在没有资源去做这些，构建一个这样的矩阵，甚至只是了解了这些思路也是有帮助的。

帐号		自动登录	找回密码
密码			立即注册

Shopify构建弹性平台的架构实践

马上注册，结交更多数据大咖，获取更多知识干货，轻松玩转大数据

站长推荐 /1