基于云的應(yīng)用與運(yùn)行在私有數(shù)據(jù)中心的應(yīng)用之間最大的差別就是可擴(kuò)展性。云提供了按需擴(kuò)展的能力，能夠根據(jù)負(fù)載的波動(dòng)對(duì)應(yīng)用進(jìn)行擴(kuò)展和收縮。但是傳統(tǒng)應(yīng)用要充分發(fā)揮云的優(yōu)勢，并不是簡單地將應(yīng)用部署到云上就萬事大吉，而是需要根據(jù)云的特點(diǎn)圍繞可擴(kuò)展性重新進(jìn)行架構(gòu)設(shè)計(jì)，近日AppDynamics的開發(fā)布道者Dustin.Whittle撰文闡述了適合云端部署的應(yīng)用架構(gòu)，對(duì)我們傳統(tǒng)應(yīng)用往云端部署有很大的啟發(fā)和借鑒意義。
應(yīng)用的架構(gòu)
Dustin.Whittle給出了云應(yīng)用的示例架構(gòu)，它具有高度的可擴(kuò)展性，如下圖所示：
在這個(gè)圖中，應(yīng)用按照分層的理念進(jìn)行了拆分，分別介紹如下：
客戶端層：客戶端層包含了針對(duì)目標(biāo)平臺(tái)的用戶界面，可能會(huì)包括基于Web的、移動(dòng)端的甚至是胖客戶端的用戶界面。一般來講，這可能會(huì)是Web應(yīng)用，包含諸如用戶管理、會(huì)話管理、頁面構(gòu)建等功能，但是其他客戶端所發(fā)起的交互都需要以RESTful服務(wù)的形式調(diào)用服務(wù)器。
服務(wù)：服務(wù)器包含了緩存服務(wù)以及聚合（aggregate）服務(wù)，其中緩存服務(wù)中持有記錄系統(tǒng)（system of record）中最新的已知狀態(tài)，而聚集服務(wù)會(huì)直接與記錄系統(tǒng)交互，并且會(huì)執(zhí)行一些破壞性的操作（會(huì)改變記錄系統(tǒng)中的狀態(tài)）。
記錄系統(tǒng)：記錄系統(tǒng)是領(lǐng)域特定的服務(wù)端，它會(huì)驅(qū)動(dòng)業(yè)務(wù)功能，可能會(huì)包括客戶管理系統(tǒng)、采購系統(tǒng)、預(yù)定系統(tǒng)等等，這些很可能是遺留系統(tǒng)，你的應(yīng)用需要與其進(jìn)行交互。聚集服務(wù)要負(fù)責(zé)將你的應(yīng)用從這些特有的記錄系統(tǒng)中抽象出來，并為你的應(yīng)用提供一致的前端接口。
ESB：當(dāng)記錄系統(tǒng)發(fā)生數(shù)據(jù)變化的時(shí)候，它需要觸發(fā)到指定主題（topic）的事件，這就是事件驅(qū)動(dòng)架構(gòu)（event-driven architecture，EDA）能夠影響應(yīng)用的地方了：當(dāng)記錄系統(tǒng)進(jìn)行了一項(xiàng)其他系統(tǒng)可能感興趣的變更時(shí)，它會(huì)觸發(fā)一個(gè)事件，任何關(guān)注記錄系統(tǒng)的其他系統(tǒng)會(huì)監(jiān)聽到這個(gè)事件，并作出對(duì)應(yīng)的響應(yīng)。這也是使用使用主題（topic）而不是隊(duì)列（queue）的原因：隊(duì)列支持點(diǎn)對(duì)點(diǎn)（point-to-point）的消息，而主題支持發(fā)布-訂閱（publish-subscribe）的消息或事件。當(dāng)與遺留系統(tǒng)進(jìn)行集成時(shí)，我們很期望這些遺留的系統(tǒng)能夠免遭負(fù)載的影響。因此，我們實(shí)現(xiàn)了一個(gè)緩存系統(tǒng)，這個(gè)緩存系統(tǒng)維持了記錄系統(tǒng)中所有最新的已知狀態(tài)。緩存系統(tǒng)會(huì)使用EDA的規(guī)則監(jiān)聽記錄系統(tǒng)的變化，它會(huì)更新自己所保存數(shù)據(jù)的版本，從而保證與記錄系統(tǒng)中的數(shù)據(jù)相匹配。這是一個(gè)很強(qiáng)大的策略，不過會(huì)將一致性模型變?yōu)樽罱K一致性，也就是說如果你在社交媒體上發(fā)布一條狀態(tài)的話，你的朋友可能在幾秒鐘甚至幾分鐘之后才能看到，數(shù)據(jù)最終是一致的，但有時(shí)你所看到的與你的朋友所看到的并不一致。如果能接受這種一致性的話，就能在很大程度上實(shí)現(xiàn)可擴(kuò)展性的收益。
NoSQL：在數(shù)據(jù)存儲(chǔ)方面，有很多的可選方案，但如果要存儲(chǔ)大量數(shù)據(jù)的話，使用NoSQL存儲(chǔ)能夠更容易地?cái)U(kuò)展。有多種NoSQL存儲(chǔ)可供選擇，不過這要匹配所存儲(chǔ)數(shù)據(jù)的特點(diǎn)，如MongoDB適合存儲(chǔ)可搜索的數(shù)據(jù)，Neo4j適合存儲(chǔ)高度互相關(guān)聯(lián)的數(shù)據(jù)，而Cassandra適合存儲(chǔ)鍵/值對(duì)，像Solr這樣的搜索索引有利于加速對(duì)經(jīng)常訪問數(shù)據(jù)的查詢。
將應(yīng)用拆分為多個(gè)層的時(shí)候，最好的模式就是使用面向服務(wù)架構(gòu)（service-oriented architecture，SOA）。要實(shí)現(xiàn)這一點(diǎn)，可以使用SOAP，也可以使用REST，但是REST更為合適，因?yàn)樗蓴U(kuò)展性更強(qiáng)。作者接下來對(duì)REST的理念進(jìn)行了深入的闡述，InfoQ上關(guān)于REST已有很多相關(guān)的文章，如這里和這里，甚至包括Roy Fielding經(jīng)典博士論文的中譯本，所以這里不再贅述。不過，作者在這里特別強(qiáng)調(diào)了RESTful Web服務(wù)能夠保持無狀態(tài)性（stateless）。無狀態(tài)是實(shí)現(xiàn)可擴(kuò)展性的關(guān)鍵需求，因?yàn)闊o狀態(tài)，所以請(qǐng)求可以由任何一個(gè)服務(wù)器響應(yīng)。如果你在服務(wù)層上需要更多的容量時(shí)，只需要為該層添加虛擬機(jī)即可，而不需關(guān)注客戶端狀態(tài)保持的問題，負(fù)載可以很容易地重新分配。
部署到云端
前面介紹了基于云的應(yīng)用架構(gòu)，接下來作者闡述了這樣的應(yīng)用該如何部署到云端。
RESTful Web服務(wù)要部署到Web容器中，并且要位于數(shù)據(jù)存儲(chǔ)之前。這些Web服務(wù)是沒有狀態(tài)的，只會(huì)反映其暴露的底層數(shù)據(jù)的狀態(tài)，因此可以根據(jù)需要部署任意數(shù)量的服務(wù)器。在基于云的部署中，開始時(shí)可以開啟足夠的實(shí)例以應(yīng)對(duì)日常的需求，然后配置彈性策略，從而根據(jù)負(fù)載增加或減少服務(wù)器的數(shù)量。衡量飽和度的最好指標(biāo)就是服務(wù)的響應(yīng)時(shí)間。另外還需要考慮這些服務(wù)所使用的底層數(shù)據(jù)存儲(chǔ)的性能。示例的部署圖如下所示：
如果在云部署時(shí)有EDA的需求，那么就需要部署ESB，作者給出的建議是根據(jù)功能對(duì)ESB進(jìn)行分區(qū)（partitioning），這樣一個(gè)segment的過大負(fù)載不會(huì)影響到其他的segment。如下圖所示：
這種分離使System 1的負(fù)載與System 2的負(fù)載實(shí)現(xiàn)了隔離。如果System 1產(chǎn)生的負(fù)載拖慢了ESB，它只會(huì)影響到自己的segment，并不會(huì)影響到System 2的segment，因?yàn)樗渴鹪谄渌布稀Ｈ绻鸈SB產(chǎn)品支持的話，我們還可以給指定的segment添加服務(wù)器來實(shí)現(xiàn)擴(kuò)展。
基于云的應(yīng)用與傳統(tǒng)應(yīng)用有著很大的差別，因?yàn)樗兄煌臄U(kuò)展性需求。基于云的應(yīng)用必須有足夠的彈性以應(yīng)對(duì)服務(wù)器的添加與移除，必須松耦合，必須盡可能的無狀態(tài)，必須預(yù)先規(guī)劃失敗的情況，并且必須能夠從幾臺(tái)服務(wù)器擴(kuò)展到成千上萬臺(tái)服務(wù)器。
針對(duì)云應(yīng)用并沒有唯一正確的架構(gòu)，但是本文所闡述的RESTful服務(wù)以及事件驅(qū)動(dòng)架構(gòu)卻是經(jīng)過實(shí)踐檢驗(yàn)有效的架構(gòu)。作者認(rèn)為REST和EDA是實(shí)現(xiàn)云端可擴(kuò)展應(yīng)用的基本工具。
目前，國內(nèi)許多傳統(tǒng)的軟件廠商正在逐漸往云端遷移，希望本文所闡述的架構(gòu)理念能夠?yàn)樽x者提供一些借鑒。
京公網(wǎng)安備 11010502049343號(hào)