[[125700]]

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

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

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

何謂云計算？

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

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

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

借助開發應用程序的傳統方式，不可能處理這么龐大的數據量。這促使我們采用了一種全然不同的方法，開發可擴展性非常好的應用程序。那就是云應用程序。

#p#

為何開發Web應用程序的傳統方法其擴展性不夠好？

開發Web應用程序的傳統方法

不妨看一下為什么傳統應用程序無法處理規模龐大的數據。

如果你開發過一款傳統的Web應用程序，它應該與上圖非常相似。存在另外一些細小的差異，比如合并應用服務器和Web服務器或者多臺企業服務器。不過大多數時候，數據庫是關系型數據庫。Web服務器通常是有狀態（stateful）服務器，而企業服務器能同時提供無狀態服務和有狀態服務。

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

完美的可擴展性在實際環境中實現不了。確切地說，開發人員只是旨在實現近似完美的可擴展性。比如說，DNS服務器就不在我們的控制范圍之內。因而，從理論上來說，我們無法處理數量超出DNS服務器的請求。這就是任何系統的上限，連谷歌也不例外。

SQL

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

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

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

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

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

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

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

有狀態

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

就傳統應用程序而言，負載均衡系統沒有系統負載的任何信息，通常使用循環配置（Round Robin）手法，將請求分散到不同的服務器。這里的問題在于，并非所有的請求都一個樣，也并非所有的客戶機都發送數量一樣的請求。這勢必導致有些服務器不堪重負，而有些服務器仍然處于閑置狀態。

混合數據檢索和數據處理

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

#p#

重新考慮開發可擴展應用程序的最佳方法

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

醫院

[[125701]]

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

讓情況頗具挑戰性的是，我們這家醫院在互聯網時代之前就在運作了。

有狀態與無狀態

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

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

這個政策可能無法讓客戶滿意，但是對IT領域來說，有狀態服務和無狀態服務提供了同樣的結果。

數據復制

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

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

服務分離

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

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

特定的資源

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

運用這些想法來開發云應用程序

現在，你在分析了上述例子后可能覺得，大多數想法頗有道理。開發人員很快就可以開始運用這些想法來開發Web應用程序。

然后，我們就進入了云應用程序時代。

#p#

如何開發云應用程序？

為了開發云應用程序，我們就要想方設法，運用上述的想法來開發應用程序。下面是我建議采取的方法。

基礎設施

如果你開始考慮開發云應用程序，基礎設施是需要關注的頭一個問題。如果你的平臺不支持特定的資源（動態提升現有服務器的硬件規格或啟用新實例），想開發應用程序就很困難。

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

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

數據庫

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

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

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

計算密集型還是數據密集型

要是我們知道系統是數據密集型還是計算密集型，就比較好。比如說，Facebook等社交網絡幾乎完全是數據密集型，而我們的大數據分析既是數據密集型又是計算密集型。

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

數據密集型系統通常處理實時數據，而計算密集型系統運行后臺任務來處理數據。將這兩種繁重任務結合在同一個環境中可能最后會降低系統效果。

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

云應用程序的設計模式

想開發一個成功的云應用程序，我們應該牢記以下幾個方面。

1. 無狀態

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

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

• 基于Cookie的會話
• 分布式緩存會話
• 數據庫會話

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

2. 冪等性

就云應用程序而言，大多數API調用會通過網絡而進行，而不是通過內部方法調用而進行。因此，如果我們能確保方法調用安全，比較好。如果你堅持使用上述的無狀態原則，那么你實施的服務已經具有冪等性。

3. 遠程外觀

遠程外觀有別于外觀模式。它們實際上看起來似乎一樣，但旨在解決不同的問題。由于你的大多數API調用是通過網絡進行的，網絡延遲會對響應時間大有影響。借助遠程外觀模式，開發人員應該可以構建粗粒度API，那樣就可以減少調用數量。

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

4. 數據訪問對象

你在傳輸數據時，要注意所傳輸的數據量。最好只傳輸所需的最少數據。

5. 穩扎穩打

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

結束語

我希望開發云應用程序的這個方法能為大家帶來一點幫助。要是你有其他什么觀點或經驗，歡迎留言交流。

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