圖片

如果你曾參與開發過一個僅因幾千用戶訪問就變慢的 Web 應用，那么試著想象一下一個用戶量達到數十億人時會是什么樣子。

現在再想象一下，它實現這一切并非依靠數百個微服務，也并非依靠每年一次的前沿技術重寫，而是僅僅依靠一個設計巧妙、紀律嚴明、架構優美的單體架構。

這是一個真實的故事，講述 Shopify 如何每分鐘處理超過 20 TB 的數據，如何運營著全球最大的電子商務平臺之一，同時仍能保持其架構的簡潔、可擴展且出人意料地人性化。

黑色星期五

對大多數公司而言，黑色星期五是壓力巨大的。

對 Shopify 呢？這是傳奇性的時刻。

當午夜鐘聲敲響時，來自世界各地的流量如洪水般涌入。

數以百萬計的人們同時打開由 Shopify 驅動的商店，如 Gymshark、Kylie Cosmetics 和 Allbirds。

在 2021 年的黑色星期五周末期間：

Shopify 每分鐘處理30 TB 的數據

他們的服務器每分鐘承受超過 3200 萬次請求

每秒處理1100 萬次 MySQL 查詢

每分鐘產生超過 390 萬美元的銷售額

而且，系統沒有崩潰。

沒有中斷。

沒有不眠之夜。

只有平穩的擴展。

那么，秘訣是什么？

成長起來的單體架構

Shopify 的架構圍繞一個模塊化單體構建——這是一個主要用 Ruby on Rails 編寫的單一代碼庫，但被精心地構建成具有邏輯邊界。

與將所有東西拆分成細小的微服務（每個微服務都有自己的基礎設施、部署流程和復雜性）不同，Shopify 將其單體架構視為一個由街區組成的城市——一個城市，多個區域。

每個"區域"或組件負責一個業務領域：

• 結賬
• 支付
• 訂單
• 管理后臺
• 庫存
• 分析

簡單視圖：

每個模塊都擁有：

• 自己的數據所有權
• 自己的公共 API
• 自己的維護團隊

它們在同一代碼庫內相互隔離——這意味著更少的部署麻煩和更緊密的集成。

Shopify 使用一個名為 Packwerk 的內部工具來強制執行這種紀律。

它能自動檢測到一個模塊何時訪問了它不該訪問的其他模塊。

這就是為什么一個擁有 10 多年歷史、由數千名工程師維護的單體架構，至今仍能保持清晰和模塊化。

引入六邊形架構

如果說模塊化決定了什么功能位于何處，那么六邊形架構則決定了這些部件如何與外部世界通信。

六邊形架構也被稱為端口與適配器模式，它讓 Shopify 能夠將其核心邏輯與外部混亂（如 API、數據庫或隊列）獨立開來。

核心思想如下：

應用程序是一個六邊形——中心（業務邏輯）永不改變，而邊緣（適配器）負責處理與外部世界的通信。

在 Shopify 世界中的運作方式

讓我們以"創建訂單"為例。

傳統方法（緊耦合）：

• 控制器直接調用數據庫
• 業務邏輯存在于控制器內部
• 對 API 的任何更改都會破壞一切

六邊形方法（Shopify 的方式）：

────────────────────────┐
│              Web Layer               │
│ (GraphQL, REST, Mobile APIs, etc.)   │
└──────────────────┬───────────────────┘
                   │
                   ▼
     ┌────────────────────────────┐
     │    Application Service     │
     │ (CreateOrderUseCase Port)  │
     └────────────┬───────────────┘
                  │
           (via Interface)
                  │
     ┌────────────────────────────┐
     │        Adapters            │
     │ (MySQL, Kafka, Redis etc.) │
     └────────────────────────────┘

當客戶點擊"結賬"時，流程如下：

• API 適配器接收到請求
• 將其傳遞給核心用例——CreateOrderUseCase
• 該用例運行領域邏輯：庫存檢查、支付驗證、折扣規則等
• 適配器層將結果持久化到 MySQL 或向 Kafka 隊列發送消息

關鍵點在于？

核心邏輯從不知曉也無需關心數據是來自 GraphQL、REST 還是一個 CLI 任務。

這種隔離意味著 Shopify 可以在不觸及業務邏輯的情況下，演進技術——更換隊列、重構 API 或切換數據庫。

Pods

單體架構的水平擴展

當你運營著一個托管數百萬商店的平臺時，一次病毒式的產品發布就可能拖垮整個平臺。

