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

開篇概述

在現在移動互聯網、互聯網+、大數據的時代，各種的互聯網網站、平臺異常突起，如同雨後春筍，有種「忽如一晚上春風來，千樹萬樹梨花開」感受。
對於移動互聯網時代的平臺來講，用戶的體驗感是否良好？平臺的穩定性是否良好？估計是對全部互聯網平臺來講兩大頭等要素吧，的確，移動互聯網時代，流量就是市場價值，說白了就是收益，就是RMB，失去了流量，那麼你也就失去了賺取收益的機會與機遇。

所以，對於互聯平臺或網站來講，網站的高可用、不間斷服務也是平臺運營過程當中的一個重大決定因素，好比說某平臺，三天兩頭的故障，打不開，又或者說，常常性的出現錯誤、訪問超時等等問題，那麼用戶的流失機率就會隨之增長。
那麼今天咱們就來聊一聊各種高可用架構的一個演變過程究竟是如何的？此文民工哥用時三小時總結寫做完成，但願對你們有所幫助，歡迎你們拍磚、留言、點贊、轉發分享以支持。

什麼是高可用？

「高可用性」（High Availability）一般來描述一個系統通過專門的設計，從而減小停工時間，而保持其服務的高度可用性。簡而言之，就是不間斷對外提供服務。

架構之初

架構圖

架構簡述

這類架構比較適用於初創企業或流量較小的平臺。
此種架構通常都是在平臺運行之初所用到的架構，日均PV不大，簡單的架構足以可以應對用戶的流量請求，好比前端網站使用Apache/nginx均可以，APP服務器直接使用JAVA環境如tomcat應用，互聯網平臺的數據庫大部分使用Mysql，備份服務器通常都備份一些經常使用的配置、代碼、數據庫數據的備份文件等。所以，民工哥稱它爲架構之初。

架構中期

隨着用戶數量的增加、訪問量的增長，隨之而來的問題就是單臺服務器已沒法承受用戶的訪問流量，所以前期的基礎架構就須要面臨必定的調整，大概調整以下

架構圖

架構簡述

這類架構就此引入了負載均衡的概念，關於應用的負載均衡，前面也有相關的文章介紹，具體文章連接以下
nginx負載均衡與反向代理
Nginx+Tomcat多實例及負載均衡配置

負載均衡的開源軟件較多，一般會有如下兩種方式

• 硬件負載——F5 7層或者4層網絡代理
• 軟件負載——nginx、haproxy開源負載均衡軟件

負載均衡的算法一般有：

• 輪詢法
• 隨機法
• 源地址哈希法
• 加權輪詢法
• 加權隨機法
• 最小鏈接數法

具體使用何種方式，一切以企業實際需求、投入與產出比（成本考慮）爲主，可是此類架構也有必定的缺點存在，暫時不考慮前端負載設備的高可用，好比用戶的上傳與查看文件問題（經過A服務訪問上傳，而後負載查看時是通B服務器的，就會形成用戶沒法查看的問題），APP服務器同理；數據庫服務器存在主、從庫單點問題，一旦故障，能夠手工進行故障切換，可是可能會形成數據丟失或不統一，而且會在必定程度上給用戶形成很差的體驗；所以仍需演變。

架構圖

架構簡述

此架構在上面的架構基礎，以應對各種問題作出的修改，增長了數據存儲服務器（NFS共享存儲Linux系統NFS網絡文件系統），對於存儲架構及源件，其實挺多的，具體有如下幾種開源軟件服務

• 一、NFS網絡共享存儲文件系統
• 二、FastDFS 輕量級網絡文件系統(參考文章：分佈式文件系統FastDFS詳解)
• 三、分佈式文件系統MooseFS
• 四、GlusterFS文件系統

並配置負載均衡、而且還解決了單點故障的問題，對於數據庫服務器作出了必定的架構調整，爲雙主多從的架構，對於數據庫的各類高可用架構，前面也有文章作過度析，具體如：
淺談MySQL集羣高可用架構

MySQL集羣高可用架構之MHA

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

架構終期

架構圖

架構簡述

架構演變到必定程度，僅經過平行的擴展或增長服務器數量可能已沒法解決相關的性能問題，所以

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

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

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

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

前端應用層：

• 給用戶提供頁面展現、查找、搜索的界面及相關的最終結果顯示頁面

  後端服務層：

• 通常包括像經常使用的後臺服務、用戶管理、接口管理、支付管理等，都是給前端應用提提供服務的

  ** 數據存儲層：**

• 這個就很容易理解，像數據庫、文件系統、緩存等一系列提供數據訪問與存儲的

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

最終總結

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

@版權屬於做者，來自民工哥原創做品，如需轉載，請註明出處及做者信息。