厲害了，淘寶千萬併發，14 次架構演進….

本文以設計淘寶網的後臺架構爲例，介紹從一百個併發到千萬級併發狀況下服務端的架構的14次演進過程，同時列舉出每一個演進階段會遇到的相關技術，讓你們對架構的演進有一個總體的認知。

文章最後彙總了一些架構設計的原則。

基本概念

在介紹架構以前，爲了不部分讀者對架構設計中的一些概念不瞭解，下面對幾個最基礎的概念進行介紹。

1）什麼是分佈式？

系統中的多個模塊在不一樣服務器上部署，便可稱爲分佈式系統，如Tomcat和數據庫分別部署在不一樣的服務器上，或兩個相同功能的Tomcat分別部署在不一樣服務器上。

2）什麼是高可用？

系統中部分節點失效時，其餘節點可以接替它繼續提供服務，則可認爲系統具備高可用性。

3）什麼是集羣？

一個特定領域的軟件部署在多臺服務器上並做爲一個總體提供一類服務，這個總體稱爲集羣。

如Zookeeper中的Master和Slave分別部署在多臺服務器上，共同組成一個總體提供集中配置服務。

在常見的集羣中，客戶端每每可以鏈接任意一個節點得到服務，而且當集羣中一個節點掉線時，其餘節點每每可以自動的接替它繼續提供服務，這時候說明集羣具備高可用性。

4）什麼是負載均衡？

請求發送到系統時，經過某些方式把請求均勻分發到多個節點上，使系統中每一個節點可以均勻的處理請求負載，則可認爲系統是負載均衡的。

5）什麼是正向代理和反向代理？

系統內部要訪問外部網絡時，統一經過一個代理服務器把請求轉發出去，在外部網絡看來就是代理服務器發起的訪問，此時代理服務器實現的是正向代理；

當外部請求進入系統時，代理服務器把該請求轉發到系統中的某臺服務器上，對外部請求來講，與之交互的只有代理服務器，此時代理服務器實現的是反向代理。

簡單來講，正向代理是代理服務器代替系統內部來訪問外部網絡的過程，反向代理是外部請求訪問系統時經過代理服務器轉發到內部服務器的過程。

純真年代：單機架構

以淘寶做爲例子：在網站最初時，應用數量與用戶數都較少，能夠把Tomcat和數據庫部署在同一臺服務器上。瀏覽器往www.taobao.com發起請求時，首先通過DNS服務器（域名系統）把域名轉換爲實際IP地址10.102.4.1，瀏覽器轉而訪問該IP對應的Tomcat。

架構瓶頸：隨着用戶數的增加，Tomcat和數據庫之間競爭資源，單機性能不足以支撐業務。

第一次演進：Tomcat與數據庫分開部署

Tomcat和數據庫分別獨佔服務器資源，顯著提升二者各自性能。

架構瓶頸：隨着用戶數的增加，併發讀寫數據庫成爲瓶頸。

第二次演進：引入本地緩存和分佈式緩存

在Tomcat同服務器上或同JVM中增長本地緩存，並在外部增長分佈式緩存，緩存熱門商品信息或熱門商品的html頁面等。經過緩存能把絕大多數請求在讀寫數據庫前攔截掉，大大下降數據庫壓力。

其中涉及的技術包括：使用memcached做爲本地緩存，使用Redis做爲分佈式緩存，還會涉及緩存一致性、緩存穿透/擊穿、緩存雪崩、熱點數據集中失效等問題。

架構瓶頸：緩存抗住了大部分的訪問請求，隨着用戶數的增加，併發壓力主要落在單機的Tomcat上，響應逐漸變慢。

第三次演進：引入反向代理實現負載均衡

在多臺服務器上分別部署Tomcat，使用反向代理軟件（Nginx）把請求均勻分發到每一個Tomcat中。此處假設Tomcat最多支持100個併發，Nginx最多支持50000個併發，那麼理論上Nginx把請求分發到500個Tomcat上，就能抗住50000個併發。