Shopify 通過 Pods 優雅地解決了這個問題——即單體架構的隔離集群。

每個 Pod 就像一個小型的 Shopify：

• 獨立的數據庫分片
• 獨立的緩存
• 獨立的任務隊列
• 獨立的工作進程

所有請求都通過一個名為 Sorting Hat 的智能內部服務（是的，就像《哈利·波特》里的分院帽一樣 ）路由到正確的 Pod。

其結構如下所示：

因此，如果 Kylie Jenner 的新產品發布導致 Pod A 崩潰，Pod B（服務于其他 10 萬家商店）甚至不會察覺到。

這就是 Shopify 在全球范圍內擴展的方式，而無需碎片化成數百個微服務。

數據流

在每一次"加入購物車"點擊的背后，是海量的數據流動。

Shopify 是這樣處理的：

Shopify 的數據管道隨著時間不斷演進：

• 舊系統：Longboat —— 每小時復制數據的批量查詢
• 新系統：Debezium + Kafka —— 實時變更數據捕獲

現在，每一個數據庫變更——一個新訂單、退款或更新——都會實時流入 Kafka。

這使得在 PB 級的數據上實現實時儀表板、即時欺詐檢測和實時分析成為可能。

優雅應對流量峰值

當 100 萬人在同一秒點擊"加入購物車"時，你不能依賴蠻力。

Shopify 依賴的是精巧的緩存和受控的服務降級。

• 邊緣緩存（CDN）： 直接提供靜態頁面和媒體資源。
• Redis/Memcached： 處理會話、預計算數據和快速讀取。
• 后臺隊列： 卸載高成本任務（電子郵件、Webhooks、分析）。
• 優雅降級： 在流量峰值期間，非核心功能自動暫停。

例如：如果在某位名人產品發布期間流量激增 100 倍，推薦功能可能會暫停，但結賬功能絕不會中斷。

可預測性勝過臨時救急。

堅持使用 MySQL

Shopify 仍然使用 MySQL 作為其核心數據庫。

但他們將其擴展到了地球上少有的規模。

• 數百個分片分布在各個 Pod 中
• 每秒超過 1000 萬次查詢
• 跨副本的自動負載均衡
• 基于快照的備份，恢復窗口為 30 分鐘
• 在線模式變更，實現零停機時間

他們甚至編寫了內部系統，以動態地在分片間重新平衡商店，從而避免任何單一數據庫成為熱點。

這不是什么炫酷的技術。

這是枯燥的卓越。

黑色星期五值班是怎樣的體驗

一位工程師曾說：

"你為戰斗做好準備。你預想著警報會響。你想象著混亂。但當流量來襲時——圖表曲線飆升，Pods 嗡嗡作響，緩存正常工作，然后……什么也沒崩潰。你只是小口喝著咖啡，微笑著。"

這就是大規模下簡潔架構的魔力。

當一切都在平穩運轉時，一年中最繁忙的一天也會顯得很平靜。

我們都能借鑒的經驗教訓

你不需要運營 Shopify 也能應用他們的經驗：

1、從單體開始，向模塊化發展

除非必要，否則不要拆分系統。復雜性代價高昂。

2、遵循六邊形架構原則

保持業務邏輯清晰，并與 I/O 解耦。

3、隔離故障

Pods、分片或領域——無論采用何種方式，都要限制故障波及范圍。

4、采用流式處理，而非批量處理

實時數據支持更快的反饋和更清晰的數據管道。

5、故障做好優雅降級計劃

降級非核心功能，保護核心功能。

6、讓'枯燥'變得美好

最好的架構是那種讓人覺得平淡無奇的架構。

最后的思考

Shopify 的故事無關炒作或流行詞。

它關乎的是清晰性、工藝精神以及在規模下的從容。

他們證明了，一個設計良好的單體架構，在六邊形架構和嚴格的模塊化指導下，即使是在互聯網規模下，其性能也能超越一團亂麻的微服務網絡。

當你的平臺每分鐘推送20 TB 數據，而全世界都在不停購物時，簡單并非壞事，而是卓越的體現。

總結圖：Shopify 的六邊形單體架構

圖片

這就是 Shopify——一個每分鐘處理數 TB 數據、維持數百萬企業運營的六邊形單體架構，它證明了簡潔性可以擴展。

作者丨Himanshu Singour   編譯丨Rio

來源丨網址：https://medium.com/@himanshusingour7/how-shopify-handles-30tb-of-data-every-minute-with-a-monolithic-architecture-cad54df86955