[[125700]]

最近，我們受命開發(fā)一個用于分析大數(shù)據(jù)的軟件即服務(wù)（SaaS）應(yīng)用程序。為了進(jìn)行數(shù)據(jù)挖掘，系統(tǒng)需要將數(shù)十億個公開帖子存儲在數(shù)據(jù)庫中，并且對這些帖子進(jìn)行分類處理。

這個環(huán)境下的分類是一個緩慢、耗費資源、又讓人痛苦的過程，需要為數(shù)據(jù)庫中的任何記錄賦予主題或情緒。對我們的測試數(shù)據(jù)進(jìn)行分類的過程持續(xù)時間長達(dá)24個小時。

為了應(yīng)對這些要求，顯然擺在我們面前的選擇就是在亞馬遜網(wǎng)絡(luò)服務(wù)（AWS）上構(gòu)建一個云應(yīng)用程序。接手這個項目一段時間后，我想交流一下本人在開發(fā)基于Java的云應(yīng)用程序方面的心得、認(rèn)識和方法。

何謂云計算？

不妨先來看看維基百科給出的定義：

這個定義可能有點模糊不清，但是可以理解，因為云計算本身與其說是個技術(shù)術(shù)語，還不如說是個營銷術(shù)語。對新手而言，要是我們用一種更實際的方法來定義云計算，理解起來就比較容易：

如今云應(yīng)用程序大行其道，這是由于人們對現(xiàn)代應(yīng)用程序提出了更高的要求。在過去，谷歌以開發(fā)含有互聯(lián)網(wǎng)上幾乎所有可用信息的具有高擴(kuò)展性的應(yīng)用程序而出名。而如今，另外許多企業(yè)需要開發(fā)能夠處理類似規(guī)模數(shù)據(jù)和計算的應(yīng)用程序（Facebook、Youtube、LinkedIn、Twitter，還有像我們這樣搜索和處理數(shù)據(jù)的人員）。

借助開發(fā)應(yīng)用程序的傳統(tǒng)方式，不可能處理這么龐大的數(shù)據(jù)量。這促使我們采用了一種全然不同的方法，開發(fā)可擴(kuò)展性非常好的應(yīng)用程序。那就是云應(yīng)用程序。

#p#

為何開發(fā)Web應(yīng)用程序的傳統(tǒng)方法其擴(kuò)展性不夠好？

開發(fā)Web應(yīng)用程序的傳統(tǒng)方法

不妨看一下為什么傳統(tǒng)應(yīng)用程序無法處理規(guī)模龐大的數(shù)據(jù)。

如果你開發(fā)過一款傳統(tǒng)的Web應(yīng)用程序，它應(yīng)該與上圖非常相似。存在另外一些細(xì)小的差異，比如合并應(yīng)用服務(wù)器和Web服務(wù)器或者多臺企業(yè)服務(wù)器。不過大多數(shù)時候，數(shù)據(jù)庫是關(guān)系型數(shù)據(jù)庫。Web服務(wù)器通常是有狀態(tài)（stateful）服務(wù)器，而企業(yè)服務(wù)器能同時提供無狀態(tài)服務(wù)和有狀態(tài)服務(wù)。

有一些重大的缺點導(dǎo)致這種架構(gòu)不具備足夠好的可擴(kuò)展性。我們不妨先從定義完美的可擴(kuò)展性開始分析。

完美的可擴(kuò)展性在實際環(huán)境中實現(xiàn)不了。確切地說，開發(fā)人員只是旨在實現(xiàn)近似完美的可擴(kuò)展性。比如說，DNS服務(wù)器就不在我們的控制范圍之內(nèi)。因而，從理論上來說，我們無法處理數(shù)量超出DNS服務(wù)器的請求。這就是任何系統(tǒng)的上限，連谷歌也不例外。

SQL

