當前位置:
首頁 > 最新 > 高性能、高可用平台架構的演變過程

高性能、高可用平台架構的演變過程

開篇概述

在如今移動互聯網、互聯網+、大數據的時代,各類的互聯網網站、平台異常突起,如同雨後春筍,有種「忽如一夜春風來,千樹萬樹梨花開」感覺。

對於移動互聯網時代的平台來說,用戶的體驗感是否良好?平台的穩定性是否良好?估計是對所有互聯網平台來說兩大頭等要素吧,的確,移動互聯網時代,流量就是市場價值,說白了就是收益,就是RMB,失去了流量,那麼你也就失去了賺取收益的機會與機遇。

因此,對於互聯平台或網站來說,網站的高可用、不間斷服務也是平台運營過程中的一個重大決定因素,比如說某平台,三天兩頭的故障,打不開,又或者說,經常性的出現錯誤、訪問超時等等問題,那麼用戶的流失機率就會隨之增加。

那麼今天我們就來聊一聊各類高可用架構的一個演變過程到底是如何的?此文民工哥用時三小時總結寫作完成,希望對大家有所幫助,歡迎大家拍磚、留言、點贊、轉發分享以支持。

什麼是高可用?

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

架構之初

架構圖

架構簡述

這類架構比較適用於初創企業或流量較小的平台

此種架構一般都是在平台運行之初所用到的架構,日均PV不大,簡單的架構足以能夠應對用戶的流量請求,比如前端網站使用Apache/nginx都可以,APP伺服器直接使用JAVA環境如tomcat應用,互聯網平台的資料庫大部分使用Mysql,備份伺服器一般都備份一些常用的配置、代碼、資料庫數據的備份文件等。因此,民工哥稱它為架構之初。

架構中期

隨著用戶數量的增長、訪問量的增加,隨之而來的問題就是單台伺服器已無法承受用戶的訪問流量,因此前期的基礎架構就需要面臨一定的調整,大概調整如下

架構圖

架構簡述

這類架構就此引入了負載均衡的概念,關於應用的負載均衡,前面也有相關的文章介紹,具體文章鏈接如下

負載均衡的開源軟體較多,通常會有以下兩種方式

硬體負載——F5 7層或者4層網路代理

軟體負載——nginx、haproxy開源負載均衡軟體

負載均衡的演算法通常有:

輪詢法

隨機法

源地址哈希法

加權輪詢法

加權隨機法

最小連接數法

具體使用何種方式,一切以企業實際需求、投入與產出比(成本考慮)為主,但是此類架構也有一定的缺點存在,暫時不考慮前端負載設備的高可用,比如用戶的上傳與查看文件問題(通過A服務訪問上傳,然後負載查看時是通B伺服器的,就會造成用戶無法查看的問題),APP伺服器同理;資料庫伺服器存在主、從庫單點問題,一旦故障,可以手工進行故障切換,但是可能會造成數據丟失或不統一,並且會在一定程度上給用戶造成不好的體驗;因此仍需演變。

架構圖

架構簡述

此架構在上面的架構基礎,以應對各類問題做出的修改,增加了數據存儲伺服器(NFS共享存儲Linux系統NFS網路文件系統),對於存儲架構及源件,其實挺多的,具體有以下幾種開源軟體服務

1、NFS網路共享存儲文件系統

2、FastDFS 輕量級網路文件系統(參考文章:分散式文件系統FastDFS詳解)

3、分散式文件系統MooseFS

4、GlusterFS文件系統

並配置負載均衡、並且還解決了單點故障的問題,對於資料庫伺服器做出了一定的架構調整,為雙主多從的架構,對於資料庫的各種高可用架構,前面也有文章做過分析,具體如:

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

架構終期

架構圖

架構簡述

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

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

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

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

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

前端應用層:

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

後端服務層:

一般包括像常用的後台服務、用戶管理、介面管理、支付管理等,都是給前端應用提提供服務的

數據存儲層:

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

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

最終總結

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


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 民工哥Linux運維 的精彩文章:

TAG:民工哥Linux運維 |