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

應用的架構

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

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

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

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

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

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

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

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

部署到云端

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

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

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

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

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

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

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