回到上面那個圖，最大的弱點在于數(shù)據(jù)庫的可擴(kuò)展性。請求數(shù)量和數(shù)據(jù)大小都足夠小時，開發(fā)人員應(yīng)該不會注意到負(fù)載增加后性能受到的任何影響。繼續(xù)進(jìn)一步增加負(fù)載，如果處理器的使用率達(dá)到100%或者內(nèi)存全部被占用，影響可能非常明顯。這時候，最實際的辦法就是為數(shù)據(jù)庫系統(tǒng)提供更多的內(nèi)存和處理器資源。之后，系統(tǒng)可能會再度順暢運行起來。

遺憾的是，這種方法不可能只要問題出現(xiàn)就可以永遠(yuǎn)重復(fù)?？偸菚嬖谝粋€限制：不管你擁有多少內(nèi)存和處理器資源，性能總會慢慢變得越來越差。這是預(yù)料之中的事，因為會有許多請求需要創(chuàng)建、讀取、更新和刪除（CRUD）某一些記錄。不管你是決定緩存記錄、將記錄存儲在內(nèi)存中還是采取其他任何手段，它們都是獨特的記錄，存在于單一機(jī)器中，多少數(shù)量的訪問請求可以發(fā)送到某一個內(nèi)存地址是有限制的。

這又是不可避免的限制，因為SQL是為確保完整性而開發(fā)的。為了確保完整性，SQL服務(wù)器中的任何信息都應(yīng)該具有獨特性，這點必不可少。即便在進(jìn)行了數(shù)據(jù)隔離或復(fù)制之后，這個特點仍然適用（至少對主實例來說是這樣）。

相比之下，NoSQL并不試圖對數(shù)據(jù)進(jìn)行規(guī)范化。相反，它選擇存儲聚合對象，這些對象里面可能含有重復(fù)的信息。因此，NoSQL只有在數(shù)據(jù)完整性并非必需的情況下才適用。

來自couchbase.com的上面這個例子表明了數(shù)據(jù)如何存儲在文檔數(shù)據(jù)庫中以及如何存儲在關(guān)系數(shù)據(jù)庫中。如果某戶人家有多個成員，關(guān)系數(shù)據(jù)庫只為所有家庭成員存儲一個地址，而NoSQL數(shù)據(jù)庫只是復(fù)制住址。某家人搬家后，所有家庭成員的住址可能在一個事務(wù)中未被更新，這違反了數(shù)據(jù)完整性。

不過，對我們的應(yīng)用程序及另外許多應(yīng)用程序而言，這種暫時的違反是可以接受的。比如說，你可能不需要你的社交網(wǎng)頁頁面瀏覽量或社交網(wǎng)站的公開帖子數(shù)做到百分之百準(zhǔn)確。

數(shù)據(jù)重復(fù)實際上消除了我們上面提到的針對單單一個內(nèi)存地址的并發(fā)訪問，讓開發(fā)人員可以選擇將數(shù)據(jù)存儲在自己希望的任何地方，只要一個節(jié)點中的變化內(nèi)容可以慢慢同步到其他節(jié)點。這種架構(gòu)的可擴(kuò)展性強得多。

有狀態(tài)

下一個問題是有狀態(tài)服務(wù)。有狀態(tài)服務(wù)需要同一批硬件來服務(wù)同一客戶機(jī)提出的請求。客戶機(jī)數(shù)量增加后，最明智的舉動就是將更多的應(yīng)用服務(wù)器和Web服務(wù)器部署到系統(tǒng)中。不過就有狀態(tài)服務(wù)而言，資源分配無法做到完全優(yōu)化。

就傳統(tǒng)應(yīng)用程序而言，負(fù)載均衡系統(tǒng)沒有系統(tǒng)負(fù)載的任何信息，通常使用循環(huán)配置（Round Robin）手法，將請求分散到不同的服務(wù)器。這里的問題在于，并非所有的請求都一個樣，也并非所有的客戶機(jī)都發(fā)送數(shù)量一樣的請求。這勢必導(dǎo)致有些服務(wù)器不堪重負(fù)，而有些服務(wù)器仍然處于閑置狀態(tài)。

混合數(shù)據(jù)檢索和數(shù)據(jù)處理

