如何用5分鐘完成數(shù)十萬行Ruby代碼持續(xù)集成
【編者的話】在構建大型分布式系統(tǒng)應用時，如何降低不同部分之間的依賴，增強系統(tǒng)的彈性，電商解決方案提供商 Shopify 給出了解決方法。
本文介紹了 Shopify 構建彈性平臺的方法。這篇文章不僅讀起來有意思，而且你可以把它運用到實踐中，構建自有的彈性平臺。
Shopify 面臨的擴展挑戰(zhàn)
電商解決方案提供商 Shopify 每個月的獨立訪問用戶大約有 3 億。注意，這些用戶訪問并不是均勻分布的。
其中一個***的挑戰(zhàn)是“閃購”，即***的那些網(wǎng)店在特定時間內(nèi)的銷售活動。
例如， Kanye West 開賣新款鞋子。加上 Kim Kardashian ，他們在 Twitter 上有 5,000 萬粉絲。
有些客戶還在超級碗上打廣告。因此， Shopify 根本無法預期屆時有多大的訪問流量。想想這種情況：在 3 點， 200,000 訪客一涌而入，參與幾小時后就會結束的特賣活動。
Shopify 該如何擴展，以應對突然增加的訪問?即使擴展后不能很好地應對某一場特賣，那么怎么確保這場特賣不會影響其它網(wǎng)店呢?在下一節(jié)，我們首先介紹 Shopify 的應用架構，然后以此為背景，深入地討論上述問題。
Shopify 應用架構
去年， Shopify 全面采用 Docker ，但是仍然采用單體的應用架構。 Simon 告訴我，之所以這么做，是因為轉向微服務架構的代價不低。當然，由于全面采用 Docker ，如果他們將來決定轉向微服務架構，也比較容易。
總之， Shopify 的架構大致是這樣的：應用請求首先發(fā)送到 Nginx ，然后再轉發(fā)到服務器應用集群，每個服務器應用是一個運行 Rails 應用的 Docker 容器。
在數(shù)據(jù)層，他們用到了：
- Memcached
- Redis
- ElasticSearch
- MySQL
- Kafka
- ZooKeeper
大部分軟件運行自有的硬件上，少部分運行在 AWS 上。
為了減少成本， Shopify 運營了一個多租戶平臺，即不同的網(wǎng)店可能運行在同一臺服務器上——例如， shopA.com 和 shopB.com 運行在一臺服務器上。
雖然全面轉向 Docker 并非一帆風順，但是最終獲得了下列好處：
只需大約 5 分鐘，就能運行完數(shù)十萬行 Ruby 代碼的持續(xù)集成(沒用 Docker 之前需要 15 分鐘)，部署到橫跨 3 個數(shù)據(jù)中心的 300-400 臺服務器上只需 3 分鐘(以前需要 15 分鐘)。多么令人印象深刻的成效。
如何處理流量激增
平臺***自己就能處理訪問的激增。不過，這還沒完全實現(xiàn)，在每次大型售賣之前，他們運行一系列的性能檢測。
以上面的 Kanye West 為例，他們提前花了兩周的時間，把平臺的關鍵部分組合在一起，進行廣泛的被動負載測試和性能優(yōu)化。
為了運行不同的測試，他們用到了彈性矩陣：
(摘自 Simon 的大會報告)
在某項服務失效時，彈性矩陣有助于搞清楚系統(tǒng)出了什么問題。
假設 Redis 服務不可用了。從彈性矩陣可以看出， Redis 是買單服務的一部分。這時候，是不是要整個網(wǎng)站下線，進入維護狀態(tài)呢?當然不，可以讓每個用戶登出網(wǎng)站，仍然允許他們在沒有客戶賬戶的情況下繼續(xù)買單。然后，一旦 Redis 服務恢復了，將電子郵件地址與客戶賬戶關聯(lián)，據(jù)此補上此前缺少的信息。
依次下線每一個服務(像網(wǎng)店前端、管理面板、API等等)，看看此時系統(tǒng)的運行情況——這是否影響到系統(tǒng)的其它部分?盡量去掉服務之間的依賴，整個應用的彈性會因此顯著地增加。這好比一條拉鏈，最弱的那一環(huán)決定了應用的健壯程度。
Shopify 開源了與之相關的兩個工具： Toxiproxy 和 Semian 。
Toxiproxy 能夠控制系統(tǒng)的延遲。
Semian 用于檢驗系統(tǒng)是否存在單點失效
更多細節(jié)，請看 Simon 的大會報告，非常有意思的一個報告。
在彈性平臺之上，由于 Shopify 擁有自己的硬件，它能夠做到超額配置。對他們而言，這種解決方案很便宜，但是還是比在云上運行花費高。請仔細比較相應的代價和收益，確定這種方案是否適合你的需求。
數(shù)據(jù)存儲的擴展是另外一個巨大的挑戰(zhàn)。由于 Shopify 處理的是金融交易，他們的數(shù)據(jù)庫必須保持同步。解決方案是什么呢? 兩年前 Shopify 就開始實施 MySQL 分片了。他們非常激進，力求經(jīng)過一段時間后把數(shù)據(jù)庫切分成更多更小的切片。
Simon 隨即說道，數(shù)據(jù)庫的擴展尤其是切片是相當難的。不到***，別采用數(shù)據(jù)庫切片，盡可能地利用緩存。采用切片后的一個好處是有助于事故的隔離。如果在某個切片中某個客戶的數(shù)據(jù)發(fā)生災難，也只會影響整個平臺的一小部分。
說到對彈性的測試， Simon 強調(diào)說有了彈性平臺和自動災后恢復機制，大部分數(shù)據(jù)庫擴展問題都已經(jīng)被解決了。
接下來，他們準備提高哪些方面?
接下來， Shopify 團隊正在審視應用之間的隔離問題。另外一個主要問題是如何讓網(wǎng)店同時運行在位于不同大洲的多個數(shù)據(jù)中心上。這不僅非常有利于保證數(shù)據(jù)本地性，也能避免意外事件的影響。
我訪問 Jeremy Edberg 時，他說過 Netflix 也投入很多資源研究如何避免意外事件的影響。
除此之外，他們也在研究如何實現(xiàn)一天內(nèi)的多次災后恢復。在訪談 Simon 的頁面，你能了解到他們?nèi)绾卧谡麄€數(shù)據(jù)中心進行災后恢復測試。
目前，如果要實現(xiàn)整個數(shù)據(jù)中心的災后恢復，就不得不臨時關閉買單服務。他們正在尋找相關的解決方案。
采取的行動
本文的目的是為讀者提供行動指南?，F(xiàn)在，你能做什么呢?是避免切片，更多地使用緩存嗎?由于成本的原因，你可能無法超額配置，但是總可以檢查一下彈性矩陣吧?即使現(xiàn)在還沒有資源做這些事情，構建一個彈性矩陣，或者僅僅思考一下彈性的問題，也是有幫助的。
如果你覺得上述挑戰(zhàn)很有意思，告訴你， Shopify 正在招人。
你最依賴的系統(tǒng)是什么?不妨在評論中與我們分享哦。
