# 用于擴展 Turntable.fm 和 Labmeeting 的數百萬用戶的 17 種技術 > 原文： [http://highscalability.com/blog/2011/9/26/17-techniques-used-to-scale-turntablefm-and-labmeeting-to-mi.html](http://highscalability.com/blog/2011/9/26/17-techniques-used-to-scale-turntablefm-and-labmeeting-to-mi.html)  在[如何在一個月內啟動并擴展到一百萬用戶](http://www.jperla.com/blog/post/how-to-launch-in-a-month-scale-to-a-million-users)，[前技術副總裁兼 Turntable.fm 的創始團隊 Joseph Perla](http://twitter.com/jperla) 分享了他用來構建和快速擴展的技術 他的創業公司。 該帖子寫得很好，必須閱讀。 這里是要領： 1. **保持簡單。** 在制作網站或移動應用之前，請構建 API。 保持界面小巧，用途單一。 2. **正確處理。** 從一開始就內置自動化測試。 創建功能測試，模塊級別測試和完全集成測試。 對每個提交運行測試。 存在錯誤時，無需編寫新代碼。 3. **不要隱藏力量。** 使用 [Pebbles](http://www.jperla.com/blog/post/write-bug-free-javascript-with-pebbles) 編寫無錯誤的 Javascript，該庫通過在代碼中添加一些額外的 HTML 標記來編寫 0 個 javascript，從而創建復雜的 AJAX 交互。 4. **使用過程參數可提供接口的靈活性。** 通過函數而不是參數來支持復雜的場景。 例如，過濾器函數返回布爾值。 5. **留給客戶端。** 保持服務器簡單，并將盡可能多的功能移至客戶端。 6. **連續性。** 保持接口穩定。 版本從一開始就是接口。 7. **保守實現的秘密。** 保持服務實現完全獨立，以提供最大的靈活性來處理需求更改，即使這意味著性能會略有下降。 8. **再次使用一個好主意，而不是一概而論。** 復制和專用化類似代碼而不是創建一個更通用的庫是可以的。 9. **通常分別處理正常情況和最壞情況。** 代碼應該清楚地顯示特殊情況，而不是使用更通用的算法來刪除特殊情況。 10. **如果有疑問，請以固定方式拆分資源。** 服務器應為單一用途。 例如，將數據庫索引和搜索索引保留在單獨的計算機上。 然后可以獨立縮放它們，而不會彼此腳。 11. **如果可以，請使用靜態分析。** 在簽入時運行對代碼的堆棧分析工具，以查找錯誤和性能問題。 12. **從方便的表示形式動態轉換為可以快速解釋的形式。** 例如，用于 tweet 過濾的 Python 特定于域的語言易于編程，可以直接轉換為 python 字節碼。 13. **緩存可解決昂貴的計算問題。** 不言自明，，但請注意緩存失效問題。 14. **如有疑問，請使用蠻力。** 最好使用簡單的算法更快地完成功能，而不是延遲實現聰明的算法。 15. **盡可能在后臺計算。** 在 Web 服務器中做盡可能少的工作，將其排隊到后臺進程。 16. **盡可能使用批處理。** 加載單個數據項的速度很慢，請大批量加載它們。 17. **減少負載以控制需求。** 可以有限制。 選擇使您的軟件正常工作的限制，而無需經過巨大的努力或更改堆棧。 ## 相關文章 * [有關計算機系統設計的提示](http://research.microsoft.com/en-us/um/people/blampson/33-Hints/WebPage.html)，作者：Butler W. Lampson 如果說基于 JavaScript 構建一個 api，則不確定“將其交給客戶端”始終是正確的方法。 如果該產品在緊湊型市場中，您將考慮使用一個簡單的 api 來快速實施，并使用更復雜的服務器端 ＃8 是最簡單但經常被忽略的問題之一。 開發人員通常嘗試在模式中尋找任何類型的通用性，以證明將抽象功能集成到單個通用組件中是合理的。 有時這是一個好主意，但有時它只會創建難以管理的代碼，并且可能對性能產生負面影響。 做好一件事情，而不是少做一件事情。