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

前言

【福利】阿里雲產品1888元優惠券

一個好的架構是靠演變而來，而不是單純的靠設計。剛開始作架構設計，咱們不可能全方位的考慮到架構的高性能、高擴展性、高安全等各方面的因素。隨着業務需求愈來愈多、業務訪問壓力愈來愈大，架構不斷的演變及進化，於是造就了一個成熟穩定的大型架構。如淘寶網、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：

【福利】阿里雲產品1888元優惠券