其中涉及的技術包括：Nginx、HAProxy，二者都是工做在網絡第七層的反向代理軟件，主要支持http協議，還會涉及session共享、文件上傳下載的問題。

架構瓶頸：反向代理使應用服務器可支持的併發量大大增長，但併發量的增加也意味着更多請求穿透到數據庫，單機的數據庫最終成爲瓶頸。

第四次演進：數據庫讀寫分離

把數據庫劃分爲讀庫和寫庫，讀庫能夠有多個，經過同步機制把寫庫的數據同步到讀庫，對於須要查詢最新寫入數據場景，可經過在緩存中多寫一份，經過緩存得到最新數據。

其中涉及的技術包括：Mycat，它是數據庫中間件，可經過它來組織數據庫的分離讀寫和分庫分表，客戶端經過它來訪問下層數據庫，還會涉及數據同步，數據一致性的問題。

架構瓶頸：業務逐漸變多，不一樣業務之間的訪問量差距較大，不一樣業務直接競爭數據庫，相互影響性能。

第五次演進：數據庫按業務分庫

把不一樣業務的數據保存到不一樣的數據庫中，使業務之間的資源競爭下降，對於訪問量大的業務，能夠部署更多的服務器來支撐。這樣同時致使跨業務的表沒法直接作關聯分析，須要經過其餘途徑來解決，但這不是本文討論的重點，有興趣的能夠自行搜索解決方案。

架構瓶頸：隨着用戶數的增加，單機的寫庫會逐漸會達到性能瓶頸。

第六次演進：把大表拆分爲小表

好比針對評論數據，可按照商品ID進行hash，路由到對應的表中存儲；針對支付記錄，可按照小時建立表，每一個小時表繼續拆分爲小表，使用用戶ID或記錄編號來路由數據。只要實時操做的表數據量足夠小，請求可以足夠均勻的分發到多臺服務器上的小表，那數據庫就能經過水平擴展的方式來提升性能。其中前面提到的Mycat也支持在大表拆分爲小表狀況下的訪問控制。

這種作法顯著的增長了數據庫運維的難度，對DBA的要求較高。數據庫設計到這種結構時，已經能夠稱爲分佈式數據庫，可是這只是一個邏輯的數據庫總體，數據庫裏不一樣的組成部分是由不一樣的組件單獨來實現的，如分庫分表的管理和請求分發，由Mycat實現，SQL的解析由單機的數據庫實現，讀寫分離可能由網關和消息隊列來實現，查詢結果的彙總可能由數據庫接口層來實現等等，這種架構實際上是MPP（大規模並行處理）架構的一類實現。

目前開源和商用都已經有很多MPP數據庫，開源中比較流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、華爲的LibrA等等，不一樣的MPP數據庫的側重點也不同，如TiDB更側重於分佈式OLTP場景，Greenplum更側重於分佈式OLAP場景，這些MPP數據庫基本都提供了相似Postgresql、Oracle、MySQL那樣的SQL標準支持能力，能把一個查詢解析爲分佈式的執行計劃分發到每臺機器上並行執行，最終由數據庫自己彙總數據進行返回，也提供了諸如權限管理、分庫分表、事務、數據副本等能力，而且大多可以支持100個節點以上的集羣，大大下降了數據庫運維的成本，而且使數據庫也可以實現水平擴展。推薦：大廠在用的分庫分表方案，都在這了！

架構瓶頸：數據庫和Tomcat都可以水平擴展，可支撐的併發大幅提升，隨着用戶數的增加，最終單機的Nginx會成爲瓶頸。

第七次演進：使用LVS或F5來使多個Nginx負載均衡

