告別單體架構，迎接分佈式時代!

  隨着互聯網+、智能製造等大數據應用的發展，傳統的企業信息化單體架構必定繞不過以下兩個坎：

• 單機資源瓶勁造成系統響應慢，需要高成本升級硬件來解決；
• 單機故障造成系統不可用，需要較長的時間來恢復故障。

  所以將來的企業信息化基礎架構必定是分佈式的，AppBoxFuture設計之初就確立了必須滿足簡單、低成本的分佈式架構原則，能夠利用普通硬件構建具備橫向擴展能力的集羣。作者最近在設計與實現集羣的運維管理功能，下面讓我們來體驗已實現的部分功能。

一、測試環境

二、創建集羣

1. 啓動集羣：

在VM1上執行：

sudo ./appbox --init=10.211.55.3:9000 --peer=1.1.1 

在VM2及VM3分別執行：

sudo ./appbox --join=10.211.55.3:9000 --peer=1.1.2

sudo ./appbox --join=10.211.55.3:9000 --peer=1.1.3

執行完後，打開瀏覽器輸入網址“http://任意節點:5000/ops”進入運維管理登錄界面，用戶名：Admin 密碼：760wb，可以看到集羣包含3個節點，其中第一個是元數據節點(MetaNode)。

運維管理系統由框架自身實現，可以自由修改相關模型進行自定義。

3. 提升副本因子：

依次點擊“SetAsMeta”將其他兩個節點設置爲MetaNode, 點“刷新”按鈕後可以看到另外兩個節點也轉化爲MetaNode。然後點擊“提升副本因子”按鈕將系統自帶的實體存儲提升爲副本因子3，即表的分區存在3份數據。稍候刷新可以看到如下圖所示集羣每個節點上都存在相同數量的分區，當然如果集羣包含其他非MetaNode，系統會盡量將分區均勻分佈在每個節點上。

三、測試高可用

1. 建立一個查詢服務

代碼如下圖所示，保存併發布。

其中sys.Runtime.RuntimeContext.PeerId表示當前節點的標識

2. 建立Bash腳本定時調用服務

curl指向Nginx地址

3. 執行腳本並嘗試關掉集羣某一節點

執行腳本，控制檯定時輸出服務調用結果，可以看到Nginx均衡分配至3個節點上。此時如果關閉集羣某一節點，Nginx將調用分配至其他兩個節點，整個集羣的可用性不受影響，存儲層只要讀寫的目標分區有多數派存活，就可以保障可用性。

四、本篇小結

  本篇介紹了集羣在多數派存活的情況下保障系統的高可用，GitHub上的運行時已更新可測試。作者還在努力爭取到年底前達到基本可用的狀態，請您多多點贊支持！