# 在破壞之前先檢查自己-鱷梨的建筑演進的 5 個早期階段 > 原文： [http://highscalability.com/blog/2013/4/10/check-yourself-before-you-wreck-yourself-avocados-5-early-st.html](http://highscalability.com/blog/2013/4/10/check-yourself-before-you-wreck-yourself-avocados-5-early-st.html) 在[中不要驚慌！ 這是如何快速擴展您的移動應用](http://venturebeat.com/2013/04/06/dont-panic-heres-how-to-quickly-scale-your-mobile-apps/)的方法。 [Mike Maelzer](http://www.linkedin.com/in/maelzer) 描繪了 [Avocado](https://avocado.io/) （一種用于連接情侶的移動應用程序）是如何發展的，可在幾周內處理 30 倍的流量。 如果您只是入門，那么這是一個值得學習的好例子。 我喜歡的東西：寫得很好，在一個很小的空間中包裝了很多有用的信息； 它是由故障驅動的，顯示了有目的的測試和生產經驗所驅動的增量變化的過程； 它顯示出對于重要的用戶（對于他們而言）注冊的意識； 使用副本設置進行測試，這是一個不錯的云優勢。 他們從中學到的最大的教訓是一個很好的教訓： > 最好早得多開始擴展過程。 由于時間緊迫，我們不得不做出讓步-例如放下四個媒體縮放器盒。 雖然在某些擴展問題上投入更多的硬件確實可以，但是這并不理想。 這是我對這篇文章的介紹： ## 進化一-使之工作 剛開始時，您只想完成工作，無論完成多少。 您如何確定需要解決的問題？ Avacodo 所做的是有目的地測試他們的軟件，尋找弱點，修復它們，然后進行迭代。 一個非常明智的增量過程。 您可能會想，為什么不跳到最終結果，但是那永遠不會真正解決。 敏捷/精益思維的所有觀點都有很多真理。 每個大型系統都是從較小的系統演變而來的。 * 第一個問題：您真的需要擴展嗎？ 為什么要經歷所有這些努力？ Avocado 正在促銷中，他們希望帶來更多的流量，而他們負擔不起那些潛在的新用戶帶來的不良體驗。 因此，必須應對大量的流量高峰。 * 他們從典型的擁有每種功能設置的服務器開始：1 前端服務器（存儲：API，Web 狀態，socket.io，HAProxy，隧道/ SSL 加密）； 1 個 Redis 服務器; 1 個 MySQL 服務器； 1 個批處理服務器（正在運行其他守護程序）。 * 復制測試設置用于運行常見的方案，例如帳戶創建。 * 在測試環境中使用較小的 EC2 實例可以節省資金，并且可以消除與資源相關的錯誤。 * 使用 [jmeter](http://jmeter.apache.org/) 構建的測試腳本每分鐘模擬成千上萬的用戶注冊。 * 測試旨在使用不同的場景來發現薄弱環節，例如添加第二臺服務器并使用服務器上的所有 CPU。 * 通過數千個同時注冊來提高性能： * 由于創建新的 Python 進程來發送電子郵件驗證和調整個人資料圖片的大小而導致的 CPU 高峰。 * 所有這些都發生在一個盒子上。 * 一些 MySQL 查詢需要很長時間。 * SSL 是主要的 CPU 負載 ## 進化二-測試驅動的變更 根據測試結果，他們： * 添加了一些數據庫索引以加快訪問速度。 創建表時，您是否不應該知道要添加哪些索引？ 這不是很明顯嗎？ 有時是，有時不是。 讓您的數據庫告訴您哪些緩慢的方法也適用，尤其是在游戲初期。 * 重新編寫電子郵件驗證以使用 node.js 的異步功能，而不是每次都派生一個單獨的 Python 進程。 吞吐量提高了 3 到 5 倍。 他們為什么首先使用 Python 方法？ 看來顯然是浪費。 也許他們已經有了代碼？ 也許他們知道如何用 Python 做到這一點？ 在較大的計算機上可能沒有關系。 但這是明智的漸進式變化。 采取可行的措施，并在無法解決時進行修復。 盡管他們在這里仍然有巨大的失敗漏洞。 如果進程終止，則用戶注冊狀態機將停止。 * SSL 已移至其自己的服務器。 同樣，這很明顯是一個問題，而更大的機器可能會成為一個問題，但是從一臺機器上啟動肯定更容易。 * 對于促銷，分配了四個新實例來調整圖像大小。 晉升后將其刪除。 處理預期流量高峰的好策略。 ## 進化三-生產驅動型變化 隨著我們對生產經驗的深入了解，我們可以看到問題的類型正在變為那些很難預測并且似乎只有修復的奇怪問題。 * 在促銷監視期間，警報提示響應時間較慢，因此添加了第二臺前端服務器。 因此要進行監控。 最終添加了 15 臺服務器。 * 注意到在較大的 EC2 實例上，僅使用一個 CPU，node.js 是單處理器解決方案，并且 HAProxy 每個框僅路由到一個實例。 重新啟動 HAProxy 以讀取新配置以解決此問題花費了幾秒鐘，因此他們創建了冗余 HAProxy 服務器以減少停機時間。 * ELB 用于將流量路由到兩個 HAProxy 服務器并處理 SSL，從而減少了代理箱的數量并節省了資金。 * 這導致 socket.io 出現多服務器問題，因為用戶需要與一臺服務器維護一個會話。 因此，他們參加了粘性會議，需要做一些棘手的更改。 * 有趣的發現：Websockets 不能在所有的蜂窩網絡上工作。 由于這是至關重要的移動應用程序。 另外，ELB 不支持 websocket。 因此他們使用了 XHR 輪詢。 命運的驚人轉折。 * 將 Socket.io 移動到具有 8 個 socket.io 服務器（每個 CPU 一個）的自己的盒子中，總共有 16 個 socket.io 服務器實例。 * 似乎很多套接字服務器。 為了減少數量，使用了數據庫連接池。 最初，每個 socket.io 服務器都有一個數據庫連接，該數據庫連接將工作排隊到數據庫中，從而使 socket.io 使用了 8 個 CPU 中的 60％。 每個服務器實例使用 2 至 10 個數據庫連接池將 CPU 使用率降至 3％，并顯著縮短了響應時間。 * 為什么不從一開始就使用連接池？ 這是很標準的。 他們沒有，我感到很驚訝，但是會出現各種各樣的問題，重點不是他們是哪個問題，而是您找到并解決這些問題。 ## 進化四-走向全球 * 移動對夫婦遍布世界各地，因此他們也通過在全球范圍內啟動服務器進行調整，以指導亞馬遜按時進行路由。 注意這有多瘋狂。 一次國際發行本來是一筆大買賣。 現在，這只是您要做的另一件事。 * 他們應該早些時候走向全球嗎？ 畢竟，移動性能是應用的關鍵。 但這太瘋狂了，您必須具有系統使用經驗，然后才能前往多個位置。 ## 進化五-現在使它更好地工作 * 在處理了最初的促銷任務，了解了其系統的工作原理并解決了問題之后，現在該考慮自動化和自動部署策略了。 慢慢來，這樣您就可以一次擔心一種問題。 從一開始就進行自動化將使事情變得非常復雜，因為您甚至在不知道應該如何工作的情況下嘗試進行自動化。 更好的漸進式思維。 我讀了“ CPU”，但我懷疑很多時候它應該是 CPU“線程”。 在體系結構規模上迭代的一個很好的例子，并且不會感到被堆棧的任何特定部分所束縛。