技術乾貨 阿里雲構建千萬級別架構演變之路

2021-09-23 19:21:32 字數 3368 閱讀 1359

前言

乙個好的架構是靠演變而來,而不是單純的靠設計。剛開始做架構設計,我們不可能全方位的考慮到架構的高效能、高擴充套件性、高安全等各方面的因素。隨著業務需求越來越多、業務訪問壓力越來越大,架構不斷的演變及進化,因而造就了乙個成熟穩定的大型架構。如**網、facebook等大型**的架構,無不從乙個小型規模架構,不斷進化及演變成為乙個大型**架構。

架構原始階段:萬能的單機

架構的最原始階段,即一台ecs伺服器搞定一切。傳統官網、論壇等應用,只需要一台ecs。對應的web伺服器、資料庫、靜態檔案資源等,部署到一台ecs上即可。一般5萬pv到30萬pv訪問量,結合核心引數調優、web應用效能引數調優、資料庫調優,基本上能夠穩定的執行。

架構採用單台ecs:

架構基礎階段:物理分離web和資料庫

當訪問壓力達到50萬pv到100萬pv的時候,部署在一台伺服器上面的web應用及資料庫等服務應用,會對伺服器的cpu/記憶體/磁碟/頻寬等系統資源進行競爭。顯然單機已經出現效能瓶頸。我們將web應用和資料庫物理分離單獨部署,解決對應效能問題。這裡的架構採用ecs+rds:

架構動靜分離階段:靜態快取 + 檔案儲存

當訪問壓力達到100萬pv到300萬pv的時候,我們看到前端web服務出現效能瓶頸。大量的web請求被堵塞,同時伺服器的cpu、磁碟io、頻寬都有壓力。這時候我們一方面將**、js、css、html及應用服務相關的檔案儲存在oss中,另外一方面通過cdn將靜態資源分布式快取在各個節點實現「就近訪問」。通過將動態請求、靜態請求的訪問分離(「動靜分離」),有效解決伺服器在磁碟io、頻寬方面的訪問壓力。

架構採用cdn + ecs + oss + rds:

架構分布式階段:負載均衡

當訪問壓力達到300萬pv到500萬pv的時候,雖然「動靜分離」有效分離了靜態請求的壓力,但是動態請求的壓力已經讓伺服器「吃不消」。最直觀的現象是,前端訪問堵塞、延遲、伺服器程序增多、cpu100%,並且出現常見502/503/504的錯誤碼。顯然單台web伺服器已經滿足不了需求,這裡需要通過負載均衡技術增加多台web伺服器(對應ecs可以選擇不同可用區,進一步保障高可用)。因而告別單機的時代,轉變分布式架構的階段。

架構採用cdn+slb + ecs + oss + rds:

架構資料快取階段:資料庫快取

當訪問壓力達到500萬pv到1000萬pv,雖然負載均衡結合多台web伺服器,解決了動態請求的效能壓力。但是這時候我們發現,資料庫出現壓力瓶頸,常見的現象就是rds的連線數增加並且堵塞、cpu100%、iops飆公升。這個時候我們通過資料庫快取,有效減少資料庫訪問壓力,進一步提公升效能。

架構採用cdn+slb +ecs +oss + 雲資料庫memcache +rds :

架構擴充套件階段:垂直擴充套件

當訪問量達到1000萬pv到5000萬pv,雖然這個時候我們可以看到通過分布式檔案系統oss已經解決了檔案儲存的效能問題,cdn也已經解決靜態資源訪問的效能問題。但是當訪問壓力再次增加,這個時候web伺服器和資料庫方面依舊是瓶頸。在此我們通過垂直擴充套件,進一步切分web伺服器和資料庫的壓力,解決效能問題。

「何為垂直擴充套件,按照不同的業務(或者資料庫)切分到不同的伺服器(或者資料庫)之上,這種切分稱之為垂直擴充套件。」

垂直擴充套件第一招:業務拆分

