# MixRadio 體系結構-兼顧各種服務 > 原文： [http://highscalability.com/blog/2014/8/25/mixradio-architecture-playing-with-an-eclectic-mix-of-servic.html](http://highscalability.com/blog/2014/8/25/mixradio-architecture-playing-with-an-eclectic-mix-of-servic.html)  *這是 [MixRadio](https://twitter.com/sr_gb) 的首席架構師 Steve Robbins 的來賓[重新發布](http://dev.mixrad.io/blog/2014/08/22/MixRadio-Architecture-Overview/)。* At MixRadio, we offer a free music streaming service that learns from listening habits to deliver people a personalised radio station, at the single touch of a button. MixRadio marries simplicity with an incredible level of personalization, for a mobile-first approach that will help everybody, not just the avid music fan, enjoy and discover new music. It's as easy as turning on the radio, but you're in control - just one touch of Play Me provides people with their own personal radio station.The service also offers hundreds of hand-crafted expert and celebrity mixes categorised by genre and mood for each region. You can also create your own artist mix and mixes can be saved for offline listening during times without signal such as underground travel, as well as reducing data use and costs.Our apps are currently available on Windows Phone, Windows 8, Nokia Asha phones and the web. We’ve spent years evolving a back-end that we’re incredibly proud of, despite being British! Here's an overview of our back-end architecture. # 架構概述 我們有機會在 2009 年重新設計后端。今天，我們的后端核心是 RESTful 服務的集合，其模式稱為['微服務'](http://martinfowler.com/articles/microservices.html)。 這些服務的大小，功能，開發語言和數據存儲各不相同，但都具有共同的屬性，例如公開定義良好的 RESTful API，可獨立擴展的功能（包括監視功能），我們將在下面介紹更多功能。 圍繞這些核心服務，我們有兩個類似的代理服務，它們是通過配置驅動的，以公開用于不同目的的 RESTful 資源的子集。 “內部工具 API”代理內部 API 的工具，以涵蓋客戶服務，內容管理，發布組合，監控和許多其他情況。 在公開場合，我們通過“外部 API 身份驗證層”服務公開了針對客戶端應用和第三方開發人員的 RESTful API。 此服務還具有執行適當的權限和授權方案的工作，例如 [OAuth2](http://en.wikipedia.org/wiki/OAuth) 。 對于最終用戶，我們的 API 服務的應用范圍非常廣泛。 我們提供 [HTML5 網站](http://www.mixrad.io/)，適用于所有不同類型諾基亞手機的設備應用程序，Windows 8 應用程序，并且我們還向第三方開發人員提供了相同 API 的子集。 我不會在本文中詳細介紹我們的應用架構，因為我們團隊的內森（Nathan）先前曾寫過[。](http://dev.mixrad.io/blog/2014/02/24/Bringing-MixRadio-to-the-new-Nokia-X-family/) 下圖概述了系統的主要領域，其中駐留了五十多個微服務：  # 使用的技術 我們采取務實的方法，即針對開源技術使用正確的工具來完成這項工作。 目前，我們正在積極使用： ## 語言能力 * [Clojure](http://clojure.org/) 用于我們的微服務。 * C＃用于我們的設備應用程序和媒體交付服務。 * HTML5 / CSS / JavaScript 用于我們的網絡體驗。 ## 存儲 * [MySQL](http://www.mysql.com/) * [Solr](http://lucene.apache.org/solr/) * [MongoDB](http://www.mongodb.org/) * [Redis](http://redis.io/) * [Elasticsearch](http://www.elasticsearch.org/) * [ZooKeeper](http://zookeeper.apache.org/) * [SQLServer](http://www.microsoft.com/sqlserver) ## 基礎設施 * [適用于 Linux 微服務的 AWS](https://aws.amazon.com/) 。 * [Azure](http://azure.microsoft.com/) 用于 Windows 和媒體存儲上運行的媒體服務。 * [GitHub Enterprise](https://enterprise.github.com/) 用于源代碼控制。 * [Packer](http://www.packer.io/) 用于創建機器映像。 * [人偶](http://puppetlabs.com/)，用于調配和檢查機器映像。 ## 監控方式 * [Nagios](http://www.nagios.org/) * [石墨](http://graphite.wikidot.com/) * [Tasseo](https://github.com/obfuscurity/tasseo) * [塞倫](https://github.com/scobal/seyren) * [篝火](https://campfirenow.com/) * [PagerDuty](http://www.pagerduty.com/) * [主題演講](http://www.keynote.com/) * [Logstash](http://logstash.net/) * [Kibana](http://www.elasticsearch.org/overview/kibana/) # 建筑原理 為了使 API 與五十多種微服務保持一致，我們制定了有關 URI 結構，分頁，排序，大小寫，處理語言代碼等方面的標準； 但是在開放的文化中，我們通常使用原則而不是硬性規則來獲得一致性。 我們的服務應： * 松散耦合，無狀態，并通過 HTTP 提供 JSON 的 RESTful 接口。 * 單獨部署并擁有自己的數據，即其他服務通過 API（而不是數據庫連接）訪問數據。 這允許單獨的規模以及持久性技術和數據結構的更改。 * 當我們為每個服務使用一個機器實例時，它既不會太大以致于變得笨拙，又不會太小而使其浪費計算資源。 * 實施用于檢查的 Healthcheck API，并負責確定健康狀況。 * 永遠不要破壞他們的消費者。 我們很早就同意一個標準，在資源路徑中有一個版本號（例如`/1.x/products/12345/`），這樣如果需要進行重大更改，則可以并行部署新版本并被上游消費者采用 。 即使我們仍然保留此功能，多年來也不需要使用它。 除了這些內部原則外，對于面向公眾的 API，我們還添加了以下內容： * API 已針對移動設備進行了優化：我們使用 JSON，因為與低功耗設備上的 XML 相比，它解析所需的內存要少于 XML，并盡可能使用 GZIP 編碼響應，最重要的是-如果不需要數據，則不會返回。 最后一點是與 API 一致性的良好平衡。 * 盡可能使用緩存； API 返回適當的緩存頭，以便將內容緩存在最終用戶設備和瀏覽器以及[內容分發網絡（CDN）](http://en.wikipedia.org/wiki/Content_delivery_network)上，從而首先使內容更接近我們的消費者。 * 云中會保留盡可能多的邏輯和數據真實性，以減少應用程序中邏輯的重復并提供一致的體驗。 * 相同的 API 用于所有客戶端-網絡，移動，桌面和第三方子集。 但是，為了針對不同的屏幕尺寸和要求進行優化，我們使用了一些技巧。 一個明顯的例子是“ itemsperpage” querystring 參數，用于調整返回的內容數量。 另一個適用于 RESTful API 設計，其中資源返回隔離的內容。 我們經常將內容分組為所謂的“視圖”，以減少所需的請求數量。 使用視圖 API 的一個示例是我們應用程序中的藝術家詳細信息頁面，該頁面包含來自許多資源的數據-藝術家傳記，圖像，推文，演出，并混合了其中的專輯，熱門專輯，熱門歌曲和類似歌手。 通過將其組合成一個“視圖”，應用程序可以一擊即獲得約 5KB 的數據。 # 快速微服務 在過去的幾年中，我們已經在 [Clojure](http://clojure.org/) 而非 Java 中構建了微服務。 Clojure 是一種動態語言，仍然可以在 Java 虛擬機（JVM）上運行，并且還允許訪問 Java 框架。 我們的后端團隊出于開發速度和運行時的速度選擇使用 Clojure。 Clojure 比 Java 簡明得多-例如，這是我們在 Clojure 中重新開發的 Java 服務之一，其代碼行數從 44,000 行增加到 4,000 行（包括所有配置，測試和其他工件）。 我們使用 [Leiningen](http://leiningen.org/) 來加快開發速度-Leiningen 提供的一個方面是自定義項目模板，我們有一個名為`cljskel`的模板為我們創建框架服務。 我們打算在以后的帖子中再次使用該模板，但是為了說明使用，我們能夠運行以下命令，并具有帶有監控 API 的功能性 RESTful 服務： ``` lein new cljskel <project name> ``` 如果您對我們如何進入 Clojure 感興趣，您可能想觀看我們兩位工程師去年在倫敦所做的演講。 # 數據 我們處理的兩個最大數據源是我們擁有的 32+百萬首曲目的內容元數據（以及相關的藝術家，專輯，混音等）以及來自我們的應用程序的分析數據，例如播放事件，大拇指向上/向下 和導航事件。 Catalog 服務（請參見下圖）為我們的消費者體驗提供內容元數據和搜索功能。 “主目錄”服務存儲來自各種來源的原始數據，例如記錄標簽，我們的內部內容團隊和互聯網資源（例如 Wikipedia）。 配置驅動的數據模型指定了如何合并來源（例如，優先考慮從我們的內容團隊得到更正的某些字段，而不是其他來源），哪些字段可搜索以及哪些字段返回給調用者。 我們可以返回不同的字段來滿足不同的用例。 例如，我們不需要搜索結果中的專輯曲目列表，但在顯示專輯詳細信息時確實需要它們。 主目錄服務不會直接為用戶流量提供服務，而是“搜索和查詢” API 是其余后端的接口。 搜索和查詢服務基于 [Apache Solr](http://lucene.apache.org/solr/) 構建，“索引后臺程序”服務對主目錄進行爬網以獲取發布到 Solr 搜索索引的更新。 [](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/catalogue.png) 收集分析和使用數據對于驅動個性化體驗，進行 A / B 測試，CRM，計算業務指標和合同報告至關重要。 隨著數據全天不斷地從各種應用程序進入后端，許多服務需要同時訪問同一數據。 一個例子是用戶在曲目上按下了“ thumbs down”按鈕，這對于當前播放曲目的混合很重要*和*到用戶的整體口味，重復的拇指 下降表示不喜歡藝術家。 為了能夠處理我們期望的數據量，去年初我們決定需要一個發布-訂閱模型，該模型將： * 高可用性，無單點故障。 * 通過解耦和暫停傳入消息的能力為整個系統提供可伸縮性。 * 與消息格式無關。 * 寫延遲低（即“即發即棄”的語義）。 * 為訂戶提供快速吞吐量。 * 提供簡單的發布和訂閱 API。 * 支持多個用戶使用相同的數據，每個用戶可能具有不同的體系結構，并以不同的速度和時間表運行。 例子是實時處理與批處理聚合或歸檔。 我們從 LinkedIn 選擇了 [Apache Kafka](http://kafka.apache.org/documentation.html#introduction) ，因為它非常適合我們的需求。 特別是它是一個持久的消息傳遞系統，旨在支持許多具有自己狀態（例如讀取數據的位置）的消費者，而不是假設訂戶永久存在并以相同速率消費數據。 # 監控方式 我們針對關鍵用例的<延遲時間為 0.8 秒，在為期 90 天的滾動期內達到 99.99％的可用性-相當于每月停機 4.3 分鐘。 因此，當出現問題時，我們如何知道何時出現問題并迅速做出反應？ 我們具有多層監視功能，可以提醒開發人員和操作工程師。 在最低級別上，我們使用 [Nagios](http://www.nagios.org/) 檢查虛擬機的基本運行狀況，并使用 [PagerDuty](http://www.pagerduty.com/) 來提醒運維工程師。 我們利用每個微服務實現的運行狀況檢查 API，讓 AWS 負載均衡器確定盒子是否需要回收（您可以在此[上一篇文章](http://dev.mixrad.io/blog/2014/05/16/How-we-use-cluppet/)中閱讀有關如何配置 AWS 負載均衡器的更多信息）。 [石墨](http://graphite.wikidot.com/)用于收集操作系統級別的指標，例如 CPU 使用率，磁盤空間等。但是，每個微服務也記錄自定義指標，這對所涉及的工程師很有幫助。 我們收集的服務指標從低級項目（例如 HTTP 500 錯誤計數）到高級抽象（激活的訂閱數），不計其數。 這是一個石墨儀表板示例： [ ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-graphite.png) 我們在 Graphite 頂部使用 [Tasseo](https://github.com/obfuscurity/tasseo) 提供漂亮的儀表板數據摘要視圖，并使用 [Seyren](https://github.com/scobal/seyren) 根據閾值變化發出警報。 Seyren 由我們的一些工程師創立，并在一篇有關 [2012 年奧巴馬連任競選](http://arstechnica.com/information-technology/2012/11/how-team-obamas-tech-efficiency-left-romney-it-in-dust/)中使用的技術的文章中得到提及。 [ ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-seyren.png) 在最高級別上，我們使用[主題演講](http://www.keynote.com/)來監控全球的用例和響應時間： [ ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-keynote.png) 最后，對于詳細的診斷，我們避免了必須通過日志傳送連接到特定服務器。 我們使用 [Logstash](http://logstash.net/) 將系統，請求，錯誤和特定于應用程序的日志收集到中央位置，并與自定義儀表板一起使用 [Kibana](http://www.elasticsearch.org/overview/kibana/) 來跟蹤特定的錯誤或查看趨勢。 該示例是幾年前我們試圖減少應用程序錯誤噪聲時的自定義儀表板： [ ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-errors.png) # 持續交付 連續交付是一種通過自動化部署和測試以可重復的方式快速發布軟件的實踐。 從大爆炸發布開始，我們花費了數年的時間來改進我們的流程； 遷移到部署管道，然后使用 AWS 中的 Netflix“紅/黑”樣式模型遷移到今天的狀態。 我們工程團隊的 Joe 在 6 月的[倫敦持續交付聚會](http://vimeo.com/100788786)上談到了這一點。 通過查看過去五年中完成的部署次數，可以了解我們的進展情況：  ## 相關文章 * [MixRadio 歷史記錄](http://dev.mixrad.io/blog/2014/08/05/MixRadio-History/)