開篇概述
在如今移動網際網路、網際網路+、大資料的時代，各類的網際網路網站、平臺異常突起，如同雨後春筍，有種“忽如一夜春風來，千樹萬樹梨花開”感覺。 對於移動網際網路時代的平臺來說，使用者的體驗感是否良好？平臺的穩定性是否良好？估計是對所有網際網路平臺來說兩大頭等要素吧，的確，移動網際網路時代，流量就是市場價值，說白了就是收益，就是RMB，失去了流量，那麼你也就失去了賺取收益的機會與機遇。
因此，對於互聯平臺或網站來說，網站的高可用、不間斷服務也是平臺運營過程中的一個重大決定因素，比如說某平臺，三天兩頭的故障，打不開，又或者說，經常性的出現錯誤、訪問超時等等問題，那麼使用者的流失機率就會隨之增加。 那麼今天我們就來聊一聊各類高可用架構的一個演變過程到底是如何的？此文民工哥用時三小時總結寫作完成，希望對大家有所幫助，歡迎大家拍磚、留言、點贊、轉發分享以支援。
什麼是高可用？
“高可用性”（High Availability）通常來描述一個系統經過專門的設計，從而減少停工時間，而保持其服務的高度可用性。簡而言之，就是不間斷對外提供服務。
架構之初
架構圖
架構簡述
這類架構比較適用於初創企業或流量較小的平臺。 此種架構一般都是在平臺執行之初所用到的架構，日均PV不大，簡單的架構足以能夠應對使用者的流量請求，比如前端網站使用Apache/nginx都可以，APP伺服器直接使用JAVA環境如tomcat應用，網際網路平臺的資料庫大部分使用Mysql，備份伺服器一般都備份一些常用的配置、程式碼、資料庫資料的備份檔案等。因此，民工哥稱它為架構之初。
架構中期
隨著使用者數量的增長、訪問量的增加，隨之而來的問題就是單臺伺服器已無法承受使用者的訪問流量，因此前期的基礎架構就需要面臨一定的調整，大概調整如下
架構圖
架構簡述
這類架構就此引入了負載均衡的概念，關於應用的負載均衡，前面也有相關的文章介紹，具體文章連結如下 nginx負載均衡與反向代理 Nginx+Tomcat多例項及負載均衡配置
負載均衡的開源軟體較多，通常會有以下兩種方式
- 硬體負載——F5 7層或者4層網路代理
- 軟體負載——nginx、haproxy開源負載均衡軟體
負載均衡的演算法通常有：
- 輪詢法
- 隨機法
- 源地址雜湊法
- 加權輪詢法
- 加權隨機法
- 最小連線數法
具體使用何種方式，一切以企業實際需求、投入與產出比（成本考慮）為主，但是此類架構也有一定的缺點存在，暫時不考慮前端負載裝置的高可用，比如使用者的上傳與檢視檔案問題（通過A服務訪問上傳，然後負載檢視時是通B伺服器的，就會造成使用者無法檢視的問題），APP伺服器同理；資料庫伺服器存在主、從庫單點問題，一旦故障，可以手工進行故障切換，但是可能會造成資料丟失或不統一，並且會在一定程度上給使用者造成不好的體驗；因此仍需演變。
架構圖
架構簡述
此架構在上面的架構基礎，以應對各類問題做出的修改，增加了資料儲存伺服器（NFS共享儲存Linux系統NFS網路檔案系統），對於儲存架構及源件，其實挺多的，具體有以下幾種開源軟體服務
- 1、NFS網路共享儲存檔案系統
- 2、FastDFS 輕量級網路檔案系統(參考文章：分散式檔案系統FastDFS詳解)
- 3、分散式檔案系統MooseFS
- 4、GlusterFS檔案系統
並配置負載均衡、並且還解決了單點故障的問題，對於資料庫伺服器做出了一定的架構調整，為雙主多從的架構，對於資料庫的各種高可用架構，前面也有文章做過分析，具體如： 淺談MySQL叢集高可用架構
但是所有架構都是要以實際需求（如對資料完整性、一致性的要求為主），從而解決主庫單點問題、從庫讀取量大的效能問題，保證在一定量用訪問時的平臺效能與高可用
架構終期
架構圖
架構簡述
架構演變到一定程度，僅通過平行的擴充套件或增加伺服器數量可能已無法解決相關的效能問題，因此
第一，在使用者訪問初始階段就會使用CDN加速技術，來提高使用者的訪問體驗度；
第二，按照業務來拆分成不同的服務，通過拆分服務、相同服務佈署多個例項的架構來達到擴充套件的目的，來提高一定的效能，也能保證平臺的高可用性；服務拆分後，也能一定限度的解決釋出問題，因為服務之間彼此獨立，服務之間耦合性不強，也比較方便平時的維護；
第三，對於使用者與資料庫之間的瓶頸問題，考慮加上快取技術來提高一定的訪問效能與高可用性，讓使用者的訪問流量在到達資料庫之前直接過濾掉一部分，甚至一大半，從而減輕資料庫訪問壓力，在查多寫少的場景，非常適用使用快取來提升查詢服務的效能，減輕對資料庫的壓力。通常使用redis作為快取伺服器，redis的一些叢集機制能很大程度上保證快取服務的高可用性（Redis叢集生產環境高可用方案實戰過程），快取服務故障時，還能從資料庫獲取資訊。然後對於備份伺服器也簡單的做調整保證資料的完整性，一方面也能及時保障應用的高可用性；其實一些大型分散式的系統在快取這塊還是比較傾向於memcached服務（Linux系統Memcached服務介紹），比如像一些使用者的登入資訊同步到其它系統此種場景，一般佈署在前臺應用層與資料儲存層中間，應對前端應用大量請求與快速響應，從而減少資料庫的訪問壓力，也能提高使用者的訪問體驗度。
也有一部分平臺架構是採用分層的方式
前端應用層：
-
給使用者提供頁面展示、查詢、搜尋的介面及相關的最終結果顯示頁面 複製程式碼
後端服務層：
-
一般包括像常用的後臺服務、使用者管理、介面管理、支付管理等，都是給前端應用提提供服務的 複製程式碼
** 資料儲存層：**
-
這個就很容易理解，像資料庫、檔案系統、快取等一系列提供資料訪問與儲存的 複製程式碼
所以因此也有下面的這類架構產生
最終總結
高可用、高效能只能說是一個階段、一個時期的，**沒有完美的架構，只有不斷演變、不斷完善的架構。**因此，今天所說的高效能、高可用架構，可能不盡完美，但歸根結底總結成一句話：“讓使用者的訪問流量儘量靠前，一步步分層去過濾使用者流量，快速響應使用者的請求，從而達到比較好的使用者體驗”。
民工哥所發文章，如無其它說明均為原創作品，轉載需註明原處、作者資訊。