分布式系統架構演進過程

文章目錄

• • • • 前言
      • 1. 概述
      • 2. 基本概念
      • • 分布式
        • 高可用
        • 叢集
        • 負載均衡
        • 正向代理和反向代理
      • 3. 架構演進
      • • 3.1 單機架構
        • 3.2 第一次演進：Tomcat與資料庫分開部署
        • 3.3 第二次演進：引入本地緩存和分布式緩存
        • 3.4 第三次演進：引入反向代理實作負載均衡
        • 3.5 第四次演進：資料庫讀寫分離
        • 3.6 第五次演進：資料庫按業務分庫
        • 3.7 第六次演進：把大表拆分為小表
        • 3.8 第七次演進：使用LVS或F5來使多個Nginx負載均衡
        • 3.9 第八次演進：通過DNS輪詢實作機房間的負載均衡
        • 3.10 第九次演進：引入NoSQL資料庫和搜尋引擎等技術
        • 3.11 第十次演進：大應用拆分為小應用
        • 3.12 第十一次演進：複用的功能抽離成微服務
        • 3.13 第十二次演進：引入企業服務總線ESB屏蔽服務接口的通路差異
        • 3.14 第十三次演進：引入容器化技術實作運作環境隔離與動态服務管理
        • 3.15 第十四次演進：以雲平台承載系統
      • 4. 架構設計總結
      • • 架構的調整是否必須按照上述演變路徑進行？
        • 對于将要實施的系統，架構應該設計到什麼程度？
        • 服務端架構和大資料架構有什麼差別？
        • 有沒有一些架構設計的原則？

前言

最近因為詞窮，學習工作忙，就轉載一些品質很高的部落格文章，以供慢慢的深入學習

作者：huashiou

位址：https://segmentfault.com/a/1190000018626163

1. 概述

本文以淘寶作為例子，介紹從一百個并發到千萬級并發情況下服務端的架構的演進過程，同時列舉出每個演進階段會遇到的相關技術，讓大家對架構的演進有一個整體的認知，文章最後彙總了一些架構設計的原則。

2. 基本概念

在介紹架構之前，先簡單的介紹一下架構設計中的基礎概念

分布式

系統中的多個子產品在不同的伺服器上進行部署，即稱為分布式，如Tomcat和資料庫分别部署在不同的伺服器上，或兩個相同功能的Tomcat分别部署在不同伺服器上。

高可用

系統中部分節點失效時，其他節點能夠接替它繼續提供服務，則可認為系統具有高可用性

叢集

一個特定領域的軟體部署在多台伺服器上并作為一個整體提供一類服務，這個整體稱為叢集。如Zookeeper中的Master和Slave分别部署在多台伺服器上，共同組成一個整體提供集中配置服務。在常見的叢集中，用戶端往往能夠連接配接任意一個節點獲得服務，并且當叢集中一個節點掉線時，其他節點往往能夠自動的接替它繼續提供服務，這時候說明叢集具有高可用性。

負載均衡

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

正向代理和反向代理

系統内部要通路外部網絡時，統一通過一個代理伺服器把請求轉發出去，在外部網絡看來就是代理伺服器發起的通路，此時代理伺服器實作的是正向代理；

當外部請求進入系統時，代理伺服器把該請求轉發到系統中的某台伺服器上，對外部請求來說，與之互動的隻有代理伺服器，此時代理伺服器實作的是反向代理。

簡單來說，正向代理是代理伺服器代替系統内部來通路外部網絡的過程，反向代理是外部請求通路系統時通過代理伺服器轉發到内部伺服器的過程。

3. 架構演進

3.1 單機架構

以淘寶作為例子。在網站最初時，應用數量與使用者數都較少，可以把Tomcat和資料庫部署在同一台伺服器上。浏覽器往www.taobao.com發起請求時，首先經過DNS伺服器（域名系統）把域名轉換為實際IP位址10.102.4.1，浏覽器轉而通路該IP對應的Tomcat。

