單點系統架構可用性與性能優化

1. 緣起

單點master的設計會大大簡化系統設計，況且有時候避免不了單點。

先看一個典型互聯網高可用架構：

（1）客戶端層：是瀏覽器或App，第一步先訪問DNS-server，由域名拿到nginx的外網IP；

（2）負載均衡層：nginx是整個服務端的入口，負責反向代理與負責均衡工做；

（3）站點層：web-server層，典型的是tomcat或apache；

（4）服務層：service層，典型的是dubbo或thrift等提供RPC調用的後端服務；

（5）數據層：包含cache和db，典型的是主從複製讀寫分離的db架構。

在這個互聯網架構中，站點層、服務層、數據庫的從庫均可以經過冗餘的方式來保證高可用，但至少：

（1）nginx層是一個潛在的單點

（2）數據庫寫庫master也是一個潛在的單點

2. 單點架構存在的問題

單點系統通常來講存在兩個很大的問題：

（1）非高可用：既然是單點，master一旦發生故障，服務就會收到影響；

（2）性能瓶頸：既然是單點，不具有良好的擴展性，服務性能總有一個上線，這個單點的性能上限每每就是整個系統的性能上限。

3. 解決單點高可用

3.1 shadow-master

shadow-master（影子master）是一種很常見的解決單點高可用問題的技術方案。

shadow-master：顧名思義，服務正常時，它只是單點master的一個影子，在master出現故障時，shadow-master會自動變成master，繼續提供服務。

shadow-master它可以解決高可用的問題，而且故障的轉移是自動的，不須要人工介入，但不足是它使服務資源的利用率降爲50%，業內常用keepalived+vip的方式實現這類單點的高可用。

 

（1）client會鏈接正常的master，shadow-master不對外提供服務；

（2）master與shadow-master之間有一種存活探測機制；

（3）master與shadow-master有相同的虛IP（virtual-IP）；

當發現master異常時：

shadow-master會自動頂上成爲master，虛IP機制能夠保證這個過程對調用方是透明的。

nginx與數據庫的主庫master可用相似的方式來保證高可用，只是細節上有些地方要注意。

傳統的一主多從，讀寫分離的db架構，只能保證讀庫的高可用，是沒法保證寫庫的高可用的，要想保證寫庫的高可用，也可使用上述的shadow-master機制。

（1）兩個主庫設置相互同步的雙主模式；

（2）平時只有一個主庫提供服務，言下之意，shadow-master不會往master同步數據；

（3）異常時，虛IP漂移到另外一個主庫，shadow-master變成主庫繼續提供服務。

須要說明的是，因爲數據庫的特殊性，數據同步須要時延，若是數據尚未完成同步，流量就切到了shadow-master，可能引發小部分數據的不一致。

3.2 減小與點點的交互，是存在單點的系統優化的核心方向

既然知道單點存在性能上限，單點的性能有可能成爲系統的瓶頸，那麼，減小與單點的交互，便成了存在單點的系統優化的核心方向。

怎麼減小與單點的交互，提供兩個常見的方法：

3.2.1 批量寫

批量寫是一種常見的提高單點性能的方式。參考https://www.cnblogs.com/lujiango/p/9376796.html#_label7

3.2.2 客戶端緩存

客戶端緩存也是一種下降與單點交互次數，提高系統總體性能的方法。

3.3 水平擴展時提高單點系統性能的好方案

不管怎麼批量寫，客戶端緩存，單點畢竟是單機，仍是有性能上限的。

千方百計水平擴展，消除系統單點，理論上纔可以無限的提高系統性能。

以nginx爲例，若是來進行水平擴展？

第一步的DNS解析，只能返回一個nginx外網IP麼？No，DNS輪詢即時支持DNS-server返回不一樣的nginx外網IP，這樣就能實現nginx負載均衡層的水平擴展。

DNS-server部分，一個域名能夠配置多個IP，每次DNS解析請求，輪詢返回不一樣的IP，就能實現nginx的水平擴展，擴展負載均衡曾的總體性能。

數據庫單點寫庫也是一樣的道理，在數據量很大的狀況下，能夠經過水平拆分，來提高寫入性能。

可是，並非全部的業務場景均可以水平拆分。

4. 總結

（1）單點系統存在的問題：可用性問題，性能瓶頸問題；

（2）shadow-master是一種常見的解決單點系統可用性的問題的方案；

（3）減小與單點的交互，是存在單點的系統優化的核心方向，常見方法是：批量寫，客戶端緩存；

（4）水平也是提高單點系統性的好方案。