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

作者:UEESHOP 浏览次数:889 发布时间:2017-10-13

>>>>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的访谈。
 

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

>>>>可以采取的行动

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

建站客服建站客服
交流QQ群交流QQ群
QQ交流1群
QQ交流1群
627102802
QQ交流2群
QQ交流2群
2966345452
热门文章

热门文章

广州联雅网络科技有限公司 UEESHOP©版权所有 粤ICP备10215284号 网站地图