随着使用者數的增長，Tomcat和資料庫之間競争資源，單機性能不足以支撐業務

3.2 第一次演進：Tomcat與資料庫分開部署

Tomcat和資料庫分别獨占伺服器資源，顯著提高兩者各自性能。

其實傳統性的企業有的任然是使用這個架構，并不是這個架構low，一切的架構演進都是基于通路量的增加而進行演進的

随着使用者數的增長，并發讀寫資料庫成為瓶頸

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

在Tomcat同伺服器上或同JVM中增加本地緩存，并在外部增加分布式緩存，緩存熱門商品資訊或熱門商品的html頁面等。通過緩存能把絕大多數請求在讀寫資料庫前攔截掉，大大降低資料庫壓力。其中涉及的技術包括：使用memcached作為本地緩存，使用Redis作為分布式緩存。

緩存的引入是會對資料庫的并發讀寫壓力的降低，但是還會涉及緩存一緻性、緩存穿透/擊穿、緩存雪崩、熱點資料集中失效等問題。

緩存抗住了大部分的通路請求，随着使用者數的增長，并發壓力主要落在單機的Tomcat上，響應逐漸變慢

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

在多台伺服器上分别部署Tomcat，使用反向代理軟體（Nginx）把請求均勻分發到每個Tomcat中。此處假設Tomcat最多支援100個并發，Nginx最多支援50000個并發，那麼理論上Nginx把請求分發到500個Tomcat上，就能抗住50000個并發。其中涉及的技術包括：Nginx、HAProxy，兩者都是工作在網絡第七層的反向代理軟體。主要支援http協。

這樣的技術架構主要還會涉及session共享、檔案上傳下載下傳的問題。 參考《大型網站技術架構》

反向代理使應用伺服器可支援的并發量大大增加，但并發量的增長也意味着更多請求穿透到資料庫，單機的資料庫最終成為瓶頸

3.5 第四次演進：資料庫讀寫分離

把資料庫劃分為讀庫和寫庫，讀庫可以有多個，通過同步機制把寫庫的資料同步到讀庫，對于需要查詢最新寫入資料場景，可通過在緩存中多寫一份，通過緩存獲得最新資料。其中涉及的技術包括：Mycat，它是資料庫中間件，可通過它來組織資料庫的分離讀寫和分庫分表，

用戶端通過它來通路下層資料庫，還會涉及資料同步，資料一緻性的問題。

例如：mysql資料的主從複制原理，高性能部署架構 理論

業務逐漸變多，不同業務之間的通路量差距較大，不同業務直接競争資料庫，互相影響性能

3.6 第五次演進：資料庫按業務分庫

把不同業務的資料儲存到不同的資料庫中，使業務之間的資源競争降低，對于通路量大的業務，可以部署更多的伺服器來支撐。這樣同時導緻跨業務的表無法直接做關聯分析，需要通過其他途徑來解決，但這不是本文讨論的重點，有興趣的可以自行搜尋解決方案。

随着使用者數的增長，單機的寫庫會逐漸會達到性能瓶頸

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

比如針對評論資料，可按照商品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會成為瓶頸

3.8 第七次演進：使用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伺服器最終會達到瓶頸，此時使用者數達到千萬甚至上億級别，使用者分布在不同的地區，與伺服器機房距離不同，導緻了通路的延遲會明顯不同

3.9 第八次演進：通過DNS輪詢實作機房間的負載均衡

在DNS伺服器中可配置一個域名對應多個IP位址，每個IP位址對應到不同的機房裡的虛拟IP。當使用者通路www.taobao.com時，DNS伺服器會使用輪詢政策或其他政策，來選擇某個IP供使用者通路。此方式能實作機房間的負載均衡，至此，系統可做到機房級别的水準擴充，千萬級到億級的并發量都可通過增加機房來解決，系統入口處的請求并發量不再是問題。

随着資料的豐富程度和業務的發展，檢索、分析等需求越來越豐富，單單依靠資料庫無法解決如此豐富的需求