就傳統(tǒng)應(yīng)用程序而言，從數(shù)據(jù)庫檢索數(shù)據(jù)的服務(wù)器最終要處理數(shù)據(jù)。處理數(shù)據(jù)和檢索數(shù)據(jù)之間沒有明確的分離。這兩項任務(wù)都會給系統(tǒng)帶來瓶頸。如果瓶頸來自數(shù)據(jù)檢索，數(shù)據(jù)處理自然未得到充分使用，反之亦然。

#p#

重新考慮開發(fā)可擴(kuò)展應(yīng)用程序的最佳方法

看一下最近我們IT領(lǐng)域采用的方法，我發(fā)現(xiàn)它們根本不是什么新發(fā)明。確切地說，IT領(lǐng)域只是采用了已在實際生活中成功運用的方法來解決可擴(kuò)展性問題。為了闡明這一點，不妨設(shè)想處理可擴(kuò)展性問題的實際情形。

醫(yī)院

[[125701]]

假設(shè)我們有一家小型醫(yī)院。就這個醫(yī)院而言，我們服務(wù)的對象主要是本地客戶。每個忠誠的客戶都有自己青睞的醫(yī)生，醫(yī)生跟蹤記錄病人的病歷。正由于如此，客戶只要出示IC病歷卡，他們青睞的醫(yī)生就會處理病歷。

讓情況頗具挑戰(zhàn)性的是，我們這家醫(yī)院在互聯(lián)網(wǎng)時代之前就在運作了。

有狀態(tài)與無狀態(tài)

上述描述是不是看起來與有狀態(tài)服務(wù)足夠相似？現(xiàn)在，你的醫(yī)院開始有了名氣，客戶數(shù)量突然激增。假設(shè)你擁有足夠的硬件基礎(chǔ)設(shè)施，一個明顯的選擇就是招聘更多的醫(yī)生護(hù)士。不過，客戶不愿意換新來的醫(yī)生。這導(dǎo)致新來的醫(yī)工作員很空，而原來的工作人員很忙。

為了確保優(yōu)化，你決定改變醫(yī)院政策，以便客戶必須保留其病歷，醫(yī)院將把他們分派給任何有空的醫(yī)生。這個新做法有助于解決醫(yī)院的所有頭痛問題，讓醫(yī)院有辦法調(diào)派更多的季節(jié)性人員，以處理客戶數(shù)量突然激增的局面。

這個政策可能無法讓客戶滿意，但是對IT領(lǐng)域來說，有狀態(tài)服務(wù)和無狀態(tài)服務(wù)提供了同樣的結(jié)果。

數(shù)據(jù)復(fù)制

假設(shè)客戶數(shù)量在不斷激增，你開始考慮開設(shè)更多的分院。與此同時，出現(xiàn)了一個新的問題：客戶不斷抱怨醫(yī)院規(guī)定看病就診時要帶病歷的做法。

為了解決這個問題，你重新沿用了原來的政策：將病歷儲存在醫(yī)院。不過，當(dāng)你擁有不止一家分院，每家分院都需要儲存用戶病歷的副本。一天或一周下來，記錄的任何變化都需要同步到每一家分院。

服務(wù)分離

醫(yī)院運作了幾個月后，你認(rèn)識到資源分配沒有得到非常理想的優(yōu)化。比如說，你在分院A和分院B都設(shè)有驗血科和X光科。不過，許多客戶在分院A進(jìn)行驗血，許多人在分院B拍X光片。

這導(dǎo)致客戶在一家分院不斷等待，另一家分院卻無人光顧。為了優(yōu)化資源，你關(guān)閉了沒充分利用起來的科室，建立了獨特的驗血中心和X光中心。客戶將從這些分院分派到提供特殊服務(wù)的特設(shè)中心。

特定的資源

很難為醫(yī)院進(jìn)行資源規(guī)劃，因為季節(jié)性疾病只在一年當(dāng)中的某個時間段才發(fā)生。此外，災(zāi)難有可能隨時都會發(fā)生。它們導(dǎo)致短期內(nèi)病房病人突然激增。為了應(yīng)對這種情況，你可能想與市政當(dāng)局簽訂協(xié)議，以便需要時可以暫時租賃設(shè)施和場地，招聘更多的兼職人員。

