在前面探祕一和探祕二中，我們已經分享了ZStack的拓撲結構和如何實現超高可伸縮性的能力。還記得我們在Why ZStack中說的，穩定性和靈活性是IaaS需要解決的兩大問題。今天我們就來揭開ZStack超強靈活性的奧祕。

今天的內容非常的豐富，我們先來看一下什麼是靈活性。所謂靈活性無非是三個方面：當需要新增新功能的時候簡單方便，不拖泥帶水；系統升級輕巧無障礙；IaaS雲配置想改就改，無需重頭搭建，改動影響僅限於被影響的部分。讓我們帶著這三個方面的定義來讀今天的內容。

首先讓我們看看通常一個自由生長出來的IaaS，它內部各個Components之間的訊息傳遞或者說邏輯關係圖吧。

是不是看起來還行？熟悉IaaS的人應該可以理解。有沒有想過當你再增加一個監控，一個計費，一個管理介面的時候，它可就不只是增加三個圈圈這麼簡單了，這圖裡的連線線怕是要多上好幾倍。而當你需要修改一個圈圈的資料結構和輸出結果的時候，你需要更改所有和當前圈圈有聯絡的其他功能模組的介面。為什麼會是這樣？這因為在自由生長的IaaS設計之初，功能比較單一，模組很少，所以模組之間的連線簡單而清晰，直連的方法最容易實現而且有效。但是當等到專案越變越大，連線越連越多的時候，一切都晚了，到最後就變成就是一個令人恐怖的拓撲結構。

多說無益，讓我們直接來看看ZStack各個模組之間的關係圖吧，星型拓撲結構：

每個微服務自然分離，又通過統一的Message Bus來連線。新增新的微服務，就增加一個星型節點和一條連線。是不是很清晰很簡單？為什麼會怎麼簡單呢？好像也沒有為什麼，這就是大自然在靈活性上的應該遵循的規則啊。

在ZStack裡面，微服務的架構又被稱為程序內的微服務（In Process Micro Service中文翻譯實在拗口啊）。它有如下的特點：

• 每個服務之間相互獨立，通過訊息匯流排連線；

• 所有的微服務都集合在同一個程序內，也就是我們說的管理節點（Management Node）

• 因為通過訊息匯流排連線，在不同管理節點上的微服務都可以相互通訊（並且相互不知道是不是在相同的管理節點上）

• 在多管理節點上存在相同的微服務（例如都有管理計算的微服務），最後由哪個管理節點上微服務來處理任務，是由Consistent Hashing Ring選擇出來的（這點我們在《ZStack架構探祕二》中有闡述）

接著讓我們來看看ZStack是如何新增一個服務的。有了星型拓撲結構，新增新的微服務就變的簡單起來。除了常規的微服務，IaaS的操作最終要落地在管理計算，儲存和網路三大資源上。拿計算資源來舉例，它有一個計算服務。在計算服務下面存在虛擬化和非虛擬化兩種形式，其中虛擬化也可以分為KVM、VMWare、Xen、HyperV等。如果ZStack支援了KVM，也就是說要整合所有KVM的基本功能。另外，相比儲存和網路，計算資源的種類是很少的。也就是一個可以工作的IaaS裡面會整合很多的服務和具體的功能。面對可能多到數不清的微服務和具體功能，ZStack是怎麼來支援的呢？可以用什麼方法來保證新新增的功能既方便又不影響現有其他功能呢？ZStack採用了類似Eclipse的外掛形式

L2的網路也是一樣的道理，可以通過Vlan，OpenVSwitch，或者VxLan來實現隔離和連通：

那具體來說，一個plugin是怎麼實現的呢？ZStack的plugin根據所需要的功能可以採用不同的plugin策略：Strategy Plugin或者Oberserver Plugin。簡而言之，策略外掛會繼承父型別的介面然後做具體的實現（例如實現NFS外掛）；觀察者外掛，會註冊listener到提供註冊的地方，當特別的事件發生的時候，註冊的lisetener就會被呼叫，然後在呼叫中去實現外掛的功能（例如在建立VM之前去登記計費。或者如下例所展示的SecurityGroup需要在不同的操作的時候去新增和刪除對應的SG規則。）。

需要指出的是，ZStack的外掛非常靈活。它可以編譯成獨立的JAR檔案，由ZStack載入（成為程序內in process的一部分）。刪除後，也只是失去了該外掛的功能本身，而不會影響其他功能。另外，由於ZStack的服務都是通過Rabbitmq來通訊的，也就是我們也支援任何可以和Rabbitmq來通訊的程序外（out-of-process）外掛。所以ZStack的外掛功能是非常靈活的。使用者可以選擇任何語言來實現自己的外掛。

ZStack是如何處理錯誤的？能回滾錯誤造成的影響嗎？由於IaaS管理的是非常複雜而龐大的系統，錯誤（由於網路，軟體甚至硬體導致）發生頻率一定不少。一個好的軟體系統不僅僅能在一切正常的情況下能夠穩定工作，更需要在不穩定的系統中能夠提供穩定執行的能力。這就需要完善的容錯和糾錯的手段，在發生不可預見的系統的錯誤的時候，能夠正確處理。事件回滾是處理由於出錯導致的很多臨時中間狀態（有時候這些中間狀態實際上就是系統垃圾）的有效手段。例如當建立VM的操作失敗在最後一步，例如Host掉電。那麼之前給VM分配的IP地址，根分割槽檔案，資料庫記錄都應該通過回滾而清理掉。如果不回滾，那麼系統中的就會留下很多垃圾，最終導致IaaS資源耗盡。

