在前面探秘一和探秘二中，我們已經分享了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的插件形式來實作不同的資源的管理。例如ZStack的主存儲是存放虛拟機的各種Volume的，從實作上可以有NFS的主存儲，iSCSI的主存儲或者本地存儲。那麼就會去針對不同的類型實作對應的插件即可：
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具有兩個特殊的功能：
- 和插件一起合作可以改變原有系統的行為；
- 給資源添加一個新的屬性；
什麼是改變原有系統行為。例如在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