【編者按】在“著名的推特論戰：Microservices vs. Monolithic”一文中，我們曾分享過Netflix、ThougtWorks及Etsy工程師在Microservices上的辯論。在看完整個辯論過程后，或許會有一大部分人認同面向服務這個架構體系。然而事實上，Microservices的執行卻并不簡單。那么究竟如何才能打造一個高效的面向服務架構？這里我們不妨看向MixRadio首席架構師Steve Robbins的分享。
以下為譯文
MixRadio提供了一個免費的音樂流服務，通過學習用戶的收聽習慣以交付一個定制化的電臺，而用戶需要做的只是去點擊一些簡單的按鈕。通過極其簡易的交互，MixRadio通過“移動優先”的方式提供了一個難以置信的定制化等級。它適用于任何人去發現新的音樂，不只是狂熱的音樂發燒友。使用MixRadio就像打開一臺收音機，但一切都在你的掌握之中――輕點Play Me，你的私人廣播電臺隨之開啟?；诘赜蛄髋珊惋L格，MixRadio包括了數以百計的手工歌單、創建歌單功能，當然不能缺少保存喜愛的歌單并離線播放，這樣即使沒有互聯網，美妙的音樂仍然可以繼續。
當下服務已經在Windows Phone、Windows 8、Nokia Asha以及Web上可用，而支撐這些應用的后端系統則經過了數年的打磨，下面我們一起看看系統的架構概括。
在2009年，我們如愿獲得了重構后端系統的機會。而衍變到現在，后端系統已經由一系列RESTful服務組成，也就是大家經常說的“Microservices”。這些系統的功能、大小、開發語言、數據存儲都各不相同，然而有一些共性是必不可少的，比如一些良好定義的RESTful API、獨立擴展、監視能力。圍繞這些核心服務，系統還擁有兩個相似的代理服務，通過配置以提供RESTful資源的子集，它們被用于不同功能?！癐nternal Tooling API”代理服務器擁有內部API以提供客戶服務、內容管理、歌單發布、監視以及其他場景使用的工具，客戶端應用及第三方開發者使用的 RESTful API通過“External API auth layer”開放，這個服務同樣負責執行適當的許可權限以及授權方案，比如OAuth2。
對于終端用戶，通過API服務的應用程序范圍非常廣。我們提供了獨立的HTML5網站、以及適用于Nokia電話和搭載Windows 8系統的設備應用，同時我們還開放部分相同的API給第三方開發者。下面我們不會公布過多的系統架構細節，如果想有更多詳細了解可以查看我同事Nathan之前發布的文章。我們將對系統主要部分進行高度綜述，下圖顯示了系統中由50多個Microservices構成的組件：
基于開源，我們務實地選擇合適的工具以完成任務，下面一起看系統中重度使用的技術堆棧：
為了保持50多個Microservices API的一致性，我們在URL、結構、分頁、排序、包裝、語言代碼等處理上都制定了標準；但是在一個開放的文化下，我們通常使用原則而非硬性規定來保持一致性。我們的服務需要遵循以下的條款：
遵循這些內部原則，對于外部公開API，我們有一些附加標準：
使用視圖API的一個例子就是應用中藝術家詳情分頁，數據從多個源中抽取――藝術家個人簡介、圖片、推特、gigs（混合了風格、熱門歌曲、朋友聽過的歌曲、相似的藝術家）。通過將這些集合到“view”中，應用每次都可以獲得5千字節左右的數據。
近年內，我們一直進行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、計算業務指標過程中，收集常用和分析數據至關重要。隨著連續不斷的數據從各種應用中傳到后端，許多服務都需要對相同的數據同時訪問。舉個例子，當某個用戶踩某首歌曲時，這對當下播放的曲目列表有著重要的意義，有助于對一個用戶品位的把握，再三的重復踩這個動作意味著這個藝術家可能并不為用戶喜歡。為了能處理預期的數據，我們確定了預期中訂閱/發布系統所具備的特性：
我們選擇了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 （翻譯/童陽 責編/仲浩）
程序員人生，我編程，我富裕，記住wfuyu網，php教程，php學習，php手冊，CMS模版制作
聲明：本站大部分內容是作者原創，少部分收集于互聯網供大家一起學習，原版權很多不明，如有侵權請聯系本站，謝謝！
粵ICP備14040726號-1?? 2015-2020 程序員人生 版權所有
