隨着加密貨幣及區塊鏈技術日益火爆，區塊鏈的可擴展性逐漸成爲制約其應用落地的痛點之一，2017 年引爆加密世界的加密貓遊戲就曾讓以太坊網絡瀕臨癱瘓。
儘管目前各行各業的去中心化應用如雨後春筍一般持續湧現，但其性能問題一直是未能突破的瓶頸，仍然存在應用場景受限、可擴展性不強等問題。當下，就連 V 神也是三句話離不開可擴展性話題。
而與之相對的中心化機構 Coinbase 交易所，雖然在 2017 年也曾受平臺擴展性瓶頸影響而導致大規模故障停機，但自此以後，儘管數字貨幣交易人羣不斷暴增、交易請求數量呈指數增長，但 Coinbase 平臺貌似並沒有再受擴展性問題的影響，持續、穩定地運行着，令人差異，他們是如何做到的？
近日，Coinbase 的大牛工程師 Luke Demi 發文總結了平臺去年故障停機的經驗與教訓，並詳細介紹了其平臺的可擴展性解決方案。
那麼，Coinbase 團隊是如何應對 2017 年突增的平臺交易量？之後又是如何逐步擴展平臺容納量、持續穩定運行呢？其擴展性解決方案在去中心化應用領域是否有借鑑意義？接下來，聽 Luke Demi 講述 Coinbase 平臺背後的故事！
2017 年，加密貨幣市場經歷了井噴式增長，整個加密貨幣生態系統的總市值從 200 億美元躍升至 6000 億美元。
在此期間，在中心化交易所 Coinbase 平臺之上，幾乎所有技術組件都經歷了殘酷的實戰考驗。
實踐證明，在保障平臺的安全性之外，其可靠性和可擴展性也是不容忽視的。
在 2018 年的 MongoDB 社區大會中，包括 Luke Demi 在內的 Coinbase 工程師都談到了 2017 年的經驗和教訓，以及此後如何增加平臺擴展性的解決方案。
2017 年的經驗教訓
2016 年，也就是加密貨幣市場井噴的前一年，Coinbase 平臺的交易量基本恆定。
在 2017 年首次爆發之前，Coinbase 團隊就用表示四到五倍平臺每日最大交易量的紅線來標示出預計的平臺交易量，即每分鐘大約 100000 個後端 API 請求。
2016 年以太幣價格飆升之前平臺每分鐘後端 API 請求的數量
然而，在 2017 年 5 月和 6 月，隨着以太幣價格的飆升，平臺的交易量也隨之猛漲並超越了紅線。
在此期間，平臺的交易量持續超越了事先預定的紅線，導致 Coinbase 平臺出現了一段時間的故障停機。
在 2017 年的交易量開始井噴的早期，每分鐘平臺後端 API 請求的數量
爲了快速解決 Coinbase 平臺的可擴展性問題，工程師團隊先從平臺環境中常規的、容易實現的技術點進行了改進。
團隊對平臺進行垂直擴展，爲改進其性能及優化檢索過程升級數據庫版本，此外，還將熱點數據庫集羣拆分爲單獨數據庫集羣等。
經過以上方法改進，Coinbase 平臺壓力暫時得以緩解，但隨着時間流逝，交易量總在持續攀升，平臺斷斷續續出現了很多次故障。
每次故障停機的模式都是相同的：主監控平臺會顯示 100 倍的延遲峯值，Ruby 和 MongoDB 延遲時間各是 50 倍。
作爲 Coinbase 的主要數據存儲區，MongoDB 在數據流量大的時候會出現高延遲，而 Ruby 延遲時間並沒有增加。
在早期的監控系統中，這就是「幽靈」現的方式
Coinbase 已有的監控工具無法爲當時遇到的一些關鍵問題提供明確的答案，我們把這個現象稱爲「幽靈」。
比如，這些查詢操作來自哪裏？ 這些操作是怎麼回事？ 爲什麼 Ruby 時間顯示出相關的峯值？ 問題可能源於應用程序方面嗎？簡而言之，團隊現有的監控服務並沒有完全利用 Coinbase 平臺環境中的可用信息。
因此，需要一個框架來回答這些問題並可視化 Coinbase 環境組件之間的關係。
團隊通過修改 MongoDB 的數據庫驅動程序來進一步改進數據庫的查詢操作。
修改後的數據庫驅動程序會記錄超過特定響應時間閾值的所有查詢操作，以及請求 / 響應大小、響應時間、源代碼和查詢類型等重要信息。
所有慢速 MongoDB 查詢操作中記錄的重要信息
這些改進提供的詳細數據使團隊能夠快速找到一些故障停機期間的異常特徵，甚至在非故障停機期間也可以。
第一個主要異常是查找設備操作的響應信息數據量過大。
當用戶登錄網站購買加密貨幣或查看相關信息時，大量的查詢會導致過重的網絡負載。
造成響應信息數據量過大的原因是當時用戶和設備之間爲多對多關係。
例如，一些用戶可能擁有多個設備，而某些設備可能由多名用戶共用。 糟糕的設備指紋（用於標定設備）識別算法將大量用戶置於同一設備中，從而導致單個設備擁有大量_user_id 對象。
爲了解決這個問題，Coinbase 團隊將這種多對多關係重構爲簡單的一對多關係，其中每個設備只映射到一個用戶。
這個改進爲 Coinbase 平臺帶來了 2017 年最大的一次性能提升。
這一發現說明了良好監控平臺的作用。
在精心改進我們的數據庫查詢操作之前，這幾乎是不可能實現的調試問題，有了新工具，現在結果顯而易見。
另一個問題是某些數據庫集羣的巨大讀取流量。
添加一個查詢緩存層，用於在 Memcached （一個高性能的分佈式內存對象緩存系統，用於動態 Web 應用以減輕數據庫負載）中緩存查詢結果。
在查詢數據庫之前，特定高讀取流量的數據庫集羣對任何單個文檔的查詢操作都會先在查詢緩存層中進行，對數據庫的任何寫入操作也會同時更新緩存。
這樣就能夠同時在多個數據庫集羣中推出此更新。 查詢緩存是在 ORM （Object Relational Mapping，對象關係映射）和驅動程序級別編寫的，這使我們可以同時更新多個有問題的數據庫集羣。
事實證明，去年 5 月和 6 月經歷的交易量井噴與去年 12 月和今年 1 月經歷的交易量井噴根本不是一個數量級的。
藉助這些修復和其他方法，Coinbase 平臺就能夠承受更大的交易量激增。
2017 年上半年的交易量井噴（紅圈處）較後期而言不足爲奇
爲未來做準備
今天，Coinbase 團隊正積極努力爲下一次加密貨幣市場的井噴做準備。
雖然在井噴期間做這些改進工作很容易，即使未來將處於交易量非常低的週期，但仍然需要找到一種方法來改善系統在未來的表現。
比較有效的方案就是通過模擬幾倍於過去經歷的交易量峯值來測試平臺環境，來發現下一個問題點可能來自哪裏。
解決方案就是執行交易流量的捕獲和回放，明確地說就是在數據庫上按需生成人爲的「加密狂熱（crypto mania）」。
這種方案比生成合成流量的方案更好，因爲它去除了合成腳本需要保持最新的要求。每次運行套件時，都要確保查詢操作根據捕獲的數據準確映射到應用程序生成的流量類型。
爲此，我們創建了一個名爲「Capture」的工具，其內部封裝了現有工具「mongoreplay」。
在環境中選擇一個特定數據庫集羣后，Capture 會同時啓動數據庫集羣快照並開始捕獲定向到該數據庫集羣的應用程序服務器上的原始流量。然後，它會在一段時間後將這些捕獲的加密信息保存到 S3 回放。
當準備好執行回放時，另一個基於「mongoreplay」名爲「Cannon」的工具將根據之前的數據庫集羣快照將記錄的流量回放到新啓動的數據庫集羣上。
在這個過程中，面臨的挑戰就是如何同時橫跨多個應用程序服務器來捕獲單個數據庫集羣的所有 MongoDB 流量。
解決方法就是，Cannon 工具通過從每次捕獲中打開一個 10MB 的緩衝區來同時進行合併和過濾捕獲。
最終得到一個合併的捕獲文件，然後 Cannon 工具可以將其定向到一個新啓用的 MongoDB 數據庫集羣中。
Cannon 工具允許精確選擇回放捕獲信息的速度，從而模擬數千倍於平臺一天可能遇到的交易數據量的負載。
雖然纔剛剛開始使用 Capture 和 Cannon 工具，但在 MongoDB 數據庫集羣上執行這類的負載測試時，我們取得了一些新發現。
這個發現來自於 Cannon 工具的調試功能。Cannon 工具能夠檢查特定的捕獲文件並查看其中的前 100 條消息。 經過檢查，確實發現了一些有趣的事：
有沒有注意到 ping 命令（ping 命令用於檢查網絡是否連通，可以幫助分析和判定網絡故障。）與 find 命令（查找）混合在一起？
事實證明，數據庫 MongoDB 的 Ruby 語言驅動程序未完全遵循 MongoDB 驅動程序的設計規範，並且在每次查詢數據庫時通過執行 ping 命令以檢查複製集狀態。
雖然這種行爲不太可能導致 Coinbase 平臺故障停機，但幾乎可以肯定，這是造成我們在監控中觀察到的「幽靈」行爲的原因。
在團隊協作完成這次挑戰後，我們爲 Coinbase 目前的可靠性狀態感到自豪。
2017 年的事件再次證明，給客戶提供訪問和查看資金的可靠服務對於實現 Coinbase 成爲值得信賴的購買、銷售和管理加密貨幣平臺的目標至關重要。
雖然安全性始終是我們的首要任務，但我們也樂於將確保我們平臺可靠性、可擴展性當作 Coinbase 的主要任務！
目前，我們已經組建了三個獨立的專注維護平臺高性能和可擴展性團隊，爲未來加密貨幣熱情的暴漲做好準備。
鏈聞 ChainNews：提供每日不可或缺的區塊鏈新聞。
原文作者：Luke Demi Coinbase 工程師
文章來源：區塊鏈大本營微信號
中文編譯：kou、Guoxi
版權聲明：文章爲作者獨立觀點，不代表 鏈聞 ChainNews 立場。
繁體中文
简体中文
English
日本語
Español