web server介面是什麼
前言
在《一圖讀懂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)等維度，進一步提升系統高可用。