-
1 # 無敵碼農
-
2 # 雲計算那些事兒
一個好的架構是靠演變而來,而不是單純的靠設計。剛開始做架構設計,我們不可能全方位的考慮到架構的高效能、高擴充套件性、高安全等各方面的因素。隨著業務需求越來越多、業務訪問壓力越來越大,架構不斷的演變及進化,因而造就了一個成熟穩定的大型架構。如淘寶網、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:
-
3 # 青蓮網路雲服務
當今技術的發展日新月異,系統架構也跟隨技術的發展不斷升級和改進,從傳統的單一架構演變為如今的微服務分散式架構,我們來看看技術架構的演變過程。
NO.1 初期網站架構網站建設初期,訪問人數有限,資料量不大,只需要一臺伺服器足矣,這時應用程式、檔案、資料庫等所有資源全部集中在這臺伺服器上,網站架構請看下圖:
NO.2 應用和資料分離
隨著網站業務的不斷髮展,一臺伺服器已經不能滿足要求,使用者訪問量越來越大,資料量也越來越大,此時對網站的要求也逐漸變大,這就需要將應用和資料分離,變成應用伺服器、檔案伺服器和資料庫伺服器。架構圖如下:
NO.3 快取資料以改善網站效能
隨著使用者逐漸的不斷增加,資料庫訪問壓力變大,導致訪問延遲,效能較低,這時就需要快取技術,將查詢較多或者改動不大的資料快取起來,以加快應用訪問速度,下面是基本的架構圖:
NO.4 應用叢集
在網站訪問高峰,併發量大的情況下,應用伺服器就成為了整個網站的瓶頸,單一的應用伺服器資源有限,高併發情況下連線很快就會超限,這時,我們就需要部署應用伺服器叢集,利用負載均衡器分散訪問流量,減少單臺伺服器的壓力,網站架構圖如下:
NO.5 資料庫讀寫分離
這個階段,資料繼續增加,請求數量繼續加大,單個數據庫已然不能滿足要求,這個時候需要部署多個數據庫進行讀寫分離,請看架構圖:
NO.6 部署 CDN 節點
使用者訪問量的增加意味著使用者地域的分散請求,如果所有請求都直接傳送中心伺服器的話,距離越遠,響應速度越差,這時就需要用到 CDN 技術,透過 CDN 加速,保證使用者訪問每次都從最近的伺服器獲取資料,架構圖如下:
NO.7 分散式資料庫
分散式資料庫是網站資料庫拆分的最後手段,只有在單表資料規模非常龐大的時候才使用。
不到不得已時,網站更常用的資料庫拆分手段是業務分庫,將不同業務的資料庫部署在不同的物理伺服器上,如下圖所示:
NO.8 使用非關係型資料庫
當網站資料足夠龐大,達到PB甚至更高時,關係型資料庫已經達到瓶頸,這時就需要考慮採用非關係型資料庫了,請看下圖:
NO.9 微服務架構
隨著網站業務的不斷擴大,我們需要將各個業務進行拆分,形成不能的產品線,每個產品線由不同的業務團隊負責,各個產品之間需要通訊,這時就要用到微服務架構,請看下圖:
目前,最流行的 JavaEE 框架就是 Spring 框架,該框架是最古老也就是最成熟的 Java 技術框架之一。
為了適應技術的高速發展,Spring Cloud 出現了,它的出現帶給了我們微服務的解決方案。
透過 Spring Cloud,我們很容易部署一套高效能高可用的微服務架構。
回覆列表
https://m.toutiaocdn.com/i6624862486354985476/?iid=51515366066&app=news_article×tamp=1542766033&group_id=6624862486354985476&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share&from=singlemessage