【編者按】打造一個高擴展性應(yīng)用程序并不是一件容易的事情，首先要選擇合適的技術(shù)堆棧，這些技術(shù)在具備高擴展性的同時，還需要具備良好的“活力”。不僅如此，你還需要清楚它們的擴展極限，這樣才能做出更好的應(yīng)用程序擴展策略。本次為大家分享兩篇博文，其中之一是Serendip前首席架構(gòu)師Rotem Hermon的Web應(yīng)用程序設(shè)計――架構(gòu)中囊括了云服務(wù)、NoSQL等眾多新時代元素。另一個則是10個MongoDB深入理解，出自MongoDB資深解決方案架構(gòu)師Asya Kamsky。
以下為譯文：
Serendip是個社交音樂服務(wù)，用作好友間的音樂分享。基于“人以類聚”這個原因，用戶有很大的幾率在好友那發(fā)現(xiàn)自己喜歡的音樂。Serendip基于AWS構(gòu)建，使用了的堆棧包括Scala（以及一些Java）、Akka（用以處理并發(fā)性）、Play框架（用于Web和API前端）、MongoDB以及Elasticsearch。
Serendip面臨最大的挑戰(zhàn)就是剛開始就需要處理大量數(shù)據(jù)，因為Serendip的一大特性就是從Twitter或者其他音樂服務(wù)上收集音樂相關(guān)信息。因此，在選擇技術(shù)堆棧時，首要考慮的問題就是擴展性。
1. JVM
JVM非常適合Serendip的系統(tǒng)特性，同時它的性能也得到許多實踐驗證，選用它還很大程度上歸結(jié)于許多開源系統(tǒng)都可以使用本地客戶端。
2. Scala、Akka及Play框架
著眼JVM生態(tài)系統(tǒng)，Scala這種新式編程語言就非常突出了，同時Scala還可以與Java保持良好的互操作性。之所以選擇Scala，Akka這個適合流處理的基礎(chǔ)設(shè)施框架也占了很大一部分因素。在2011年服務(wù)開始構(gòu)建時，Play web框架才剛變得流行，可靠性也才初見端倪，那時候這些技術(shù)都是非常前沿的，不過值得興奮的是，Scala和Akka在2011年底合并成了Typesafe，而Play也在不久后合并了進(jìn)來。
3. MongoDB
選擇MongoDB的原因許多，比如對開發(fā)者友好、易于使用、特征集和可擴展性（使用自動分片）。然而，我們很快就發(fā)現(xiàn)，應(yīng)用程序的數(shù)據(jù)使用和查詢方式需求在MongoDB上建立大量索引，這樣一來，系統(tǒng)將很快遭遇性能和內(nèi)存瓶頸。因此，我們改變了MongoDB的使用策略――繼續(xù)使用MongoDB作為主要的鍵值文檔存儲，同時還利用其原子增量支撐幾個需要計數(shù)器的功能。
在更換使用策略后，MongoDB表現(xiàn)的非常穩(wěn)定。同時，MongoDB還有1個易維護的優(yōu)點，雖然很大一部分原因在于一直避免使用分片和只使用了單一的副本集（MongoDB的分片架構(gòu)確實非常復(fù)雜）。
4. Elasticsearch
為了更好的查詢數(shù)據(jù)，我們需要一個具有搜索能力成熟的系統(tǒng)。在所有可能的開源搜索解決方案中，Elasticsearch是無疑面向云解決方案中最具擴展性的一個。通過動態(tài)索引模式及多種搜索和分類的可能性，Elasticsearch讓我們看到了支撐很多特性的可能，無疑問的，它成為了系統(tǒng)架構(gòu)中的一個核心組件。
對于MongoDB和Elasticsearch的維護沒有使用托管方案，這主要基于兩個原因：首先，希望擁有兩個系統(tǒng)的絕對控制，我們不期望將升級或者降級假手于人；其次，需要處理的數(shù)據(jù)量決定使用EC2將比自己托管貴得多。
Serendip的“pump”每天處理大約500萬條信息，即處理來自Twitter、Facebook或其他系統(tǒng)的數(shù)據(jù)。這些信息經(jīng)過一系列的“filter”（從其它的服務(wù)上抓取并處理音樂鏈接，比如YouTube、Soundcloud、Bandcamp等），并為這些信息加上元數(shù)據(jù)。pump和filter在系統(tǒng)中扮演的角色類似Akka，整個過程由一個專門的m1.large EC2實例支撐；因此，它可以按需的進(jìn)行擴展，并通過Akka的remote actors將負(fù)載分配到集群處理。
從這些數(shù)據(jù)中，系統(tǒng)大約每天可以獲得85萬條有效信息，這些信息中包含了相關(guān)的音樂鏈接。所有信息都會在Elasticsearch中進(jìn)行索引，同時MongoDB中也會如此，用于備份和計數(shù)。因為每條信息都會修改幾個對象，Elasticsearch的速度大約在每秒40個左右。
在Elasticsearch中，信息（tweet和post）的索引按月進(jìn)行，每個月大約包含2500萬條信息，并且擁有3個分片。集群運行了4個節(jié)點，每個都建立在m2.2xlarge實例上，還會擁有一個m1.xlarge副本。
在feed設(shè)計時，我們期望它是動態(tài)的并且記錄了用戶行為和輸入。如果一個用戶將“rock-on”標(biāo)注到1首歌曲上，或者將“airs”打到某個藝術(shù)家上，我們希望這個行為在feed中立刻被反映。如果用戶對某個藝術(shù)家比較無愛，那么以后將不會給他推薦這首歌。
我們同樣希望這個feed整合了多個資源，比如朋友的共享、喜歡藝術(shù)家的作品以及那些具有相同品味人們的推薦。這就意味著常用的“fan-out-on-write”方法將并不適合，服務(wù)需要一個更實時feed系統(tǒng)的構(gòu)建方法，充分利用起從用戶那收集的信息，而Elasticsearch的一組特性讓一切成為可能。
Feed的算法整合了幾種策略，它會動態(tài)調(diào)整不同資源的比率，當(dāng)然每個策略都會重點考慮用戶最近的行為和輸入。策略的整合會被轉(zhuǎn)換成實時數(shù)據(jù)上的不同查詢，這些數(shù)據(jù)會不停的被Elasticsearch索引。鑒于這些數(shù)據(jù)的實時性以及索引的按月建立，系統(tǒng)只需要查詢所有數(shù)據(jù)中的很小一部分。
幸運的是，Elaticsearch對這樣的搜索支撐得非常好。同樣它還提供了架構(gòu)擴展的一個途徑――通過增加分片數(shù)量，搜索可以通過增加更多的副本和物理節(jié)點進(jìn)行擴展。
“music soulmates”的尋找過程同樣是Elasticsearch的充分應(yīng)用，作為不間斷社交流處理的一部分，系統(tǒng)會為社交網(wǎng)絡(luò)用戶計算它所收集中被共享最多的藝術(shù)家。
每當(dāng)Serendip的用戶發(fā)射一個信號（不管是airing音樂還是與feed交互），都會引起一次“music soulmates”的重計算，算法依賴于喜愛藝術(shù)家列表（會被經(jīng)常修改）重新匹配具有共同口味的用戶，當(dāng)然類似人氣、被分享次數(shù)這些數(shù)據(jù)也會被考慮進(jìn)去。同時，系統(tǒng)還會使用另一套算法來過濾垃圾推送者和異常值。
經(jīng)過長時間的生產(chǎn)環(huán)境測試，我們發(fā)現(xiàn)整個系統(tǒng)運行的非常平穩(wěn)，同時也不需要去考慮附加的系統(tǒng)來運行更加復(fù)雜的集群或者推薦算法。
Serendip使用ServerDensity進(jìn)行監(jiān)控和提醒，ServerDensity是個付費服務(wù)，原生提供了MongoDB和服務(wù)器的監(jiān)視。這個工具在系統(tǒng)內(nèi)部得到了大量使用，通過自定義指標(biāo)來顯示內(nèi)部系統(tǒng)的統(tǒng)計。
使用內(nèi)部統(tǒng)計收集機制收集系統(tǒng)內(nèi)每個行為的事件，并將它們保存在MongoDB集合中。定時作業(yè)每分鐘都會從MongoDB中讀取這個數(shù)據(jù)。這樣一來，操作數(shù)據(jù)的同時，ServerDensity還起到了監(jiān)控Elaticsearch和報警的作用。
服務(wù)器和部署的管理依賴于Amazon Elastic Beanstalk，Elastic Beanstalk是AWS定制PaaS解決方案，非常易于開始。雖然它并非完全意義上的PaaS，但是基礎(chǔ)功能足以滿足一般的用例需求。它提供了簡易的自動擴展配置，同時還可以通過EC2來完全訪問。
應(yīng)用程序的建立依賴于EC2上的Jenkins實例，Play網(wǎng)絡(luò)應(yīng)用程序被打包成一個WAR，通過post-build腳本將WAR推送給Elastic Beanstalk作為一個新應(yīng)用程序版本。新版本不會自動地部署給服務(wù)器，必須通過手動完成，通常在階段性的測試后部署到生產(chǎn)環(huán)境。
下面總結(jié)了Serendip打造過程中的幾個關(guān)鍵要素：
1. 知道如何進(jìn)行擴展。可能并不是第一天就需要擴展，但是需要清楚系統(tǒng)中每個部分的組件都可以擴展以及能擴展到什么程度，一定要給自己一定的時間進(jìn)行擴展。
2. 準(zhǔn)備好應(yīng)對峰值。特別是程序打磨的初期階段，保留足夠的空間以應(yīng)對突發(fā)負(fù)載或者進(jìn)行快速擴展。
3. 選擇一門不會拖你后腿的語言。確保語言具備你期望使用技術(shù)的本地客戶端，或者至少是積極維護的，不要讓你的應(yīng)用程序卡在庫的更新上。
4. 相信炒作。你期望的技術(shù)必然是長久存在的，一個響亮的，具備活躍社區(qū)并且評論不斷的技術(shù)恰恰證明了它的活力。
5. 不要太相信一些爭辯。多查一些該技術(shù)的熱門評論，它可以讓你知道技術(shù)的弱點所在。但是也別太在意它們，因為人們在失望時的情緒是非常激動的。
6. 擁有足夠的興趣。選擇一門讓你興奮的技術(shù)，這才能讓你保持充足的動力。
正如前文所說，Serendip為了減少MongoDB中的復(fù)雜性而避免使用分片及一些功能，接下來我們?yōu)榇蠹規(guī)淼氖荕ongoDB資深解決方案架構(gòu)師所分享的10個MongoDB深入理解：
1. MongoDB同樣需要運維。首先，MongoDB是個數(shù)據(jù)庫，因此與其他數(shù)據(jù)庫一樣，它需要容量規(guī)劃、性能調(diào)優(yōu)、監(jiān)視及維護。請不要因為MongoDB易于安裝、開始及比傳統(tǒng)關(guān)系型數(shù)據(jù)庫更友好就認(rèn)為MongoDB不需要關(guān)心及投入精力，同樣不要因為小數(shù)據(jù)集運行飛快就認(rèn)為MongoDB不需要優(yōu)秀的模式、索引策略以及支撐應(yīng)用程序所需的資源。然而一旦你做了充分的準(zhǔn)備并且吃透了那些最佳實踐，那么管理一個大型MongoDB集群將只是麻煩而不是傷透腦筋！
2. 成功的MongoDB使用者會監(jiān)控一切并隨時準(zhǔn)備好它的增長。跟蹤當(dāng)下的資源使用情況并做合適的容量規(guī)劃是使用任何數(shù)據(jù)庫系統(tǒng)必備的基礎(chǔ)，MongoDB也不能免俗。你必須了解當(dāng)下集群可以支撐的負(fù)載量，也必須清楚在負(fù)載峰值時的硬件需求。如果你不清楚負(fù)載的增長情況，你必將因為資源耗盡而煩惱。為了監(jiān)視你的MongoDB部署，你可以使用MongoDB Management Service（MMS）來可視化你的操作。
3. 擴展過程中的困難可能并不符合你的預(yù)期。在了解數(shù)百用戶的部署后，發(fā)現(xiàn)性能瓶頸通常會因為以下幾個問題產(chǎn)生（影響程度從大到小）：
模式設(shè)計不適合應(yīng)用程序需求是影響性能的首罪，其次就是索引――很差、缺少或者是太多；然而即使這兩個方面都沒有問題，性能還可能受到磁盤IO的吞吐量限制，特別是寫入吞吐量。內(nèi)存不足會導(dǎo)致許多page faulting并且給磁盤IO帶來壓力，隨著應(yīng)用規(guī)模的增加，系統(tǒng)所需的內(nèi)存越來越多。
4. 許多MongoDB用戶得益于單一的副本集。過早分片容易產(chǎn)生不成熟的優(yōu)化，不是每個MongoDB部署都需要分片。分片只適合特定的情況，而不是應(yīng)對“數(shù)據(jù)庫緩慢”的靈丹妙藥。如果你有1個錯誤的模式或者是不恰當(dāng)?shù)乃饕?，分片不能解決任何問題。只有某個資源在單機或者單副本集情況下產(chǎn)生瓶頸時，并且繼續(xù)擴展這個資源不符合投資回報比，分片才是最佳優(yōu)化方案。系統(tǒng)可能會需求更多的IO吞吐量、RAM，亦或是更多的存儲或并發(fā)性，這些情況下，分片往往比較好的選擇。
5. 即使不是將整個數(shù)據(jù)庫放入RAM中，你也可以獲得優(yōu)異的性能。在MongoDB世界里存在一個普遍的誤區(qū)――將整個數(shù)據(jù)庫放入RAM才可以獲得較高的性能。然而取決于負(fù)載的類型，這可能是世界上最大的笑話。下面是一個顯示和度量，體現(xiàn)了負(fù)載不同數(shù)據(jù)庫所需的RAM。如你所見，隨著數(shù)據(jù)庫體積的增加，放入RAM中的部分受限于有效的實體存儲器。如果RAM的大小不適合性能的需求，你將會看到page faulting，同時隨著錯誤數(shù)量的增加，系統(tǒng)的性能不升反降。
6. 數(shù)據(jù)持久化到磁盤。如果磁盤使用率已經(jīng)達(dá)到100%，那么將無法執(zhí)行更快地寫入。你可以在MMS Background flush average圖表中查看臟頁面從數(shù)據(jù)文件寫入磁盤耗費的時間，從這個趨勢來看，隨著寫入增多，這個過程將花費更多的時間。在這種情況下，你可以通過讓磁盤更快、使用更多的分片以及優(yōu)化應(yīng)用程序來解決問題。需要注意的是，每個寫入都會持久化到磁盤兩次――日志及數(shù)據(jù)文件，將這兩個操作劃分到不同的物理磁盤上可以切實地降低IO帶寬爭用。
7. 副本不等于備份。所有人都清楚備份的重要性，但是備份為何如此重要？一般情況下該歸結(jié)于可以從影響到所有副本節(jié)點數(shù)據(jù)的災(zāi)難事件中恢復(fù)，副本不等于備份的原因非常簡單，備份可以阻止數(shù)據(jù)被一些人為因素破壞――比如，某個人突然的刪掉所有生產(chǎn)數(shù)據(jù)，或者是部署了錯誤版本的應(yīng)用程序代碼，這都可能讓你的部分或者全部數(shù)據(jù)陷入危險之中。類似的情況下，你必須擁有一個備份來防止災(zāi)難的發(fā)生。因此，請進(jìn)行適當(dāng)?shù)膫浞荩词鼓阋呀?jīng)使用了文件系統(tǒng)快照、Mongodump或者是MMS備份。請不要讓你首次備份發(fā)生在數(shù)據(jù)已經(jīng)被受到威脅之時！
8. 副本集的健康程度不只看Replication lag。Replication lag體現(xiàn)了副本落后于主節(jié)點的程度，它只是副本集健康狀態(tài)的指標(biāo)之一。與之同等重要的還有replication oplog window，它會基于當(dāng)下的寫入負(fù)載計算出 oplog完全恢復(fù)所需的時間。換句話說，它表示了一個預(yù)計時間――節(jié)點發(fā)生故障并有能力從中恢復(fù)，而無需去執(zhí)行完全的數(shù)據(jù)同步。隨著時間的推移，系統(tǒng)的寫入負(fù)載可能會出現(xiàn)波動，replication oplog window同樣會隨之改變。在峰值負(fù)載下，replication oplog window將會縮短，這點在容量規(guī)劃中是非常重要的。下面是一個MMS的對比視圖，顯示了跨副本集的replication oplog window：
9. MongoDB不會知道數(shù)據(jù)需要什么級別的安全。任何數(shù)據(jù)庫的管理都需要建立在“按需訪問”之上，原則上最小化的控制權(quán)限，因此你必須自己去配置數(shù)據(jù)庫的安全級別。對MongoDB本身的安全限制也是非常重要的，你需要關(guān)閉所需訪問之外所有的權(quán)限。
10. 請勿擅自修改MongoDB的高級選項。雖然MongoDB具備這個功能，但是除非萬不得已請勿使用。在問題產(chǎn)生時，對比修改底層參數(shù)，更應(yīng)該做的是定期分析查詢及其他力所能及的事。
相關(guān)鏈接：
Building a social music service - the technology behind serendip.me
10 Things You Should Know About Running MongoDB at Scale （編譯/仲浩 審校/毛夢琪）
程序員人生，我編程，我富裕，記住wfuyu網(wǎng)，php教程，php學(xué)習(xí)，php手冊，CMS模版制作
聲明：本站大部分內(nèi)容是作者原創(chuàng)，少部分收集于互聯(lián)網(wǎng)供大家一起學(xué)習(xí)，原版權(quán)很多不明，如有侵權(quán)請聯(lián)系本站，謝謝！
粵ICP備14040726號-1?? 2015-2020 程序員人生 版權(quán)所有