因爲瓶頸在Nginx，所以沒法經過兩層的Nginx來實現多個Nginx的負載均衡。圖中的LVS和F5是工做在網絡第四層的負載均衡解決方案，其中LVS是軟件，運行在操做系統內核態，可對TCP請求或更高層級的網絡協議進行轉發，所以支持的協議更豐富，而且性能也遠高於Nginx，可假設單機的LVS可支持幾十萬個併發的請求轉發；F5是一種負載均衡硬件，與LVS提供的能力相似，性能比LVS更高，但價格昂貴。因爲LVS是單機版的軟件，若LVS所在服務器宕機則會致使整個後端系統都沒法訪問，所以須要有備用節點。可以使用keepalived軟件模擬出虛擬IP，而後把虛擬IP綁定到多臺LVS服務器上，瀏覽器訪問虛擬IP時，會被路由器重定向到真實的LVS服務器，當主LVS服務器宕機時，keepalived軟件會自動更新路由器中的路由表，把虛擬IP重定向到另一臺正常的LVS服務器，從而達到LVS服務器高可用的效果。

此處須要注意的是，上圖中從Nginx層到Tomcat層這樣畫並不表明所有Nginx都轉發請求到所有的Tomcat，在實際使用時，可能會是幾個Nginx下面接一部分的Tomcat，這些Nginx之間經過keepalived實現高可用，其餘的Nginx接另外的Tomcat，這樣可接入的Tomcat數量就能成倍的增長。

架構瓶頸：因爲LVS也是單機的，隨着併發數增加到幾十萬時，LVS服務器最終會達到瓶頸，此時用戶數達到千萬甚至上億級別，用戶分佈在不一樣的地區，與服務器機房距離不一樣，致使了訪問的延遲會明顯不一樣。

第八次演進：經過DNS輪詢實現機房間的負載均衡

在DNS服務器中可配置一個域名對應多個IP地址，每一個IP地址對應到不一樣的機房裏的虛擬IP。當用戶訪問www.taobao.com時，DNS服務器會使用輪詢策略或其餘策略，來選擇某個IP供用戶訪問。此方式能實現機房間的負載均衡，至此，系統可作到機房級別的水平擴展，千萬級到億級的併發量均可經過增長機房來解決，系統入口處的請求併發量再也不是問題。

架構瓶頸：隨着數據的豐富程度和業務的發展，檢索、分析等需求愈來愈豐富，單單依靠數據庫沒法解決如此豐富的需求。

第九次演進：引入NoSQL數據庫和搜索引擎等技術

當數據庫中的數據多到必定規模時，數據庫就不適用於複雜的查詢了，每每只能知足普通查詢的場景。對於統計報表場景，在數據量大時不必定能跑出結果，並且在跑複雜查詢時會致使其餘查詢變慢，對於全文檢索、可變數據結構等場景，數據庫天生不適用。所以須要針對特定的場景，引入合適的解決方案。如對於海量文件存儲，可經過分佈式文件系統HDFS解決，對於key value類型的數據，可經過HBase和Redis等方案解決，對於全文檢索場景，可經過搜索引擎如ElasticSearch解決，對於多維分析場景，可經過Kylin或Druid等方案解決。

固然，引入更多組件同時會提升系統的複雜度，不一樣的組件保存的數據須要同步，須要考慮一致性的問題，須要有更多的運維手段來管理這些組件等。

架構瓶頸：引入更多組件解決了豐富的需求，業務維度可以極大擴充，隨之而來的是一個應用中包含了太多的業務代碼，業務的升級迭代變得困難。

第十次演進：大應用拆分爲小應用

按照業務板塊來劃分應用代碼，使單個應用的職責更清晰，相互之間能夠作到獨立升級迭代。這時候應用之間可能會涉及到一些公共配置，能夠經過分佈式配置中心Zookeeper來解決。

架構瓶頸：不一樣應用之間存在共用的模塊，由應用單獨管理會致使相同代碼存在多份，致使公共功能升級時所有應用代碼都要跟着升級。

