# Shopify 如何擴展以處理來自 Kanye West 和 Superbowl 的 Flash 銷售 > 原文： [http://highscalability.com/blog/2015/11/2/how-shopify-scales-to-handle-flash-sales-from-kanye-west-and.html](http://highscalability.com/blog/2015/11/2/how-shopify-scales-to-handle-flash-sales-from-kanye-west-and.html)  *這是[縮放您的代碼](https://twitter.com/christophelimp)的創建者 Christophe Limpalair 提出的來賓[重新發布](https://scaleyourcode.com/blog/article/23)。* 在本文中，我們介紹了 Shopify 使平臺具有彈性的方法。 這不僅有趣，而且實用并且可以幫助您開發自己的應用程序。 ## Shopify 的擴展挑戰 Shopify 是一個電子商務解決方案，每個月處理大約 3 億獨立訪客，但是正如您所看到的，這 3 億人不會以均勻分布的方式出現。 他們的**最大挑戰之一是所謂的“閃存銷售”** 。 這些快速銷售是在非常受歡迎的商店在特定時間銷售商品的時候。 例如， **Kanye West** 可能會出售新鞋。 結合 **Kim Kardashian** ，僅 Twitter 上的**就有 5000 萬人以下**。 他們也有在超級碗上做廣告的顧客。 因此，他們不知道會有多少流量。 **可能有 200,000 人在 3:00** 出現，并在幾個小時內結束特價銷售。 **Shopify 如何適應這些流量的突然增加？** 即使他們無法在特定銷售中很好地擴展規模，也如何確保它不會影響其他商店？ 在簡要說明 Shopify 的上下文架構之后，這就是我們將在下一部分中討論的內容。 ## Shopify 的架構 即使 Shopify **去年移至 Docker** ，他們**仍未脫離 Monolithic 應用程序**。 我問西蒙（Simon）為什么，他告訴我說，他們并不會輕易承擔[微服務](http://martinfowler.com/articles/microservices.html "Microservices explanation")的開銷。 但是，如果他們決定走這條路，此舉使他們在將來可以更輕松地過渡。 無論如何，它們的體系結構看起來像這樣： 一個**請求**進入 **Nginx** ，然后進入運行中的**服務器集群 帶有 Rails 應用程序**的 Docker。 對于**數據層**，他們使用以下方法： * 記憶快取 * 雷迪斯 * 彈性搜索 * 的 MySQL * 卡夫卡 * 動物園管理員 此**的大部分運行在自己的硬件**上。 他們還在 AWS 上運行了**幾件事。 為了降低成本，Shopify **運行多租戶平臺**。 這意味著它們在單個服務器上有多個商店-例如，shopA.com 和 shopB.com 是從同一服務器提供服務的。 即使遷移到 Docker [并非一帆風順](https://www.youtube.com/watch?v=Qr0sATj9IVc "Simon Eskildsen on switching to Docker")，他們最終還是從中獲得了一些好處： 遷移到 Docker 使 Shopify 得以運行 **在大約 5 分鐘（Docker 之前的 15 分鐘）內在數十萬行 Ruby 上進行持續集成**，并在 3 個數據中心中將其部署到 300-400 個節點僅需 3 分鐘（之前 15 分鐘）。 這些是令人印象深刻的變化。** ## 他們如何處理交通高峰 理想情況下，平臺可以自行處理峰值。 這還沒有完全實現，因此他們在大量銷售之前要通過**性能清單**。 在 Kanye West 的示例中，他們坐了 2 周，并通過組合平臺的關鍵部分進行了**廣泛的被動負載測試和性能優化**。 為了運行各種測試，他們使用了稱為“彈性矩陣”的工具。  （圖片來自 [Simon 的會議演講](https://speakerdeck.com/sirupsen/dockercon-2015-resilient-routing-and-discovery "Simon Eskildsen on Resilient Routing and Discovery and Dockercon 2015")） **彈性矩陣**可以幫助確定服務提供時系統發生了什么 下跌降落。 說 Redis 失敗了，Redis 被用作結帳的組成部分。 您是否將整個站點拆毀并置于維護模式？ 不，您可以退出所有人，仍然允許他們在沒有客戶帳戶的情況下進行結帳。 然后，在 Redis 備份后，將電子郵件地址與客戶帳戶相關聯并填補空白。 進入系統列表（如店面，管理儀表板，API 等），然后查看服務中斷時會發生什么—系統的其他部分也會受到影響？ 嘗試**消除這些依賴關系，您的應用程序彈性將大大提高。** 這就像一條鏈，您的應用程序的強度僅與最弱的鏈接一樣強。  為了幫助此過程，Shopify 團隊**開源了 Toxiproxy 和 Semian** 。 [Toxiproxy](https://github.com/Shopify/toxiproxy "Toxiproxy") 會在您選擇的任何系統中引入**控制的潛伏期**。  [Semian](https://github.com/Shopify/semian "Semian") 用于驗證您沒有**單點故障**。  有關彈性的更多信息，請查看 [Simon 的會議演講](https://speakerdeck.com/sirupsen/dockercon-2015-resilient-routing-and-discovery "Simon Eskildsen on Resilient Routing and Discovery and Dockercon 2015")中的其中之一，他將提供更多詳細信息。 超級有趣。 在此彈性工作的基礎上，Shopify 還能夠**超額配置，因為他們擁有自己的硬件**。 對于他們來說這很便宜，但是如果您在云上運行，它可能不會那么便宜。 查看成本與收益的關系，看看是否對您有意義。 另一個大挑戰是擴展數據存儲。 由于 Shopify 處理金融交易，因此其數據庫*不能*不同步。 解決方案？ **Shopify 在大約 2 年前對 MySQL** 進行了分片。 他們非常積極地進行分片，并且目標是隨著時間的推移增加**和較小的分片**。 Simon 繼續說**擴展數據庫非常困難**-尤其是分片。 它幾乎總是應該是不得已的方法。 您可能需要先緩存很多東西。 但是分片的好處是它們有助于隔離事件。 如果一個客戶群中發生了一些瘋狂的事情，那么整個平臺中只有一小部分會受到影響。 回到彈性測試，Simon 強調說，大多數**數據庫擴展問題已通過許多彈性工作和自動故障轉移**得到解決。 ## 他們計劃進行哪些其他改進？ 展望未來，團隊正在研究**相互隔離的**層，它們相互為應用程序提供服務。 他們正在做的另一件事是讓**的商店同時用完不同大陸上的多個不同數據中心**。 這對于數據局部性來說非常重要，也可以防止意外事件。 杰里米·埃德伯格（Jeremy Edberg）在[的采訪](/interviews/interview/11 "Jeremdy")中告訴我，Netflix 也投入了大量資源來防范突發事件。 除了這些計劃之外，他們還研究**使故障轉移變得可以輕松地每天多次執行**。 如果您對它們如何在整個數據中心之間執行故障轉移測試感到好奇，請參閱 [Simon 的采訪頁面](/interviews/interview/14 "Simon Eskildsen interview with ScaleYourCode")。 就目前的情況而言，他們無法在不臨時取消檢出的情況下對整個數據中心進行故障轉移。 但是，他們目前正在研究一種解決方案，以解決此問題。 ## 采取的行動 My goal with this article is to give you easily-digestible knowledge you can take action on. What action(s) can you take now? Well, you probably want to avoid sharding, so can you cache more? You may not be able to over-provision due to cost, but what about checking out the resiliency matrix? Even if you don't have the resources to pull this off right now, building one of these matrices or even just thinking about it can be helpful. 如此高的收益率是您的瓶頸。 沒有留下深刻印象