3.10 第九次演進：引入NoSQL資料庫和搜尋引擎等技術

當資料庫中的資料多到一定規模時，資料庫就不适用于複雜的查詢了，往往隻能滿足普通查詢的場景。對于統計報表場景，在資料量大時不一定能跑出結果，而且在跑複雜查詢時會導緻其他查詢變慢，對于全文檢索、可變資料結構等場景，資料庫天生不适用。是以需要針對特定的場景，引入合适的解決方案。如對于海量檔案存儲，可通過分布式檔案系統HDFS解決，對于key value類型的資料，可通過HBase和Redis等方案解決，對于全文檢索場景，可通過搜尋引擎如ElasticSearch解決，對于多元分析場景，可通過Kylin或Druid等方案解決。

當然，引入更多元件同時會提高系統的複雜度，不同的元件儲存的資料需要同步，需要考慮一緻性的問題，需要有更多的運維手段來管理這些元件等。（這些延伸出來的技術需要很深入的探索）

引入更多元件解決了豐富的需求，業務次元能夠極大擴充，随之而來的是一個應用中包含了太多的業務代碼，業務的更新疊代變得困難

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

按照業務闆塊來劃分應用代碼，使單個應用的職責更清晰，互相之間可以做到獨立更新疊代。這時候應用之間可能會涉及到一些公共配置，可以通過分布式配置中心Zookeeper來解決。

不同應用之間存在共用的子產品，由應用單獨管理會導緻相同代碼存在多份，導緻公共功能更新時全部應用代碼都要跟着更新

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

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

不同服務的接口通路方式不同，應用代碼需要适配多種通路方式才能使用服務，此外，應用通路服務，服務之間也可能互相通路，調用鍊将會變得非常複雜，邏輯變得混亂

3.13 第十二次演進：引入企業服務總線ESB屏蔽服務接口的通路差異

通過ESB統一進行通路協定轉換，應用統一通過ESB來通路後端服務，服務與服務之間也通過ESB來互相調用，以此降低系統的耦合程度。這種單個應用拆分為多個應用，公共服務單獨抽取出來來管理，并使用企業消息總線來解除服務之間耦合問題的架構，就是所謂的SOA（面向服務）架構，這種架構與微服務架構容易混淆，因為表現形式十分相似。個人了解，微服務架構更多是指把系統裡的公共服務抽取出來單獨運維管理的思想，而SOA架構則是指一種拆分服務并使服務接口通路變得統一的架構思想，SOA架構中包含了微服務的思想。

業務不斷發展，應用和服務都會不斷變多**，應用和服務的部署變得複雜，同一台伺服器上部署多個服務還要解決運作環境沖突的問題，此外，對于如大促這類需要動态擴縮容的場景，需要水準擴充服務的性能，就需要在新增的服務上準備運作環境，部署服務等，運維将變得十分困難**

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

目前最流行的容器化技術是Docker，最流行的容器管理服務是Kubernetes(K8S)，應用/服務可以打包為Docker鏡像，通過K8S來動态分發和部署鏡像。Docker鏡像可了解為一個能運作你的應用/服務的最小的作業系統，裡面放着應用/服務的運作代碼，運作環境根據實際的需要設定好。把整個“作業系統”打包為一個鏡像後，就可以分發到需要部署相關服務的機器上，直接啟動Docker鏡像就可以把服務起起來，使服務的部署和運維變得簡單。（隻知其名不知其人，需要學習了）

在大促的之前，可以在現有的機器叢集上劃分出伺服器來啟動Docker鏡像，增強服務的性能，大促過後就可以關閉鏡像，對機器上的其他服務不造成影響（在3.14節之前，服務運作在新增機器上需要修改系統配置來适配服務，這會導緻機器上其他服務需要的運作環境被破壞）。

使用容器化技術後服務動态擴縮容問題得以解決，但是機器還是需要公司自身來管理，在非大促的時候，還是需要閑置着大量的機器資源來應對大促，機器自身成本和運維成本都極高，資源使用率低

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