第十一次演進：複用的功能抽離成微服務

如用戶管理、訂單、支付、鑑權等功能在多個應用中都存在，那麼能夠把這些功能的代碼單獨抽取出來造成一個單獨的服務來管理，這樣的服務就是所謂的微服務，應用和服務之間經過HTTP、TCP或RPC請求等多種方式來訪問公共服務，每一個單獨的服務均可以由單獨的團隊來管理。此外，能夠經過Dubbo、SpringCloud等框架實現服務治理、限流、熔斷、降級等功能，提升服務的穩定性和可用性。

架構瓶頸：不一樣服務的接口訪問方式不一樣，應用代碼須要適配多種訪問方式才能使用服務，此外，應用訪問服務，服務之間也可能相互訪問，調用鏈將會變得很是複雜，邏輯變得混亂。

第十二次演進：引入企業服務總線ESB屏蔽服務接口的訪問差別

經過ESB統一進行訪問協議轉換，應用統一經過ESB來訪問後端服務，服務與服務之間也經過ESB來相互調用，以此下降系統的耦合程度。

這種單個應用拆分爲多個應用，公共服務單獨抽取出來來管理，並使用企業消息總線來解除服務之間耦合問題的架構，就是所謂的SOA（面向服務）架構，這種架構與微服務架構容易混淆，由於表現形式十分類似。

我的理解，微服務架構更可能是指把系統裏的公共服務抽取出來單獨運維管理的思想，而SOA架構則是指一種拆分服務並使服務接口訪問變得統一的架構思想，SOA架構中包含了微服務的思想。

架構瓶頸：業務不斷髮展，應用和服務都會不斷變多，應用和服務的部署變得複雜，同一臺服務器上部署多個服務還要解決運行環境衝突的問題，此外，對於如大促這類須要動態擴縮容的場景，須要水平擴展服務的性能，就須要在新增的服務上準備運行環境，部署服務等，運維將變得十分困難。

第十三次演進：引入容器化技術實現運行環境隔離與動態服務管理

目前最流行的容器化技術是Docker，最流行的容器管理服務是Kubernetes(K8S)，應用/服務能夠打包爲Docker鏡像，經過K8S來動態分發和部署鏡像。Docker鏡像可理解爲一個能運行你的應用/服務的最小的操做系統，裏面放着應用/服務的運行代碼，運行環境根據實際的須要設置好。把整個「操做系統」打包爲一個鏡像後，就能夠分發到須要部署相關服務的機器上，直接啓動Docker鏡像就能夠把服務起起來，使服務的部署和運維變得簡單。

在大促的以前，能夠在現有的機器集羣上劃分出服務器來啓動Docker鏡像，加強服務的性能，大促事後就能夠關閉鏡像，對機器上的其餘服務不形成影響（在第18節以前，服務運行在新增機器上須要修改系統配置來適配服務，這會致使機器上其餘服務須要的運行環境被破壞）。

架構瓶頸：使用容器化技術後服務動態擴縮容問題得以解決，可是機器仍是須要公司自身來管理，在非大促的時候，仍是須要閒置着大量的機器資源來應對大促，機器自身成本和運維成本都極高，資源利用率低。

第十四次演進：以雲平臺承載系統

系統可部署到公有云上，利用公有云的海量機器資源，解決動態硬件資源的問題，在大促的時間段裏，在雲平臺中臨時申請更多的資源，結合Docker和K8S來快速部署服務，在大促結束後釋放資源，真正作到按需付費，資源利用率大大提升，同時大大下降了運維成本。

所謂的雲平臺，就是把海量機器資源，經過統一的資源管理，抽象爲一個資源總體，在之上可按需動態申請硬件資源（如CPU、內存、網絡等），而且之上提供通用的操做系統，提供經常使用的技術組件（如Hadoop技術棧，MPP數據庫等）供用戶使用，甚至提供開發好的應用，用戶不須要關係應用內部使用了什麼技術，就可以解決需求（如音視頻轉碼服務、郵件服務、我的博客等）。