運用這些想法來開發(fā)云應(yīng)用程序

現(xiàn)在，你在分析了上述例子后可能覺得，大多數(shù)想法頗有道理。開發(fā)人員很快就可以開始運用這些想法來開發(fā)Web應(yīng)用程序。

然后，我們就進(jìn)入了云應(yīng)用程序時代。

#p#

如何開發(fā)云應(yīng)用程序？

為了開發(fā)云應(yīng)用程序，我們就要想方設(shè)法，運用上述的想法來開發(fā)應(yīng)用程序。下面是我建議采取的方法。

基礎(chǔ)設(shè)施

如果你開始考慮開發(fā)云應(yīng)用程序，基礎(chǔ)設(shè)施是需要關(guān)注的頭一個問題。如果你的平臺不支持特定的資源（動態(tài)提升現(xiàn)有服務(wù)器的硬件規(guī)格或啟用新實例），想開發(fā)應(yīng)用程序就很困難。

眼下，我們之所以選擇AWS是因為它是市面上最成熟的平臺。一年前，由于AWS具有的一些重大好處，我們從內(nèi)部托管模式轉(zhuǎn)為AWS托管模式。

• 多個位置：我們的客戶來自五大洲；使用亞馬遜區(qū)域（Amazon Region），我們就能讓部署的實例更靠近客戶位置；這樣一來，可以縮短響應(yīng)時間。
• 監(jiān)控和自動擴(kuò)展：亞馬遜為其平臺提供了一種相當(dāng)有效的監(jiān)控服務(wù)。面對服務(wù)器負(fù)載，可以實現(xiàn)自動擴(kuò)展。
• 內(nèi)容分發(fā)網(wǎng)絡(luò)：亞馬遜CloudFront為我們提供了這一選項，即將靜態(tài)內(nèi)容從主部署環(huán)境卸載過來，這將縮短頁面裝入時間。類似平常的實例，靜態(tài)內(nèi)容從最近的實例提供給客戶。
• 同步與分布式緩存：這些年來，MemCache一直是我們青睞的緩存解決方案。不過，一大問題是缺少對節(jié)點之間同步的支持。亞馬遜彈性緩存（Amazon Elastic Cache）為我們提供了使用MemCache的選擇，而不必?fù)?dān)心節(jié)點同步問題。
• 管理型API：這是一大優(yōu)點。最近，我們開始充分使用管理型API，以便短時間啟用實例，從而運行集成測試。

數(shù)據(jù)庫

假設(shè)你已選擇了用來開發(fā)云應(yīng)用程序的平臺，下一步應(yīng)該是為你的系統(tǒng)選擇合適的數(shù)據(jù)庫。你需要做出的第一個決策就是哪個適合你的系統(tǒng)，是SQL還是NoSQL？如果系統(tǒng)不是數(shù)據(jù)密集型，SQL應(yīng)該可以；如果系統(tǒng)是數(shù)據(jù)密集型，那么你應(yīng)該考慮NoSQL。

有時候，多個數(shù)據(jù)庫可以一起使用。比如說，如果我們想實施Facebook之類的社交網(wǎng)絡(luò)應(yīng)用程序，就可以將系統(tǒng)設(shè)置、或者甚至用戶配置文件存儲在SQL數(shù)據(jù)庫中。相比之下，由于數(shù)據(jù)量龐大，用戶帖子必須存儲在NoSQL數(shù)據(jù)庫中。此外，我們可以選擇具有強大搜索功能的SOLR來存儲公共帖子，并選擇Mongo DB用來存儲用戶活動。

可能的話，務(wù)必選擇支持集群、數(shù)據(jù)隔離和負(fù)載均衡等功能的數(shù)據(jù)庫系統(tǒng)。要不然，你可能到頭來得自行實施所有這些功能特性。比如說，相比Lucene，SOLR應(yīng)該是更合適的選擇，除非我們想自己進(jìn)行數(shù)據(jù)隔離。

計算密集型還是數(shù)據(jù)密集型

