基于云的應用與運行在私有數(shù)據(jù)中心的應用之間最大的差別就是可擴展性。云提供了按需擴展的能力，能夠根據(jù)負載的波動對應用進行擴展和收縮。但是傳統(tǒng)應用要充分發(fā)揮云的優(yōu)勢，并不是簡單地將應用部署到云上就萬事大吉，而是需要根據(jù)云的特點圍繞可擴展性重新進行架構設計，近日AppDynamics的開發(fā)布道者Dustin.Whittle撰文闡述了適合云端部署的應用架構，對我們傳統(tǒng)應用往云端部署有很大的啟發(fā)和借鑒意義。

應用的架構

Dustin.Whittle給出了云應用的示例架構，它具有高度的可擴展性，如下圖所示：

在這個圖中，應用按照分層的理念進行了拆分，分別介紹如下：

客戶端層：客戶端層包含了針對目標平臺的用戶界面，可能會包括基于Web的、移動端的甚至是胖客戶端的用戶界面。一般來講，這可能會是Web應用，包含諸如用戶管理、會話管理、頁面構建等功能，但是其他客戶端所發(fā)起的交互都需要以RESTful服務的形式調(diào)用服務器。

服務：服務器包含了緩存服務以及聚合（aggregate）服務，其中緩存服務中持有記錄系統(tǒng)（system of record）中最新的已知狀態(tài)，而聚集服務會直接與記錄系統(tǒng)交互，并且會執(zhí)行一些破壞性的操作（會改變記錄系統(tǒng)中的狀態(tài)）。

記錄系統(tǒng)：記錄系統(tǒng)是領域特定的服務端，它會驅(qū)動業(yè)務功能，可能會包括客戶管理系統(tǒng)、采購系統(tǒng)、預定系統(tǒng)等等，這些很可能是遺留系統(tǒng)，你的應用需要與其進行交互。聚集服務要負責將你的應用從這些特有的記錄系統(tǒng)中抽象出來，并為你的應用提供一致的前端接口。

ESB：當記錄系統(tǒng)發(fā)生數(shù)據(jù)變化的時候，它需要觸發(fā)到指定主題（topic）的事件，這就是事件驅(qū)動架構（event-driven architecture，EDA）能夠影響應用的地方了：當記錄系統(tǒng)進行了一項其他系統(tǒng)可能感興趣的變更時，它會觸發(fā)一個事件，任何關注記錄系統(tǒng)的其他系統(tǒng)會監(jiān)聽到這個事件，并作出對應的響應。這也是使用使用主題（topic）而不是隊列（queue）的原因：隊列支持點對點（point-to-point）的消息，而主題支持發(fā)布-訂閱（publish-subscribe）的消息或事件。當與遺留系統(tǒng)進行集成時，我們很期望這些遺留的系統(tǒng)能夠免遭負載的影響。因此，我們實現(xiàn)了一個緩存系統(tǒng)，這個緩存系統(tǒng)維持了記錄系統(tǒng)中所有最新的已知狀態(tài)。緩存系統(tǒng)會使用EDA的規(guī)則監(jiān)聽記錄系統(tǒng)的變化，它會更新自己所保存數(shù)據(jù)的版本，從而保證與記錄系統(tǒng)中的數(shù)據(jù)相匹配。這是一個很強大的策略，不過會將一致性模型變?yōu)樽罱K一致性，也就是說如果你在社交媒體上發(fā)布一條狀態(tài)的話，你的朋友可能在幾秒鐘甚至幾分鐘之后才能看到，數(shù)據(jù)最終是一致的，但有時你所看到的與你的朋友所看到的并不一致。如果能接受這種一致性的話，就能在很大程度上實現(xiàn)可擴展性的收益。

