摘要：基于業務需求，MixRadio以謹慎的態度選擇適合的技術。然而架構衍變至今，其中已包含大量的新型技術，比如MongoDB、Redis等。同時簡單、高效，他們不僅從Java過渡到了Clojure，還是AWS的重度使用者。
【編者按】在“的推特論戰：Microservices vs. Monolithic”一文中，我們曾分享過Netflix、ThougtWorks及Etsy工程師在Microservices上的辯論。在看完整個辯論過程后，或許會有一大部分人認同面向服務這個架構體系。然而事實上，Microservices的執行卻并不簡單。那么究如何才能打造一個高效的面向服務架構？這里我們不妨看向MixRadio首席架構師Steve Robbins的分享。
以下為譯文
MixRadio提供了一個免費的音樂流服務，通過學習用戶的收聽習慣以交付一個定制化的電臺，而用戶需要做的只是去點擊一些簡單的按鈕。通過極其簡易的交互，MixRadio通過“移動優先”的方式提供了一個難以置信的定制化等級。它適用于任何人去發現新的音樂，不只是狂熱的音樂發燒友。使用MixRadio就像打開一臺收音機，但一切都在你的掌握之中——輕點Play Me，你的私人廣播電臺隨之開啟。基于地域流派和風格，MixRadio包括了數以百計的手工歌單、創建歌單功能，當然不能缺少保存喜愛的歌單并離線播放，這樣即使沒有互聯網，美妙的音樂仍然可以繼續。
當下服務已經在Windows Phone、Windows 8、Nokia Asha以及Web上可用，而支撐這些應用的后端系統則經過了數年的打磨，下面我們一起看看系統的架構概括。
架構綜述
在2009年，我們如愿獲得了重構后端系統的機會。而衍變到現在，后端系統已經由一系列RESTful服務組成，也就是大家經常說的“Microservices”。這些系統的功能、大小、開發語言、數據存儲都各不相同，然而有一些共性是必不可少的，比如一些良好定義的RESTful API、獨立擴展、監視能力。圍繞這些核心服務，系統還擁有兩個相似的代理服務，通過配置以提供RESTful資源的子集，它們被用于不同功能。“Internal Tooling API”代理服務器擁有內部API以提供客戶服務、內容管理、歌單發布、監視以及其他場景使用的工具，客戶端應用及第三方開發者使用的 RESTful API通過“External API auth layer”開放，這個服務同樣負責執行適當的許可權限以及授權方案，比如OAuth2。
對于終端用戶，通過API服務的應用程序范圍非常廣。我們提供了獨立的HTML5網站、以及適用于Nokia電話和搭載Windows 8系統的設備應用，同時我們還開放部分相同的API給第三方開發者。下面我們不會公布過多的系統架構細節，如果想有更多詳細了解可以查看我同事Nathan之前發布的文章。我們將對系統主要部分進行高度綜述，下圖顯示了系統中由50多個Microservices構成的組件：
使用的技術
基于開源，我們務實地選擇合適的工具以完成任務，下面一起看系統中重度使用的技術堆棧：
語言
Microservices使用Clojure開發
設備應用和Media Delivery服務使用C#開發
Web端則使用了HTML5、CSS和JavaScript
存儲
MySQL
Solr
MongoDB
Redis
Elasticsearch
ZooKeeper
SQLServer
基礎設施
Linux Microservices使用了AWS
媒體存儲和運行在Windows上的媒體服務使用Azure
GitHub Enterprise用于源碼控制
Packer用于建立機器鏡像
Puppet用于服務開通和主機鏡像檢查
監視
Nagios
Graphite
Tasseo
Seyren
Campfire
PagerDuty
Keynote
Logstash
Kibana
架構原則
為了保持50多個Microservices API的一致性，我們在URL、結構、分頁、排序、包裝、語言代碼等處理上都制定了標準；但是在一個開放的文化下，我們通常使用原則而非硬性規定來保持一致性。我們的服務需要遵循以下的條款：
松耦合、無狀態，并且在HTTP上提供JSON RESTful接口。
獨立部署并擁有自己的數據，也就是其他服務通過API訪問數據，而不是數據庫連接。這在持久性技術及數據結構改變時，服務仍然可以獨立擴展。
不能太大，因為臃腫；不能太小，因為會浪費資源；我們為每個服務都使用了獨立的主機實例。
實現健康檢查API，用于監視和確定健康狀態。
永遠都不要破壞消費鏈。我們在早期就遵循在資源路徑中添加版本號的標準（比如/1.x/products/12345/），這樣一來，如果必須做破壞性改變，新的版本可以同時部署，并為上流消費者使用。盡管當下我們仍然保留了這個能力，但是已經數年未用。
遵循這些內部原則，對于外部公開API，我們有一些附加標準：
API遵循移動優化：我們使用JOSN，因為在低性能設備上，對比XML，它只需要耗費很少的內存去解析；只要有可能，響應回應使用 GZIP編碼，重要的是，如果不需要，就不會返回數據。后一點是對API一致性一個很好的平衡。
盡可能的使用緩存：API返回適當的緩存標頭，這樣一來，內容就可以在終端用戶設備或瀏覽器上緩存，同時，我們還使用內容分發網絡（CDN）來讓內容離消費者盡可能的近。
盡可能多的在云中托管邏輯與數據，從而大化減少應用中的邏輯副本并交付一個一致性體驗。
第三方子集、Web、移動以及桌面客戶端使用相同的API。然而，為了適應不同需求和屏幕大小，我們使用了大量的技術。舉個例子，我們經常使用“itemsperpage”查詢參數來調整返回內容數量；另一個關于RESTful API設計就是資源返回隔離的內容。內容經常被聚合到我們稱為“views”的容器中，這樣可以減少請求的數量。
使用視圖API的一個例子就是應用中藝術家詳情分頁，數據從多個源中抽取——藝術家個人簡介、圖片、推特、gigs（混合了風格、熱門歌曲、朋友聽過的歌曲、相似的藝術家）。通過將這些集合到“view”中，應用每次都可以獲得5千字節左右的數據。
讓Microservices更快
近年內，我們一直進行Microservices從Java到Clojure的重寫。Cloujure是個靜態語言，仍然運行在Java Virtual Machine（JVM）之上，允許訪問Java框架。后端團隊之所以會選擇Cloujure，大部分原因是速度——不管是開發還是運行時。Cloujure比Java來的更為簡潔，舉個例子，有一個使用Java編寫的Microservices在使用Cloujure重編寫后，代碼量從44000減少到4000行（包括所有配置、測試及組件）。我們使用Leiningen來加速開發，Leiningen提供的一個特性就是自定義項目模板來加速開發，我們擁有一個被稱為“cljskel”的模板作為所有服務的框架模板。在后續文章中我們將詳細介紹這個模板，而在使用方面，我們可以運行下面的命令，并獲得一個功能RESTful服務，它將具備監視API：
lein new cljskel <project name>
如果你感興趣我們為什么會深入Clojure，你可能會對2013年兩個工程師在London的演講感興趣。
數據
我們有兩個大的數據源，分別是3200萬+音軌的內容元數據（包括相關的藝術家、專輯、混合等）和來自應用程序的分析數據（比如回放、頂/踩以及瀏覽事件）。
Catalogue服務為消費者體驗提供了內容元數據和搜索能力，Master Catalogue則存儲來自多個數據源中的元數據，比如唱片公司、公司內部內容團隊、以及類似維基百科這樣的互聯網資源。一個配置驅動的數據模型指定如何合并資源（比如基于內容團隊在其他源中的更改對指定字段進行更新），這里的字段都可以被搜索并返回調用者。針對不同的用例，我們可以返回不同的字段。比如，有時候在搜索結果中我們并不需要一個節目列表清單，但是在顯示曲目列表詳情時我們則需要這個字段。Master Catalogue服務不會直接支撐用戶流量，取而代之，“Search and Query”API則是其余后端系統的接口。Search and Query服務基于Apache Solr建立，Index Daemon則會抓取Master Catalogue用以修改并推送給Solr搜索索引。
在定制化體驗、進行A/B測試、CRM、計算業務指標過程中，收集常用和分析數據至關重要。隨著連續不斷的數據從各種應用中傳到后端，許多服務都需要對相同的數據同時訪問。舉個例子，當某個用戶踩某首歌曲時，這對當下播放的曲目列表有著重要的意義，有助于對一個用戶品位的把握，再三的重復踩這個動作意味著這個藝術家可能并不為用戶喜歡。為了能處理預期的數據，我們確定了預期中訂閱/發布系統所具備的特性：
高可用，不能有任何單點故障
通過去耦為整個系統提供高擴展性，并且具備暫停攝入消息的能力
允許對消息格式不可知
低寫入延時
為訂閱者快速提供輸出
提供簡單的訂閱/發布API
支持同數據多訂閱，同時每個都可能有不同的架構，以不同的速度和調度處理。比如實時處理和批聚合（或者存檔）。
我們選擇了LinkedIn出品的Apache Kafka，因為它近乎完美地迎合了我們的需求。作為一個穩定的消息系統，它被設計用于支撐不同狀態（比如讀取數據的位置）的用戶，而不是所有用戶都是一塵不變的存在，并且以同樣速度消費數據。
監視
系統的目標是主要用例延時不超過0.8秒，以及在90天周期內4個9的可用性，相當于每個月停機4.3分鐘。因此當錯誤發生時，我們要快速的發現并處理問題。在這里，我們使用了多個監視層來提醒開發和運維工程師。
底層，我們使用Nagios來檢查虛擬機的健康狀況，并通過PagerDuty來提醒運維工程師。系統中，每個Microservices都會實現健康檢查API，讓AWS負載均衡器來確定某個主機是否需要被重啟（在之前的報告中，你可以了解更多關于AWS負載均衡器的配置信息）。Graphite被使用以收集操作系統級度量，比如CPU使用率、磁盤空間等。同時，每個Microservices都會根據工程師需求記錄對應度量。服務度量會在不同等級上進行，比如低等級的HTTP 500錯誤計數，以及高等級的抽象（被激活訂閱數量），我們測量一切需要的信息。下面是Graphite可視化界面的一個截圖：
在Graphite之上我們使用了Tasseo，它會提供一個更友好的數據總結視圖；同時，在閾值變化時，我們使用Seyren進行提醒。Tasseo早是由幾個工程師引進，它曾被用于2012年奧巴馬再次競選時的系統。
在高等級中，我們通過Keynote測量用例和全世界范圍內的響應時間：
終，為了做更詳細的監測，我們避免必須通過日志傳輸來連接到特定服務器的情況。通過Logstash集中收集系統、請求、錯誤和應用程序特有日志，并且使用Kibana配合定制儀表盤來追蹤特殊錯誤或者趨勢。下面這個例子是我們幾年前定制的儀表盤，目的是減少應用程序錯誤噪聲：
持續交付
持續交付是自動部署和測試的一個實踐，主要關注軟件是否可以被快速并以重復的途徑發布。多年來，我們一直致力這方面的提升，當下已經過渡到Netflix基于AWS的“red / black”模式。在今年6月份的London Continuous Delivery Meetup上，我們工程師Joe分享了這方面的內容。
你可以通過觀察我們在過去5年發布的軟件數量來查看架構提升：
原文鏈接： MixRadio Architecture - Playing With An Eclectic Mix Of Services(翻譯童陽)
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
