前言
在《一圖讀懂BaaS》中我們介紹了BaaS平台作為一種將區塊鍊和雲計算深度結合的新型服務平台，能幫助用戶快速上手區塊鏈業務。通過BaaS平台可快捷管控聯盟鏈，確保鏈上業務穩定運行。
因此，隨著區塊鏈的廣泛應用，Baas服務的穩定性日趨關鍵，其中高可用部署就是重要環節。本文將從BaaS系統如何通過冗餘+自動故障轉移等機制，實現系統的高可用。
如何度量系統高可用？
在討論系統高可用性之前，有必要先搞清楚可用性的概念，顧名思義為系統的可用程度，因此可以採用系統無故障運營的時間佔總運營時間的百分比來衡量。若要以數學方式嚴謹定義，則需引入兩個統計指標：
平均無故障時間(Mean Time Between Failures, MTBF) ，即兩次故障之間正常運行的平均時間。 MTBF越大，表明越不容易出故障，可用性越高，該指標反映的是網絡的可靠性(reliability)。平均修復時間(Mean Time To Repair, MTTR)， 即出現故障後修復故障的平均時間。 MTTR越小，表明故障時間越短，可用性也越高，該指標反映的是網絡的容錯能力(fault-tolerant capability)。
有了這兩個指標，可用性可以如此計算：Availability = MTBF/(MTBF+MTTR)
直觀感受高可用指標等級
例如，一年365天中某系統出現5次故障，總故障時間為1小時，那麼如何計算該系統高可用性呢？
首先，計算1年中的可用時間，即總時間減去故障時間為: 365*24 – 1=8759個小時，接下來計算MTBF和MTTR：
◆平均無故障時間=總的可用時間除以故障次數：
MTBF = 8759/5 = 1751.8小時
◆平均修復時間=故障時間除以故障次數:
MTTR = 1/5 = 0.2 小時
最後，Availability = MTBF/(MTBF+MTTR) = 99.9886% 即這個系統的可用性為99.9886%，接近4個9的水平。
下表格揭示了n個9的可用性情況下，對應一年內中斷服務時間：
你會發現和主觀想像不一樣，99%的可用性其實效果並不理想，它意味著一年中系統有長達3.65天是不可用的。
如何提高系統可用性？
鑑於Availability = MTBF/(MTBF+MTTR) ，可以直觀感受到：提高MTBF，降低MTTR均可以提高系統可用性。本文以如何提高MTBF為核心，即避免系統發生故障，全面提升系統可用性。
針對BaaS系統而言，導致系統故障不可用的因素很多，大致可歸納為：
1）服務器硬件故障，如服務器宕機；
2）網絡線路故障，如挖斷網線；
3）存儲磁盤故障，如硬盤出現壞道，分區表損壞；
4）軟件服務故障，如並發量/用戶請求量大幅上漲導致整個服務宕掉或者部分服務不可用。
針對上述典型的硬件、網絡基礎設備、存儲磁盤、軟件服務的故障因素， BaaS系統架構設計時，如何從架構設計層面提升系統的可用性呢？
BaaS系統的分層架構
上圖概括性地剖析了BaaS系統分佈式架構的通用設計，考慮到BaaS系統涉及到對聯盟鏈部署、合約部署、監控、日誌等眾多領域服務模塊，趣鏈BaaS在設計中採用前後端分離，而後端服務選用微服務架構的設計方案。
按照用戶流量流入方向，自上而下劃分為：客戶端層->高可用反向代理層->Web前端服務->系統網管層->後端微服務層->存儲層。具體而言：
客戶端層: 典型的調用方是瀏覽器browser或者SDK lite Https； 高可用反向代理（LoadBalance）: 例如選用keepalive + haproxy組合的高可用反向代理，作為系統入口； Web應用：實現核心的頁面渲染邏輯； 微服務層：根據功能領域的不同進行服務化拆分部署，提供開發效率； 數據存儲層/緩存層：提供服務穩定可用的文件存儲以及緩存層加速服務性能； 數據庫層：提供高可用的關係型數據股票儲方案。
綜上，從基礎的硬件層到操作系統層、數據庫層、服務應用層、網絡層，都有可能產生單點故障，若要實現系統的高可用，就要有效消除系統每一層的單點故障，可以總結為通過每一層的冗餘+自動故障轉移來實現整個系統的高可用。
客戶端層->反向代理層
反向代理是位於Web 服務器前面的服務器，負責將客戶端（例如Web 瀏覽器）請求轉發至Web 服務器。通常用於幫助提高安全性、性能和可靠性，具體而言反向代理具有如下優勢：
負載均衡: 提供負載均衡解決方案，在不同服務器之間平均分配傳入流量，防止單個服務器過載，若某台服務器無法運行，則其他服務器可以代為處理。防範攻擊: 配置反向代理後，服務無需透漏其源服務器的IP地址，使得攻擊者更難對源服務器發起針對性攻擊。全局服務器負載平衡(GSLB)：此模式下，一個網站可以分佈在全球各地的多個服務器上，反向代理會將客戶端發送到地理位置上最接近它們的服務器，可減少請求和響應傳播的距離，最大程度減少加載時間。
一方面，在BaaS系統中引入反向代理層可帶來諸多好處，但另一方面在高可用場景下，反向代理層自身也會成為系統中的單點故障，為此需要為反向代理層設置高可用方案。實踐中，可考慮通過反向代理層的冗餘和故障自動轉移來實現，以haproxy為例：有兩台haproxy,一台提供反向代理服務，另一台通過冗餘方式保證高可用，常見的實踐是keepalived通過探測haproxy（Load balancer）服務的狀態以及配置同一個虛擬浮動IP（Floating IP），當其中Active haproxy(Load balancer)掛掉時，會被Keepalived探測到這一異常情況，隨後自動啟用故障轉移機制，將客戶端流量自動遷移至其他Passive haproxy(Load Balancer)。由於上述兩個haproxy選用的相同的對外Floating Vitual IP,因此這一過程用戶是無感知的。
Web服務->後端微服務
前端Web服務到後端微服務之間有一層反向代理層，負責將前端請求根據不同的路由規則路由到有效的後端服務地址。目前市面上通用的作為反向代理的組件有Nginx、Haproxy、Traefik等等。以Traefik為例，具有Http 動態更新路由、支持請求的粘性Session (sticky session)、接口的Healthcheck等眾多優良特性。實踐中，反向代理層可採用Traefik針對後端服務地址提供的Health Check機制，當任一Servers服務中的後端地址掛了後，會自動進行故障轉移，將流量請求遷移到其他的Servers 地址，整個過程由Traefik自動完成，對調用方是透明的。
微服務層->緩存層
微服務到緩存層的高可用，通過緩存數據的冗餘實現。經典的緩存層數據冗餘有以下兩種做法：
方案一：利用客戶端的封裝，Service對cache進行雙讀或者雙寫； 方案二：使用支持主從同步的緩存集群來解決緩存層高可用，以redis集群主從模式為例，當redis中的任意主master掛了之後，若該master節點有相應的slave節點存活，則自動將slave節點升級為master節點，保證redis緩存服務的高可用。
微服務層->存儲層
實踐中，BaaS平台存儲層的高可用方案可考慮選用NFS + Keepalive + Rsync的同步架構, 不同主機部署多個NFS-Server後端以及Keepalived，通過Keepalived的VIP地址對外提供統一的NFS服務Server地址，每個熱備組內同一時刻只有一台主服務器提供服務，其他服務器處於冗餘狀態，若主NFS服務宕機，其虛擬VIP地址會被其他備用NFS服務器接替(接替順序可按優先級排序)，實現高可用的NFS服務。
微服務層->數據庫層
由於大部分系統的數據庫層都採用了“主從同步，讀寫分離”架構，所以數據庫層的高可用，又分為“讀庫高可用”和“寫庫高可用”兩大類。
▲讀庫高可用
顧名思義，讀庫高可用可通過讀庫的冗餘實現。至少配置1個主庫，2個從庫，“數據庫連接礦池”會建立與這些讀庫的連接，每次請求最終會路由至這些讀數據庫中。當任意一個讀數據庫掛了之後，數據庫連接礦池會通過健康檢查探測到這一異常並自動進行故障轉移，流量便會自動遷移至其他讀庫，整個過程由數據庫連接礦池自動完成。
▲寫庫高可用
同理，寫庫高可用通過寫庫的冗餘來實現，以MySQL雙主同步模式為例，其中一台對外提供服務，另一台冗餘以保證高可用，一旦keepalived探測到主庫異常情況後會自動故障轉移，將流量遷移至另一台的db-master。
總結
本文以如何提高平均無故障時間(Mean Time Between Failures, MTBF)為核心，針對導致BaaS系統故障的硬件、網絡基礎設備和存儲磁盤等常見故障因素，分析了在BaaS架構設計中，如何針對性的對各層設計對應的“冗餘+自動故障轉移機制”，最大化避免系統發生故障，全面提升系統可用性。
實踐中，提升系統高可用任重而道遠，我們也會在未來的推文中持續介紹趣鏈BaaS如何在縮短平均修復時間(Mean Time To Repair, MTTR)等維度，進一步提升系統高可用。
資訊來源：由0x資訊編譯自8BTC。版權歸作者所有，未經許可，不得轉載