ZStack設計了精巧的工作流引擎（Workflow Engine）既用來管理任務執行的順序，而且不論任務在什麼地方出錯都會按照原先執行的路徑回滾。

ZStack 工作流引擎有如下特點：

• 工作流可以用XML檔案或者具體程式設計實現；

• 每一個工作流都可以回滾錯誤；

• 每個工作流還可以包含子工作流用於擴充套件業務邏輯

讓我們來看看如何通過XML檔案來定義ZStack的一組工作流的：

雖然利用外掛系統可以新增新的功能，但是如果我們需要對原有功能進行擴充套件（這個不可避免，畢竟人的認知是有限的，不能保證原有功能可以支援未來更豐富的引數），可能會改變介面或者是改變原有資料結構中的表單。這種改變導致的問題是，基於原有資料庫搭建的IaaS很難遷移和升級。我們可以看到在現有的IaaS系統裡，這個方面的問題非常突出。為了解決這個問題，ZStack創造性的發明了一個Tag系統。通常大家認為的Tag系統只是用於給資源打標記做歸類。ZStack的Tag系統除了最基本的打標籤的功能外，它還可以實現System Tag。System Tag具有兩個特殊的功能：

1. 和外掛一起合作可以改變原有系統的行為；
   

2. 給資源新增一個新的屬性；

什麼是改變原有系統行為。例如在ZStack中，一個Cluster可以掛載多個主儲存。在啟動VM的時候，使用者通常只能選擇VM的Zone，Cluster，Host等資訊（如果不指定，ZStack會按照預先設計的策略自己選擇）。如果使用者希望VM被建立到一個特定的主儲存，這個時候就可以利用系統System Tag來實現。例如我們可以實現一個特別的系統Tag，並且實現一個外掛規定：當我們需要建立的VM被標註該系統Tag，那麼這個VM的主儲存就會在預先指定的一個主儲存（該主儲存也會被設定上相同的系統Tag）上建立。在ZStack中，VM可以設定DHCP Hostname。也就是在VM在獲取DHCP IP地址的時候，同時也會獲取一個系統分配的Hostname。但是由於這個DHCP HOSTNAM 並不是VM網絡卡的固定屬性（因為從物理資源角度，VM NIC的確不應該具有一個Hostname的屬性），最後在ZStack中，Hostname的功能也是通過系統Tag來實現的。

最後我們來談談IaaS部署後，滿足客戶需求變更的問題。前面我們基本上都是在講怎麼能夠給IaaS更容易的新增功能的問題。不過判斷IaaS是否靈活，還有一個非常非常關鍵的問題，就是IaaS根據使用者的要求配置完成後運行了一段時間，使用者發現原有的資源配置需要更改，IaaS能否根據使用者的要求改變？這個改變是不是可以通過一兩個命令就完成，還是需要重頭搭建整個IaaS系統？對於ZStack來說，我們的一大殺手鐗就是配置靈活易變。我們暴露了非常全面的API，既有Add/Create Resource的，也有Delete/Destroy Resource的API，還有大量的resource的掛載和解除安裝的API。可以說使用者想改變網路拓撲，如把eth0的裝置去掉，或是替換主儲存的裝置對ZStack來說都是小菜一碟。新增的操作其實影響還好，但是刪除的操作可是會造成大面積的影響。比如刪除一個host，它的影響只限於這個host上，該host上的VM會被暫時stop掉；而刪除一個Cluster，會導致刪除這個Cluster上所有的Hosts，解除安裝主儲存，以及相關的VM被刪除。而刪除L2 Network，則會導致正在使用該L2網路的VM（可能會跨很多的Cluster）被Stop掉。在ZStack中，我們有專門計算和處理由於刪除架構中的某個資源而會波及到做哪些操作的Cascade Framework。這個架構說起來其實也很輕巧，你需要構建一個大大的地圖，把資源按照相互關係梳理出來。不過很可惜的是，我們沒有在別的IaaS系統中發現有如此輕巧的設計，恐怕它們以後也沒有辦法推出類似的設計了。

有了這個資源相互影響地圖後，當解除安裝或者刪除一個資源的時候，我們就可以輕鬆的把受影響的資源的處理方法安裝順序呼叫一遍。

今天，我們一口氣介紹了ZStack的五項獨門祕籍，它們可都是為實現超靈活性和可擴充套件性而量身定做的。他們既獨立發揮著作用，又有相互關聯。可以說是構成ZStack架構中非常重要的5個環節。通過他們，希望大家對我們的超靈活性有了進一步的瞭解。我們可是絕不忽悠，是騾子是馬大家拉出來遛遛。另外由於微信裡的內容都是點到為止，詳細內容還請大家移步我們的官網，上面詳細闡述了五大祕籍的來龍去脈：

• In-Process Microservice Architecture: http://zstack.org/blog/microservices.html

• Plugin System: http://zstack.org/blog/plugin.html

• WorkFlow Engine: http://zstack.org/blog/workflow.html

• Tag System: http://zstack.org/blog/tag.html

• Cascade Framework: http://zstack.org/blog/cascade.html