在如今移動互聯網、互聯網+、大數據的時代，各類的互聯網網站、平臺異常突起，如同雨後春筍，有種“忽如一夜春風來，千樹萬樹梨花開”感覺。
對於移動互聯網時代的平臺來說，用戶的體驗感是否良好？平臺的穩定性是否良好？估計是對所有互聯網平臺來說兩大頭等要素吧，的確，移動互聯網時代，流量就是市場價值，說白了就是收益，就是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集群高可用架構

MySQL集群高可用架構之MHA

但是所有架構都是要以實際需求（如對數據完整性、一致性的要求為主），從而解決主庫單點問題、從庫讀取量大的性能問題，保證在一定量用訪問時的平臺性能與高可用

架構終期

架構圖

架構簡述

架構演變到一定程度，僅通過平行的擴展或增加服務器數量可能已無法解決相關的性能問題，因此

第一，在用戶訪問初始階段就會使用CDN加速技術，來提高用戶的訪問體驗度；

第二，按照業務來拆分成不同的服務，通過拆分服務、相同服務布署多個實例的架構來達到擴展的目的，來提高一定的性能，也能保證平臺的高可用性；服務拆分後，也能一定限度的解決發布問題，因為服務之間彼此獨立，服務之間耦合性不強，也比較方便平時的維護；

第三，對於用戶與數據庫之間的瓶頸問題，考慮加上緩存技術來提高一定的訪問性能與高可用性，讓用戶的訪問流量在到達數據庫之前直接過濾掉一部分，甚至一大半，從而減輕數據庫訪問壓力，在查多寫少的場景，非常適用使用緩存來提升查詢服務的性能，減輕對數據庫的壓力。通常使用redis作為緩存服務器，redis的一些集群機制能很大程度上保證緩存服務的高可用性（Redis集群生產環境高可用方案實戰過程），緩存服務故障時，還能從數據庫獲取信息。然後對於備份服務器也簡單的做調整保證數據的完整性，一方面也能及時保障應用的高可用性；其實一些大型分布式的系統在緩存這塊還是比較傾向於memcached服務（Linux系統Memcached服務介紹），比如像一些用戶的登錄信息同步到其它系統此種場景，一般布署在前臺應用層與數據存儲層中間，應對前端應用大量請求與快速響應，從而減少數據庫的訪問壓力，也能提高用戶的訪問體驗度。

也有一部分平臺架構是采用分層的方式

前端應用層：

• 給用戶提供頁面展示、查找、搜索的界面及相關的最終結果顯示頁面
  後端服務層：
• 一般包括像常用的後臺服務、用戶管理、接口管理、支付管理等，都是給前端應用提提供服務的
  數據存儲層：
• 這個就很容易理解，像數據庫、文件系統、緩存等一系列提供數據訪問與存儲的

所以因此也有下面的這類架構產生

最終總結

高可用、高性能只能說是一個階段、一個時期的，沒有完美的架構，只有不斷演變、不斷完善的架構。因此，今天所說的高性能、高可用架構，可能不盡完美，但歸根結底總結成一句話：“讓用戶的訪問流量盡量靠前，一步步分層去過濾用戶流量，快速響應用戶的請求，從而達到比較好的用戶體驗”。

高性能、高可用平臺架構演變史