消除單點，一篇搞定 | 架構設計篇

系統架構中，爲何會存在單點？

(1)存在設計缺陷，出現了單點；
(2)能大大簡化系統設計，有意爲之，設置單點；

典型互聯網高可用架構，哪些地方可能存在潛在單點？

典型互聯網高可用架構：
(1)端，經過DNS，由域名拿到nginx的外網IP；
(2)反向代理，nginx是後端入口；
(3)站點應用，典型的是tomcat或者apache；
(4)服務，典型的是dubbo提供RPC服務調用；
(5)數據層，典型的是讀寫分離的db架構；

在這個互聯網架構中，站點、服務、數據庫的從庫都容易經過冗餘的方式來保證高可用，但：
(1)nginx是一個潛在的單點；
(2)數據庫寫庫也是一個潛在的單點；

哪些例子，由於設計須要，有意設置的單點？

先看GFS（Google File System）架構的例子：

GFS的系統架構裏主要有這麼幾種角色：
(1)client，就是發起文件讀寫的調用端；
(2)master，這是一個單點服務，它有全局視野，掌握文件元信息；
(3)chunk-server，實際存儲文件的服務器；

在GFS系統裏，master是一個單點服務。

Map-reduce系統裏也有相似的角色，協調全局的master就是單點，它的存在，可以大大的簡化系統架構設計。

不論是設計缺陷，仍是有意爲之，像nginx，db-master，GFS-master這樣的單點服務，會存在什麼問題呢？

兩個大問題：
(1)高可用問題：單點一旦發生故障，服務就會受到影響；
(2)性能瓶頸：單點不具有良好的擴展性，單點的性能上限每每就是整個系統的性能上限；

「高可用」問題一般怎麼優化？

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

shadow-master，顧名思義，它只是單點master的一個shadow(影子)：
(1)master工做時，shadow-master只備份；
(2)master出現故障時，shadow-master會自動變成master，繼續提供服務；

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

以GFS的master爲例，master正常時：
(1)client會鏈接正常的master，shadow-master不對外提供服務；
(2)master與shadow-master之間有一種存活探測機制；
(3)master與shadow-master有相同的虛IP；

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

除了GFS與MapReduce系統中的主控master，nginx和數據庫的主庫master亦可用相似的方式來保證高可用：

(1)兩個主庫設置相互同步的雙主模式；
(2)平時只有一個主庫提供服務；
(3)異常時，虛IP漂移到另外一個主庫，shadow-master變成主庫繼續提供服務；

關於高可用，更多詳細的內容，可參考《究竟啥纔是互聯網架構「高可用」》。

「性能瓶頸」問題一般怎麼優化？

有時候，單點設計是有意爲之，此時單點的性能（例如GFS中的master）有可能成爲系統的瓶頸，那麼，減小與單點的交互，便成了存在單點的系統優化的核心方向。

如何來減小與單點的交互，有兩種常見的方法：
(1)批量寫；
(2)客戶端緩存；

如何利用「批量寫」減小與單點的交互，提高總體性能？

舉一個單點「ID生成器」的例子，不少公司會利用數據庫的auto-inc-id，來做爲一個嚴格遞增的ID生成工具。

其交互流程是：
(1)調用方須要ID；
(2)插入記錄，利用auto-inc-id來生成和返回ID；

此時，ID生成的併發上限，取決於單點數據庫的插入性能上限。

如何利用「批量寫」提高性能呢？

優化以下：
(1)增長一個服務，每次從DB拿出100個id；
(2)調用方須要ID；
(3)服務直接返回100個id中的1個，100個分配完，再訪問DB；

這樣一來，每分配100個纔會寫數據庫一次，分配id的性能提高了100倍。

如何利用「客戶端緩存」減小與單點的交互，提高總體性能？

仍是舉GFS文件系統的栗子。

GFS文件讀取的流程以下：
(1)GFS的調用客戶端client要訪問shenjian.txt，先查詢本地緩存，miss了；
(2)client訪問master問說文件在哪裏，master告訴client在chunk3上；
(3)client把shenjian.txt存放在chunk3上記錄到本地的緩存，而後進行文件的讀寫操做；
(4)將來client要訪問文件，從本地緩存中查找到對應的記錄，就不用再請求master了，能夠直接訪問chunk-server；

這類緩存的命中很是很是高，在99%以上（由於文件的自動遷移是小几率事件），這樣與master的交互次數就下降了100倍。

批量寫，客戶端緩存，對性能的提高也有極限，單點性能優化還有沒有其餘方法？

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

水平擴展，纔可以無限的提高系統性能。

以nginx爲例，如何來進行水平擴展呢？

第一步的DNS解析，只能返回一個nginx外網IP麼？

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

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

關於性能擴展，更多詳細的內容，可參考《究竟啥纔是互聯網架構「可擴展」》。

總結

今天的內容不少，但願行文有邏輯：
(1)單點系統存在的問題：可用性問題，性能瓶頸問題；
(2)shadow-master是一種常見高可用方案；
(3)減小與單點的交互，是單點系統優化的核心方向，常見方法有：批量寫，客戶端緩存；
(4)水平擴展，才能作到理論上的無限性能；

思路比結論重要。

架構師之路-分享可落地的技術文章

推薦閱讀：《究竟啥纔是互聯網架構「一致性」》《究竟啥纔是互聯網架構「高可用」》《究竟啥纔是互聯網架構「可擴展」》