# 使用 AWS，Scala，Akka，Play，MongoDB 和 Elasticsearch 構建社交音樂服務 > 原文： [http://highscalability.com/blog/2014/3/11/building-a-social-music-service-using-aws-scala-akka-play-mo.html](http://highscalability.com/blog/2014/3/11/building-a-social-music-service-using-aws-scala-akka-play-mo.html)  *這是[前 Roem Hermon](https://twitter.com/margolis20) ， [serendip.me](http://serendip.me) 的首席架構師 [Rotem Hermon](https://twitter.com/margolis20) 的來賓轉貼，涉及在進行啟動音樂服務后的體系結構和擴展注意事項 。* [serendip.me](http://serendip.me) 是一項社交音樂服務，可以幫助人們發現朋友分享的美妙音樂，還可以將他們介紹給他們的“音樂靈魂伴侶”，即他們社交圈之外的人，他們在音樂方面有著相似的品味。 Serendip 在 AWS 上運行，并基于以下堆棧構建： [scala](http://www.scala-lang.org/) （和某些 Java）， [akka](http://akka.io/) （用于處理并發性），[播放框架](http://www.playframework.com/)（用于 Web 和 API 前端）， [MongoDB](http://www.mongodb.org/) 和 [Elasticsearch](http://elasticsearch.org/) 。 ### 選擇堆棧 建立 serendip 的挑戰之一是從第一天起就需要處理大量數據，因為 serendip 的主要特征是它收集**并從公共音樂服務在 Twitter** 上共享的每一首音樂。 因此，當我們討論選擇要使用的語言和技術的問題時，一個重要的考慮因素就是擴展能力。 JVM 似乎是我們系統經過驗證的性能和工具的正確基礎。 它也是許多開源系統（例如 Elasticsearch）的選擇語言，這使**使用其本機客戶端**-很大的優勢。 當我們研究 JVM 生態系統時，scala 脫穎而出，成為一種有趣的語言選擇，它允許現代方法編寫代碼，同時保持與 Java 的完全互操作性。 支持 scala 的另一個論點是 **akka actor 框架，它似乎非常適合流處理基礎結構**（確實如此！）。 Play 網絡框架才剛剛開始被采用，并且看起來很有希望。 早在 2011 年初我們剛開始時，這些仍然是最前沿的技術。 因此，我們當然非常高興，到 2011 年底，scala 和 akka 合并成為 [Typesafe](http://typesafe.com/) ，隨后不久 Play 就加入了。 **選擇 MongoDB 是因為它結合了開發人員的友好性，易用性**，功能集和可能的可伸縮性（使用自動分片）。 我們很快了解到，要使用和查詢數據的方式將需要在 MongoDB 上創建很多大索引，這將使我們很快遇到性能和內存問題。 因此，我們一直主要將 MongoDB 用作鍵值文檔存儲，還依賴于其原子增量來獲取需要計數器的多個功能。 通過這種使用，MongoDB 變得非常可靠。 它也很容易操作，但是主要是因為我們設法*避免使用分片*并使用單個副本集（MongoDB 的分片架構非常復雜）。 為了查詢我們的數據，我們需要一個具有完整搜索功能的系統。 在可能的開源搜索解決方案中， **Elasticsearch 成為最具擴展性和面向云的系統**。 它的動態索引架構以及它提供的許多搜索和構面功能使我們可以在其之上構建許多功能，從而使其成為我們體系結構的核心組成部分。 我們選擇**自己管理 MongoDB 和 Elasticsearch** ，并且出于兩個主要原因，不使用托管解決方案。 首先，我們希望完全控制兩個系統。 我們不想依靠其他因素進行軟件升級/降級。 其次，我們處理的數據量意味著托管解決方案比直接在 EC2 上直接管理它要昂貴。 ### 一些數字 Serendip 的“泵”（處理 Twitter 公眾流和 Facebook 用戶供稿的部分）**每天大約消化 5,000,000 個項目**。 這些項目通過一系列“過濾器”傳遞，這些過濾器檢測并解析受支持服務（YouTube，Soundcloud，Bandcamp 等）的音樂鏈接，并在它們之上添加元數據。 泵和過濾器作為 akka actor 運行，并且整個過程由單個 **m1.large EC2 實例**管理。 如果需要，可以通過使用 akka 的遠程角色將系統分發到處理器集群來輕松擴展。 在這些項目中，我們每天大約可獲得 850,000 個有效項目（即真正包含相關音樂鏈接的項目）。 這些項目在 Elasticsearch 中（以及在 MongoDB 中用于備份和保持計數器）都已建立索引。 由于每個有效項都意味著更新多個對象，因此在 Elasticsearch 中我們獲得的**索引速率為?40 / sec** 。 我們**在 Elasticsearch 中保留項目（推文和帖子）的每月索引**。 每個月度索引包含**?2500 萬個項目，并具有 3 個碎片**。 群集以 **4 個節點運行，每個節點在 m2.2xlarge 實例**上。 此設置有足夠的內存來運行我們需要的數據搜索。 我們的 MongoDB 集群處理更多數據類型，計數器和統計信息更新時，每秒**為 100 個寫入/秒，每秒 300 次為**讀取。 副本集具有在 **m2.2xlarge 實例上運行的主節點，在 m1.xlarge 實例**上運行的輔助節點。 ### 建立一個提要 當我們開始設計 Serendip 的主要音樂供稿的體系結構時，我們知道我們希望供稿是動態的并對用戶的動作和輸入做出反應。 如果用戶給某首歌“加油”或“播放”特定藝術家，我們希望該動作立即反映在提要中。 如果用戶“不喜歡”藝術家，則我們不應再次播放該音樂。 我們還希望提要是來自多個來源的音樂的組合，例如朋友共享的音樂，喜愛的藝術家的音樂以及具有相同音樂品味的“建議”用戶共享的音樂。 這些要求意味著采用“ [扇出即寫](http://www.quora.com/What-is-the-best-storage-solution-for-building-a-news-feed-MongoDB-or-MySQL)”的方法來創建提要是不可行的。 我們需要一個選項，以使用與用戶有關的所有信號實時構建提要。 Elasticsearch 提供的功能集使我們能夠構建這種實時提要生成。 提要算法包含幾種“策略”，用于選擇要在每次提要中以不同比率動態組合的項目。 每種策略都可以考慮到最新的用戶操作和信號。 將策略的組合轉換為對實時數據的幾次搜索，這些搜索由 Elasticsearch 不斷索引。 由于數據是基于時間的，并且索引是每月創建的，因此**我們始終只需要查詢完整數據**的一小部分。 幸運的是，Elasticsearch 可以很好地處理這些搜索。 它還提供了擴展此體系結構的已知途徑-**寫入可以通過增加分片**的數量進行縮放。 可以通過添加更多副本和物理節點來擴展搜索范圍。 查找“音樂靈魂伴侶”（通過音樂品味匹配用戶）的過程很好地利用了 Elasticsearch 的**構面（聚合）功能。 作為持續的社交流處理的一部分，該系統通過計算遇到的社交網絡用戶的頂級共享藝術家（使用對共享音樂的多面搜索）來準備數據。** 當偶然的用戶發出信號（通過播放音樂或與提要互動）時，它可以觸發對該用戶的音樂靈魂伴侶的重新計算。 該算法會根據喜歡的藝術家列表（不斷更新）找到最匹配的其他用戶，并權衡受歡迎程度，分享數量等其他參數。然后應用另一組算法來過濾垃圾郵件發送者（是的， 是音樂垃圾郵件發送者……）和離群值。 我們發現，此過程可為我們提供足夠好的結果，同時又使我們免于需要其他可以運行更復雜的群集或推薦算法的系統。 ### 監控和部署 Serendip 正在使用 [ServerDensity](http://www.serverdensity.com/) 進行監視和警報。 這是一款易于使用的托管解決方案，具有不錯的功能集和合理的啟動價格。 ServerDensity 本機提供服務器和 MongoDB 監視。 我們還大量使用了向其中報告自定義指標的功能，以報告內部系統統計信息。 內部統計信息收集機制為系統中發生的每個操作收集事件，并將其保存在 MongoDB 收集中。 定時作業每分鐘一次從 MongoDB 中讀取這些統計信息，并將其報告給 ServerDensity。 這使我們可以使用 ServerDensity 監視和警告 Elasticsearch 以及我們的運營數據。 使用 Amazon Elastic Beanstalk 完成服務器和部署的管理。 Elastic Beanstalk 是 AWS 的受限 PaaS 解決方案。 它非常容易上手，盡管它并不是真正功能齊全的 PaaS，但其基本功能足以滿足大多數常見用例的需要。 它提供了簡單的自動縮放配置，還可以通過 EC2 進行完全訪問。 使用駐留在 EC2 上的 [Jenkins](http://jenkins-ci.org/) 實例完成應用程序的構建。 Play Web 應用程序打包為 WAR。 [構建后腳本](https://github.com/rore/beanstalk-upload)將 WAR 作為新的應用程序版本推送到 Elastic Beanstalk。 新版本不會自動部署到服務器，而是手動完成的。 通常將其首先部署到登臺環境中進行測試，然后將其批準部署到生產環境中。 ### 外賣 總結一下，這是從構建 serendip 中學到的一些重要經驗教訓，而不是通過任何特殊命令得出的。 1. **知道如何縮放**。 您可能不需要從第一天開始進行擴展，但是您需要知道系統的每個部分如何擴展以及擴展到什么程度。 如果擴展需要時間，請提前給自己足夠的時間。 2. **準備峰**。 特別是在初創企業的生命中，如果您始終以接近最高的容量運行，那么一個救生員或 reddit 帖子就會使您的系統癱瘓。 保持足夠的余量，以便您可以處理突然的負載或準備好快速擴展。 3. **選擇一種不會阻礙您的語言**。 確保要使用的技術使用您的語言的本地客戶端，或者至少具有主動維護的客戶端。 不要卡在等待庫更新。 4. **相信炒作**。 您需要一種將隨您的產品一起增長并且不會過早死亡的技術。 一個充滿活力，活躍的社區以及對該技術的一些質疑可以很好地表明其生存。 5. **不要相信炒作**。 查找有關您正在評估的技術的簡報。 他們可以教您有關它的弱點。 但也不要太當真，當事情無法按預期進行時，人們往往會情緒激動。 6. **玩得開心**。 選擇一種使您興奮的技術。 一個讓您認為“哦，太酷了，我該怎么辦”。 畢竟，這也是我們的目標。