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 和數據庫分別獨佔服務器資源，顯著提高兩者各自性能。
隨着用戶數的增長，併發讀寫數據庫成爲瓶頸
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，它是數據庫中間件，可通過它來組織數據庫的分離讀寫和分庫分表，客戶端通過它來訪問下層數據庫，還會涉及數據同步，數據一致性的問題。
業務逐漸變多，不同業務之間的訪問量差距較大，不同業務直接競爭數據庫，相互影響性能
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，出了問題沒有商業支持可能會是一個災難；
- 資源隔離設計。應避免單一業務佔用全部資源；
- 架構應能水平擴展。系統只有做到能水平擴展，纔能有效避免瓶頸問題；
- 非核心則購買。非核心功能若需要佔用大量的研發資源才能解決，則考慮購買成熟的產品；
- 使用商用硬件。商用硬件能有效降低硬件故障的機率；
- 快速迭代。系統應該快速開發小功能模塊，儘快上線進行驗證，早日發現問題大大降低系統交付的風險；
- 無狀態設計。服務接口應該做成無狀態的，當前接口的訪問不依賴於接口上次訪問的狀態。
“不積跬步，無以至千里”，希望未來的你能：有夢爲馬 隨處可棲！加油，少年！
關注公衆號:「Java 知己」，每天更新Java知識哦，期待你的到來！
- 發送「Group」，加入無廣告微信羣，與 10 萬程序員一起進步。
- 發送「面試」，領取BATJ面試資料、面試視頻攻略。
- 發送「玩轉算法」，領取《玩轉算法》系列視頻教程。
- 千萬不要發送「1024」…