系統可部署到公有雲上，利用公有雲的海量機器資源，解決動态硬體資源的問題，在大促的時間段裡，在雲平台中臨時申請更多的資源，結合Docker和K8S來快速部署服務，在大促結束後釋放資源，真正做到按需付費，資源使用率大大提高，同時大大降低了運維成本。（雲平台）

所謂的雲平台，就是把海量機器資源，通過統一的資源管理，抽象為一個資源整體，在之上可按需動态申請硬體資源（如CPU、記憶體、網絡等），并且之上提供通用的作業系統，提供常用的技術元件（如Hadoop技術棧，MPP資料庫等）供使用者使用，甚至提供開發好的應用，使用者不需要關系應用内部使用了什麼技術，就能夠解決需求（如音視訊轉碼服務、郵件服務、個人部落格等）。在雲平台中會涉及如下幾個概念：

• IaaS：基礎設施即服務。對應于上面所說的機器資源統一為資源整體，可動态申請硬體資源的層面；
• PaaS：平台即服務。對應于上面所說的提供常用的技術元件友善系統的開發和維護；
• SaaS：軟體即服務。對應于上面所說的提供開發好的應用或服務，按功能或性能要求付費。

至此，以上所提到的從高并發通路問題，到服務的架構和系統實施的層面都有了各自的解決方案，但同時也應該意識到，在上面的介紹中，其實是有意忽略了諸如跨機房資料同步、分布式事務實作等等的實際問題，這些問題以後有機會再拿出來單獨讨論

4. 架構設計總結

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

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

對于将要實施的系統，架構應該設計到什麼程度？

對于單次實施并且性能名額明确的系統，架構設計到能夠支援系統的性能名額要求就足夠了，但要留有擴充架構的接口以便不備之需。對于不斷發展的系統，如電商平台，應設計到能滿足下一階段使用者量和性能名額要求的程度，并根據業務的增長不斷的疊代更新架構，以支援更高的并發和更豐富的業務。

服務端架構和大資料架構有什麼差別？

所謂的“大資料”其實是海量資料采集清洗轉換、資料存儲、資料分析、資料服務等場景解決方案的一個統稱，在每一個場景都包含了多種可選的技術，如資料采集有Flume、Sqoop、Kettle等，資料存儲有分布式檔案系統HDFS、FastDFS，NoSQL資料庫HBase、MongoDB等，資料分析有Spark技術棧、機器學習算法等。總的來說大資料架構就是根據業務的需求，整合各種大資料元件組合而成的架構，一般會提供分布式存儲、分布式計算、多元分析、資料倉庫、機器學習算法等能力。而服務端架構更多指的是應用組織層面的架構，底層能力往往是由大資料架構來提供。

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

• N+1設計。系統中的每個元件都應做到沒有單點故障；
• 復原設計。確定系統可以向前相容，在系統更新時應能有辦法復原版本；
• 禁用設計。應該提供控制具體功能是否可用的配置，在系統出現故障時能夠快速下線功能；
• 監控設計。在設計階段就要考慮監控的手段；
• 多活資料中心設計。若系統需要極高的高可用，應考慮在多地實施資料中心進行多活，至少在一個機房斷電的情況下系統依然可用；
• 采用成熟的技術。剛開發的或開源的技術往往存在很多隐藏的bug，出了問題沒有商業支援可能會是一個災難；
• 資源隔離設計。應避免單一業務占用全部資源；
• 架構應能水準擴充。系統隻有做到能水準擴充，才能有效避免瓶頸問題；
• 非核心則購買。非核心功能若需要占用大量的研發資源才能解決，則考慮購買成熟的産品；
• 使用商用硬體。商用硬體能有效降低硬體故障的機率；
• 快速疊代。系統應該快速開發小功能子產品，盡快上線進行驗證，早日發現問題大大降低系統傳遞的風險；
• 無狀态設計。服務接口應該做成無狀态的，目前接口的通路不依賴于接口上次通路的狀态。