閱讀955 返回首頁    go windows


技術幹貨:阿裏雲構建千萬級架構演變之路

本文作者:喬銳傑,現擔任上海駐雲信息科技有限公司運維總監/架構師。曾任職過黑客講師、java軟件工程師/網站架構師、高級運維、阿裏雲架構師等職位。維護過上千台服務器,主導過眾安保險、新華社等千萬級上雲架構。在雲端運維、分布式集群架構等方麵有著豐富的經驗。

前言

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

隨著雲計算的到來,當前已經從IT時代向DT時代開始轉型。在雲端如何構建千萬級架構,本文主要結合阿裏雲最佳實踐經驗,向大家分享如何從一個小型網站逐步演變到千萬級架構的過程。

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

架構的最原始階段,即一台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級別以上,顯然已經達到傳統關係型數據庫處理的極限。

水平擴展第一招:增加更多的web服務器

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

水平擴展第二招:增加更多的SLB

單台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:

杜絕抄襲,支持開源,我為自己呐喊,百分百原創作者:喬銳傑

好啦~本文到這裏就結束了,同時,如果喜歡我們的話就趕緊訂閱我們吧~~~每天定時推送新鮮幹貨~~~也可以關注我們的微信公眾號:架構雲專家頻道每天同步更新喲~

最後更新:2017-10-08 04:10:28

  上一篇:go 阿裏雲手機係統能否挑戰安卓和蘋果操作係統?
  下一篇:go 華為雲和運營商、阿裏雲必有一戰?