在雲平臺中會涉及以下幾個概念：SaaS,PaaS,IaaS都是什麼鬼？這篇看下吧。

1）IaaS：基礎設施即服務。對應於上面所說的機器資源統一爲資源總體，可動態申請硬件資源的層面；

2）PaaS：平臺即服務。對應於上面所說的提供經常使用的技術組件方便系統的開發和維護；

3）SaaS：軟件即服務。對應於上面所說的提供開發好的應用或服務，按功能或性能要求付費。

至此：以上所提到的從高併發訪問問題，到服務的架構和系統實施的層面都有了各自的解決方案。但同時也應該意識到，在上面的介紹中，實際上是有意忽略了諸如跨機房數據同步、分佈式事務實現等等的實際問題，這些問題之後有機會再拿出來單獨討論。

架構設計經驗小結

1）架構的調整是否必須按照上述演變路徑進行？

不是的，以上所說的架構演變順序只是針對某個側面進行單獨的改進，在實際場景中，可能同一時間會有幾個問題須要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。如在政府類的併發量可能不大，但業務可能很豐富的場景，高併發就不是重點解決的問題，此時優先須要的可能會是豐富需求的解決方案。

2）對於將要實施的系統，架構應該設計到什麼程度？

對於單次實施而且性能指標明確的系統，架構設計到可以支持系統的性能指標要求就足夠了，但要留有擴展架構的接口以便不備之需。對於不斷髮展的系統，如電商平臺，應設計到能知足下一階段用戶量和性能指標要求的程度，並根據業務的增加不斷的迭代升級架構，以支持更高的併發和更豐富的業務。

3）服務端架構和大數據架構有什麼區別？

所謂的「大數據」實際上是海量數據採集清洗轉換、數據存儲、數據分析、數據服務等場景解決方案的一個統稱，在每個場景都包含了多種可選的技術，如數據採集有Flume、Sqoop、Kettle等，數據存儲有分佈式文件系統HDFS、FastDFS，NoSQL數據庫HBase、MongoDB等，數據分析有Spark技術棧、機器學習算法等。

總的來講大數據架構就是根據業務的需求，整合各類大數據組件組合而成的架構，通常會提供分佈式存儲、分佈式計算、多維分析、數據倉庫、機器學習算法等能力。而服務端架構更多指的是應用組織層面的架構，底層能力每每是由大數據架構來提供。

4）有沒有一些架構設計的原則？

a. N+1設計：系統中的每一個組件都應作到沒有單點故障；

b. 回滾設計：確保系統能夠向前兼容，在系統升級時應能有辦法回滾版本；

c. 禁用設計：應該提供控制具體功能是否可用的配置，在系統出現故障時可以快速下線功能；

d. 監控設計：在設計階段就要考慮監控的手段；

e. 多活數據中心設計：若系統須要極高的高可用，應考慮在多地實施數據中心進行多活，至少在一個機房斷電的狀況下系統依然可用；

f. 採用成熟的技術：剛開發的或開源的技術每每存在不少隱藏的bug，出了問題沒有商業支持可能會是一個災難；

g. 資源隔離設計：應避免單一業務佔用所有資源；

h. 架構應能水平擴展：系統只有作到能水平擴展，纔能有效避免瓶頸問題；

i. 非核心則購買：非核心功能若須要佔用大量的研發資源才能解決，則考慮購買成熟的產品；

j. 使用商用硬件：商用硬件能有效下降硬件故障的機率；

k. 快速迭代：系統應該快速開發小功能模塊，儘快上線進行驗證，早日發現問題大大下降系統交付的風險；

l. 無狀態設計：服務接口應該作成無狀態的，當前接口的訪問不依賴於接口上次訪問的狀態。

讀者福利：

點擊領取