要是我們知道系統(tǒng)是數(shù)據(jù)密集型還是計算密集型，就比較好。比如說，F(xiàn)acebook等社交網(wǎng)絡(luò)幾乎完全是數(shù)據(jù)密集型，而我們的大數(shù)據(jù)分析既是數(shù)據(jù)密集型又是計算密集型。

就數(shù)據(jù)密集型系統(tǒng)而言，我們可以讓云中的任何一個節(jié)點檢索數(shù)據(jù)、同時處理數(shù)據(jù)。如果是計算密集型節(jié)點，最好還是將數(shù)據(jù)檢索和數(shù)據(jù)處理分開來。

數(shù)據(jù)密集型系統(tǒng)通常處理實時數(shù)據(jù)，而計算密集型系統(tǒng)運行后臺任務(wù)來處理數(shù)據(jù)。將這兩種繁重任務(wù)結(jié)合在同一個環(huán)境中可能最后會降低系統(tǒng)效果。

就計算云而言，最好是有一個框架來監(jiān)控負(fù)載、分發(fā)任務(wù)以及計算完畢后收集結(jié)果。如果你不需要處理是實時的，Hadoop是市面上的最佳選擇。如果需要實時計算，那么可以考慮Apache Storm。

云應(yīng)用程序的設(shè)計模式

想開發(fā)一個成功的云應(yīng)用程序，我們應(yīng)該牢記以下幾個方面。

1. 無狀態(tài)

讓你的所有服務(wù)和服務(wù)器都是無狀態(tài)，這點必不可少。如果服務(wù)需要用戶數(shù)據(jù)，就把它們作為參數(shù)添加到API中。

值得注意的是，想在Web服務(wù)器上實施無狀態(tài)會話（Stateless Session），我們有幾個選擇可以考慮：

• 基于Cookie的會話
• 分布式緩存會話
• 數(shù)據(jù)庫會話

上述解決方案從上往下排列，可擴(kuò)展性較差，但可管理性較強。

2. 冪等性

就云應(yīng)用程序而言，大多數(shù)API調(diào)用會通過網(wǎng)絡(luò)而進(jìn)行，而不是通過內(nèi)部方法調(diào)用而進(jìn)行。因此，如果我們能確保方法調(diào)用安全，比較好。如果你堅持使用上述的無狀態(tài)原則，那么你實施的服務(wù)已經(jīng)具有冪等性。

3. 遠(yuǎn)程外觀

遠(yuǎn)程外觀有別于外觀模式。它們實際上看起來似乎一樣，但旨在解決不同的問題。由于你的大多數(shù)API調(diào)用是通過網(wǎng)絡(luò)進(jìn)行的，網(wǎng)絡(luò)延遲會對響應(yīng)時間大有影響。借助遠(yuǎn)程外觀模式，開發(fā)人員應(yīng)該可以構(gòu)建粗粒度API，那樣就可以減少調(diào)用數(shù)量。

通俗地說，跑一趟超市，一次性購買10件商品比跑20趟超市、每趟購買1件商品來得明智。

4. 數(shù)據(jù)訪問對象

你在傳輸數(shù)據(jù)時，要注意所傳輸?shù)臄?shù)據(jù)量。最好只傳輸所需的最少數(shù)據(jù)。

5. 穩(wěn)扎穩(wěn)打

這不是設(shè)計模式，但你會在將來慶幸穩(wěn)扎穩(wěn)打。由于分布式計算的特性，一旦哪里出了問題，就很難查明具體是哪個部分出了岔子。可能的話，為系統(tǒng)中的每個部分實施運行狀況檢查、ping檢測、全面日志、調(diào)試模式等安全機(jī)制。

結(jié)束語

我希望開發(fā)云應(yīng)用程序的這個方法能為大家?guī)硪稽c幫助。要是你有其他什么觀點或經(jīng)驗，歡迎留言交流。

https://weblogs.java.net/blog/sgdev-blog/archive/2014/05/20/how-build-java-based-cloud-application

英文原文鏈接:http://sgdev-blog.blogspot.com/2014/05/how-to-build-java-based-cloud.html