簡介： 系統架構中，爲什麼會存在單點？思路比結論重要。
系統架構中，爲什麼會存在單點？
(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生成的併發上限，取決於單點數據庫的插入性能上限。
那麼如何利用“批量寫”提升性能呢？
想看完整文章內容：點擊這裏
原文出處：阿里雲大學開發者社區