在業務層,可以把不同的功能模組拆分到不同的伺服器上面進行單獨部署。比如,使用者模組、訂單模組、商品模組等,拆分到不同伺服器上面部署。

垂直擴充套件第二招:讀寫分離

在資料庫層,當結合資料庫快取,資料庫壓力還是很大的時候。我們通過讀寫分離的方式,進一步切分及降低資料庫的壓力。

垂直擴充套件第三招:分庫

結合業務拆分、讀寫分離,在資料庫層,比如我們同樣可以把使用者模組、訂單模組、商品模組等。所涉及的資料庫表:使用者模組表、訂單模組表、商品模組表等,分別存放到不同資料庫中,如使用者模組庫、訂單模組庫、商品模組庫等。然後把不同資料庫分別部署到不同伺服器中。

架構採用cdn+slb +ecs +oss+ 雲資料庫memcache + rds讀寫分離:

架構分布式+大資料階段:水平擴充套件

當訪問量達到5000萬pv及以上時,真達到千萬級架構以上訪問量的時候,我們可以看到垂直擴充套件的架構也已經開始「山窮水盡」。比如,讀寫分離僅解決「讀」的壓力,面對高訪問量,在資料庫「寫」的壓力上面「力不從心」,出現效能瓶頸。另外,分庫雖然將壓力拆分到不同資料庫中。但單錶的資料量達到tb級別以上,顯然已經達到傳統關係型資料庫處理的極限。

通過業務垂直拆分部署在不同伺服器後,當後續壓力進一步增大,增加更多的webserver進行水平擴充套件。

單台slb也存在單點故障的風險,即slb也存在效能極限,如qps最大值為50000。通過dns輪詢,將請求輪詢**至不同可用區的slb上面,實現slb水平擴充套件。

水平擴充套件第三招:採用分布式快取

雖然阿里雲memcache記憶體資料庫已經是分布式結構,但是同樣單一的入口也存在單點故障的風險可能。並且也存在效能極限,如最大吞吐量峰值為512mbps。所以我們部署多台雲資料庫memcache版,可以在**層通過hash演算法將資料分別快取至不同的雲資料庫memcache版中。

水平擴充套件第四招:sharding + nosql

面對高併發、大資料的需求,傳統的關係型資料庫已不再適合。需要採用drds(mysql sharding分布式解決方案) + ots(基於列儲存的分布式資料庫)對應的分布式資料庫來根本性的解決問題。

架構採用cdn+dns輪詢 + slb + ecs + oss + 雲資料庫memcache + drds+ots:

技術乾貨 阿里雲構建千萬級別架構演變之路

乙個好的架構是靠演變而來,而不是單純的靠設計。剛開始做架構設計,我們不可能全方位的考慮到架構的高效能 高擴充套件性 高安全等各方面的因素。隨著業務需求越來越多 業務訪問壓力越來越大,架構不斷的演變及進化,因而造就了乙個成熟穩定的大型架構。如 網 facebook等大型 的架構,無不從乙個小型規模架構...

阿里雲構建千萬級架構演變之路

2017 11 07 乙個好的架構是靠演變而來,而不是單純的靠設計。剛開始做架構設計,我們不可能全方位的考慮到架構的高效能 高擴充套件性 高安全等各方面的因素。隨著業務需求越來越多 業務訪問壓力越來越大,架構不斷的演變及進化,因而造就了乙個成熟穩定的大型架構。如 網 facebook等大型 的架構,...

阿里雲飛天系統的技術架構

阿里雲飛天系統的技術架構 阿里雲有以下五大優勢 中國萬網,提供虛擬主機託管的服務,而且還提供網域名稱等服務,其客戶群非常龐大 阿里巴巴 內部稱 b2b 支付寶等其他子公司有大量的資料分析業務,需要消耗大量的伺服器資源,電力,機房設施 阿里巴巴集團已經購買了多條大頻寬的專線,並且形成多網互聯和加速的能...