NoSQL：在數(shù)據(jù)存儲方面，有很多的可選方案，但如果要存儲大量數(shù)據(jù)的話，使用NoSQL存儲能夠更容易地擴展。有多種NoSQL存儲可供選擇，不過這要匹配所存儲數(shù)據(jù)的特點，如MongoDB適合存儲可搜索的數(shù)據(jù)，Neo4j適合存儲高度互相關聯(lián)的數(shù)據(jù)，而Cassandra適合存儲鍵/值對，像Solr這樣的搜索索引有利于加速對經(jīng)常訪問數(shù)據(jù)的查詢。

將應用拆分為多個層的時候，最好的模式就是使用面向服務架構（service-oriented architecture，SOA）。要實現(xiàn)這一點，可以使用SOAP，也可以使用REST，但是REST更為合適，因為它可擴展性更強。作者接下來對REST的理念進行了深入的闡述，InfoQ上關于REST已有很多相關的文章，如這里和這里，甚至包括Roy Fielding經(jīng)典博士論文的中譯本，所以這里不再贅述。不過，作者在這里特別強調(diào)了RESTful Web服務能夠保持無狀態(tài)性（stateless）。無狀態(tài)是實現(xiàn)可擴展性的關鍵需求，因為無狀態(tài)，所以請求可以由任何一個服務器響應。如果你在服務層上需要更多的容量時，只需要為該層添加虛擬機即可，而不需關注客戶端狀態(tài)保持的問題，負載可以很容易地重新分配。

部署到云端

前面介紹了基于云的應用架構，接下來作者闡述了這樣的應用該如何部署到云端。

RESTful Web服務要部署到Web容器中，并且要位于數(shù)據(jù)存儲之前。這些Web服務是沒有狀態(tài)的，只會反映其暴露的底層數(shù)據(jù)的狀態(tài)，因此可以根據(jù)需要部署任意數(shù)量的服務器。在基于云的部署中，開始時可以開啟足夠的實例以應對日常的需求，然后配置彈性策略，從而根據(jù)負載增加或減少服務器的數(shù)量。衡量飽和度的最好指標就是服務的響應時間。另外還需要考慮這些服務所使用的底層數(shù)據(jù)存儲的性能。示例的部署圖如下所示：

如果在云部署時有EDA的需求，那么就需要部署ESB，作者給出的建議是根據(jù)功能對ESB進行分區(qū)（partitioning），這樣一個segment的過大負載不會影響到其他的segment。如下圖所示：

這種分離使System 1的負載與System 2的負載實現(xiàn)了隔離。如果System 1產(chǎn)生的負載拖慢了ESB，它只會影響到自己的segment，并不會影響到System 2的segment，因為它部署在其他硬件上。如果ESB產(chǎn)品支持的話，我們還可以給指定的segment添加服務器來實現(xiàn)擴展。

基于云的應用與傳統(tǒng)應用有著很大的差別，因為它有著不同的擴展性需求�；�于云的應用必須有足夠的彈性以應對服務器的添加與移除，必須松耦合，必須盡可能的無狀態(tài)，必須預先規(guī)劃失敗的情況，并且必須能夠從幾臺服務器擴展到成千上萬臺服務器。

針對云應用并沒有唯一正確的架構，但是本文所闡述的RESTful服務以及事件驅(qū)動架構卻是經(jīng)過實踐檢驗有效的架構。作者認為REST和EDA是實現(xiàn)云端可擴展應用的基本工具。

目前，國內(nèi)許多傳統(tǒng)的軟件廠商正在逐漸往云端遷移，希望本文所闡述的架構理念能夠為讀者提供一些借鑒。

在不久的將來，云計算一定會徹底走入我們的生活，有興趣入行未來前沿產(chǎn)業(yè)的朋友，可以收藏云計算，及時獲取人工智能、大數(shù)據(jù)、云計算和物聯(lián)網(wǎng)的前沿資訊和基礎知識，讓我們一起攜手，引領人工智能的未來！

標簽： 大數(shù)據(jù) 服務器 媒體 搜索 云計算

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。