點擊上方 java項目開發(fā) ，選擇 星標(biāo) 公眾號
重磅資訊，干貨，第一時間送達

本文以設(shè)計淘寶網(wǎng)的后臺架構(gòu)為例，介紹從一百個并發(fā)到千萬級并發(fā)情況下服務(wù)端的架構(gòu)的演進過程

在介紹架構(gòu)之前，為了避免部分讀者對架構(gòu)設(shè)計中的一些概念不了解，下面對幾個最基礎(chǔ)的概念進行介紹。

系統(tǒng)中的多個模塊在不同服務(wù)器上部署，即可稱為分布式系統(tǒng)，如Tomcat和數(shù)據(jù)庫分別部署在不同的服務(wù)器上，或兩個相同功能的Tomcat分別部署在不同服務(wù)器上。

系統(tǒng)中部分節(jié)點失效時，其他節(jié)點能夠接替它繼續(xù)提供服務(wù)，則可認為系統(tǒng)具有高可用性。

在常見的集群中，客戶端往往能夠連接任意一個節(jié)點獲得服務(wù)，并且當(dāng)集群中一個節(jié)點掉線時，其他節(jié)點往往能夠自動的接替它繼續(xù)提供服務(wù)，這時候說明集群具有高可用性。

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

以淘寶作為例子：在網(wǎng)站最初時，應(yīng)用數(shù)量與用戶數(shù)都較少，可以把Tomcat和數(shù)據(jù)庫部署在同一臺服務(wù)器上。

瀏覽器往www.taobao.com發(fā)起請求時，首先經(jīng)過DNS服務(wù)器（域名系統(tǒng)）把域名轉(zhuǎn)換為實際IP地址10.102.4.1，瀏覽器轉(zhuǎn)而訪問該IP對應(yīng)的Tomcat。

第一次演進：Tomcat與數(shù)據(jù)庫分開部署

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

第三次演進：引入反向代理實現(xiàn)負載均衡

在多臺服務(wù)器上分別部署Tomcat，使用反向代理軟件（Nginx）把請求均勻分發(fā)到每個Tomcat中。

此處假設(shè)Tomcat最多支持100個并發(fā)，Nginx最多支持50000個并發(fā)，那么理論上Nginx把請求分發(fā)到500個Tomcat上，就能抗住50000個并發(fā)。

第四次演進：數(shù)據(jù)庫讀寫分離

第五次演進：數(shù)據(jù)庫按業(yè)務(wù)分庫

把不同業(yè)務(wù)的數(shù)據(jù)保存到不同的數(shù)據(jù)庫中，使業(yè)務(wù)之間的資源競爭降低，對于訪問量大的業(yè)務(wù)，可以部署更多的服務(wù)器來支撐。

這樣同時導(dǎo)致跨業(yè)務(wù)的表無法直接做關(guān)聯(lián)分析，需要通過其他途徑來解決，但這不是本文討論的重點，有興趣的可以自行搜索解決方案。

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

比如針對評論數(shù)據(jù)，可按照商品ID進行hash，路由到對應(yīng)的表中存儲；

針對支付記錄，可按照小時創(chuàng)建表，每個小時表繼續(xù)拆分為小表，使用用戶ID或記錄編號來路由數(shù)據(jù)。

只要實時操作的表數(shù)據(jù)量足夠小，請求能夠足夠均勻的分發(fā)到多臺服務(wù)器上的小表，那數(shù)據(jù)庫就能通過水平擴展的方式來提高性能。其中前面提到的Mycat也支持在大表拆分為小表情況下的訪問控制。

這種做法顯著的增加了數(shù)據(jù)庫運維的難度，對DBA的要求較高。數(shù)據(jù)庫設(shè)計到這種結(jié)構(gòu)時，已經(jīng)可以稱為分布式數(shù)據(jù)庫

但這只是一個邏輯的數(shù)據(jù)庫整體，數(shù)據(jù)庫里不同的組成部分是由不同的組件單獨來實現(xiàn)的

搜索公眾號頂級架構(gòu)師后臺回復(fù)“手冊”，獲取一份驚喜禮包。

如分庫分表的管理和請求分發(fā)，由Mycat實現(xiàn)，SQL的解析由單機的數(shù)據(jù)庫實現(xiàn)，讀寫分離可能由網(wǎng)關(guān)和消息隊列來實現(xiàn)，查詢結(jié)果的匯總可能由數(shù)據(jù)庫接口層來實現(xiàn)等等

這種架構(gòu)其實是MPP（大規(guī)模并行處理）架構(gòu)的一類實現(xiàn)。

目前開源和商用都已經(jīng)有不少MPP數(shù)據(jù)庫，開源中比較流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、華為的LibrA等等

不同的MPP數(shù)據(jù)庫的側(cè)重點也不一樣，如TiDB更側(cè)重于分布式OLTP場景，Greenplum更側(cè)重于分布式OLAP場景

這些MPP數(shù)據(jù)庫基本都提供了類似Postgresql、Oracle、MySQL那樣的SQL標(biāo)準(zhǔn)支持能力，能把一個查詢解析為分布式的執(zhí)行計劃分發(fā)到每臺機器上并行執(zhí)行，最終由數(shù)據(jù)庫本身匯總數(shù)據(jù)進行返回

也提供了諸如權(quán)限管理、分庫分表、事務(wù)、數(shù)據(jù)副本等能力，并且大多能夠支持100個節(jié)點以上的集群，大大降低了數(shù)據(jù)庫運維的成本，并且使數(shù)據(jù)庫也能夠?qū)崿F(xiàn)水平擴展。

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

由于瓶頸在Nginx，因此無法通過兩層的Nginx來實現(xiàn)多個Nginx的負載均衡。

圖中的LVS和F5是工作在網(wǎng)絡(luò)第四層的負載均衡解決方案，其中LVS是軟件，運行在操作系統(tǒng)內(nèi)核態(tài)，可對TCP請求或更高層級的網(wǎng)絡(luò)協(xié)議進行轉(zhuǎn)發(fā)，因此支持的協(xié)議更豐富，并且性能也遠高于Nginx，可假設(shè)單機的LVS可支持幾十萬個并發(fā)的請求轉(zhuǎn)發(fā)；

F5是一種負載均衡硬件，與LVS提供的能力類似，性能比LVS更高，但價格昂貴。

由于LVS是單機版的軟件，若LVS所在服務(wù)器宕機則會導(dǎo)致整個后端系統(tǒng)都無法訪問，因此需要有備用節(jié)點。

可使用keepalived軟件模擬出虛擬IP，然后把虛擬IP綁定到多臺LVS服務(wù)器上，瀏覽器訪問虛擬IP時，會被路由器重定向到真實的LVS服務(wù)器

當(dāng)主LVS服務(wù)器宕機時，keepalived軟件會自動更新路由器中的路由表，把虛擬IP重定向到另外一臺正常的LVS服務(wù)器，從而達到LVS服務(wù)器高可用的效果。

此處需要注意的是，上圖中從Nginx層到Tomcat層這樣畫并不代表全部Nginx都轉(zhuǎn)發(fā)請求到全部的Tomcat

在實際使用時，可能會是幾個Nginx下面接一部分的Tomcat，這些Nginx之間通過keepalived實現(xiàn)高可用，其他的Nginx接另外的Tomcat，這樣可接入的Tomcat數(shù)量就能成倍的增加。

第八次演進：通過DNS輪詢實現(xiàn)機房間的負載均衡

在DNS服務(wù)器中可配置一個域名對應(yīng)多個IP地址，每個IP地址對應(yīng)到不同的機房里的虛擬IP。

當(dāng)用戶訪問www.taobao.com時，DNS服務(wù)器會使用輪詢策略或其他策略，來選擇某個IP供用戶訪問。此方式能實現(xiàn)機房間的負載均衡

至此，系統(tǒng)可做到機房級別的水平擴展，千萬級到億級的并發(fā)量都可通過增加機房來解決，系統(tǒng)入口處的請求并發(fā)量不再是問題。

第九次演進：引入NoSQL數(shù)據(jù)庫和搜索引擎等技術(shù)

當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)多到一定規(guī)模時，數(shù)據(jù)庫就不適用于復(fù)雜的查詢了，往往只能滿足普通查詢的場景。

對于統(tǒng)計報表場景，在數(shù)據(jù)量大時不一定能跑出結(jié)果，而且在跑復(fù)雜查詢時會導(dǎo)致其他查詢變慢

對于全文檢索、可變數(shù)據(jù)結(jié)構(gòu)等場景，數(shù)據(jù)庫天生不適用。因此需要針對特定的場景，引入合適的解決方案。

如對于海量文件存儲，可通過分布式文件系統(tǒng)HDFS解決，對于key value類型的數(shù)據(jù)，可通過HBase和Redis等方案解決

對于全文檢索場景，可通過搜索引擎如ElasticSearch解決，對于多維分析場景，可通過Kylin或Druid等方案解決。

第十次演進：大應(yīng)用拆分為小應(yīng)用

第十一次演進：復(fù)用的功能抽離成微服務(wù)

如用戶管理、訂單、支付、鑒權(quán)等功能在多個應(yīng)用中都存在，那么可以把這些功能的代碼單獨抽取出來形成一個單獨的服務(wù)來管理

這樣的服務(wù)就是所謂的微服務(wù)，應(yīng)用和服務(wù)之間通過HTTP、TCP或RPC請求等多種方式來訪問公共服務(wù)，每個單獨的服務(wù)都可以由單獨的團隊來管理。

此外，可以通過Dubbo、SpringCloud等框架實現(xiàn)服務(wù)治理、限流、熔斷、降級等功能，提高服務(wù)的穩(wěn)定性和可用性。

第十二次演進：引入企業(yè)服務(wù)總線ESB屏蔽服務(wù)接口的訪問差異

架構(gòu)瓶頸：業(yè)務(wù)不斷發(fā)展，應(yīng)用和服務(wù)都會不斷變多，應(yīng)用和服務(wù)的部署變得復(fù)雜，同一臺服務(wù)器上部署多個服務(wù)還要解決運行環(huán)境沖突的問題

此外，對于如大促這類需要動態(tài)擴縮容的場景，需要水平擴展服務(wù)的性能，就需要在新增的服務(wù)上準(zhǔn)備運行環(huán)境，部署服務(wù)等，運維將變得十分困難。

第十三次演進：引入容器化技術(shù)實現(xiàn)運行環(huán)境隔離與動態(tài)服務(wù)管理

目前最流行的容器化技術(shù)是Docker，最流行的容器管理服務(wù)是Kubernetes(K8S)，應(yīng)用/服務(wù)可以打包為Docker鏡像，通過K8S來動態(tài)分發(fā)和部署鏡像。

Docker鏡像可理解為一個能運行你的應(yīng)用/服務(wù)的最小的操作系統(tǒng)，里面放著應(yīng)用/服務(wù)的運行代碼，運行環(huán)境根據(jù)實際的需要設(shè)置好。

把整個“操作系統(tǒng)”打包為一個鏡像后，就可以分發(fā)到需要部署相關(guān)服務(wù)的機器上，直接啟動Docker鏡像就可以把服務(wù)起起來，使服務(wù)的部署和運維變得簡單。

在大促的之前，可以在現(xiàn)有的機器集群上劃分出服務(wù)器來啟動Docker鏡像，增強服務(wù)的性能

大促過后就可以關(guān)閉鏡像，對機器上的其他服務(wù)不造成影響（在第18節(jié)之前，服務(wù)運行在新增機器上需要修改系統(tǒng)配置來適配服務(wù)，這會導(dǎo)致機器上其他服務(wù)需要的運行環(huán)境被破壞）。

第十四次演進：以云平臺承載系統(tǒng)

系統(tǒng)可部署到公有云上，利用公有云的海量機器資源，解決動態(tài)硬件資源的問題

在大促的時間段里，在云平臺中臨時申請更多的資源，結(jié)合Docker和K8S來快速部署服務(wù)，在大促結(jié)束后釋放資源，真正做到按需付費，資源利用率大大提高，同時大大降低了運維成本。

所謂的云平臺，就是把海量機器資源，通過統(tǒng)一的資源管理，抽象為一個資源整體

在云平臺上可按需動態(tài)申請硬件資源（如CPU、內(nèi)存、網(wǎng)絡(luò)等），并且之上提供通用的操作系統(tǒng)，提供常用的技術(shù)組件（如Hadoop技術(shù)棧，MPP數(shù)據(jù)庫等）供用戶使用，甚至提供開發(fā)好的應(yīng)用

用戶不需要關(guān)心應(yīng)用內(nèi)部使用了什么技術(shù)，就能夠解決需求（如音視頻轉(zhuǎn)碼服務(wù)、郵件服務(wù)、個人博客等）。

1. IaaS：基礎(chǔ)設(shè)施即服務(wù)。對應(yīng)于上面所說的機器資源統(tǒng)一為資源整體，可動態(tài)申請硬件資源的層面；

2. PaaS：平臺即服務(wù)。對應(yīng)于上面所說的提供常用的技術(shù)組件方便系統(tǒng)的開發(fā)和維護；

3. SaaS：軟件即服務(wù)。對應(yīng)于上面所說的提供開發(fā)好的應(yīng)用或服務(wù)，按功能或性能要求付費。

至此：以上所提到的從高并發(fā)訪問問題，到服務(wù)的架構(gòu)和系統(tǒng)實施的層面都有了各自的解決方案。

但同時也應(yīng)該意識到，在上面的介紹中，其實是有意忽略了諸如跨機房數(shù)據(jù)同步、分布式事務(wù)實現(xiàn)等等的實際問題，這些問題以后有機會再拿出來單獨討論。

架構(gòu)設(shè)計經(jīng)驗小結(jié)

不是的，以上所說的架構(gòu)演變順序只是針對某個側(cè)面進行單獨的改進

在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應(yīng)該按照實際問題實際解決。

如在政府類的并發(fā)量可能不大，但業(yè)務(wù)可能很豐富的場景，高并發(fā)就不是重點解決的問題，此時優(yōu)先需要的可能會是豐富需求的解決方案。

對于單次實施并且性能指標(biāo)明確的系統(tǒng)，架構(gòu)設(shè)計到能夠支持系統(tǒng)的性能指標(biāo)要求就足夠了，但要留有擴展架構(gòu)的接口以便不備之需。

對于不斷發(fā)展的系統(tǒng)，如電商平臺，應(yīng)設(shè)計到能滿足下一階段用戶量和性能指標(biāo)要求的程度，并根據(jù)業(yè)務(wù)的增長不斷的迭代升級架構(gòu)，以支持更高的并發(fā)和更豐富的業(yè)務(wù)。

所謂的“大數(shù)據(jù)”其實是海量數(shù)據(jù)采集清洗轉(zhuǎn)換、數(shù)據(jù)存儲、數(shù)據(jù)分析、數(shù)據(jù)服務(wù)等場景解決方案的一個統(tǒng)稱，在每一個場景都包含了多種可選的技術(shù)

如數(shù)據(jù)采集有Flume、Sqoop、Kettle等，數(shù)據(jù)存儲有分布式文件系統(tǒng)HDFS、FastDFS，NoSQL數(shù)據(jù)庫HBase、MongoDB等，數(shù)據(jù)分析有Spark技術(shù)棧、機器學(xué)習(xí)算法等。

總的來說大數(shù)據(jù)架構(gòu)就是根據(jù)業(yè)務(wù)的需求，整合各種大數(shù)據(jù)組件組合而成的架構(gòu)，一般會提供分布式存儲、分布式計算、多維分析、數(shù)據(jù)倉庫、機器學(xué)習(xí)算法等能力。

而服務(wù)端架構(gòu)更多指的是應(yīng)用組織層面的架構(gòu)，底層能力往往是由大數(shù)據(jù)架構(gòu)來提供。

•  N+1設(shè)計：系統(tǒng)中的每個組件都應(yīng)做到?jīng)]有單點故障；

• 回滾設(shè)計：確保系統(tǒng)可以向前兼容，在系統(tǒng)升級時應(yīng)能有辦法回滾版本；

• 禁用設(shè)計：應(yīng)該提供控制具體功能是否可用的配置，在系統(tǒng)出現(xiàn)故障時能夠快速下線功能；

• 監(jiān)控設(shè)計：在設(shè)計階段就要考慮監(jiān)控的手段；

• 多活數(shù)據(jù)中心設(shè)計：若系統(tǒng)需要極高的高可用，應(yīng)考慮在多地實施數(shù)據(jù)中心進行多活，至少在一個機房斷電的情況下系統(tǒng)依然可用；

• 采用成熟的技術(shù)：剛開發(fā)的或開源的技術(shù)往往存在很多隱藏的bug，出了問題沒有商業(yè)支持可能會是一個災(zāi)難；

• 資源隔離設(shè)計：應(yīng)避免單一業(yè)務(wù)占用全部資源；

• 架構(gòu)應(yīng)能水平擴展：系統(tǒng)只有做到能水平擴展，才能有效避免瓶頸問題；

• 非核心則購買：非核心功能若需要占用大量的研發(fā)資源才能解決，則考慮購買成熟的產(chǎn)品；

• 使用商用硬件：商用硬件能有效降低硬件故障的機率；

• 快速迭代：系統(tǒng)應(yīng)該快速開發(fā)小功能模塊，盡快上線進行驗證，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風(fēng)險；

• 無狀態(tài)設(shè)計：服務(wù)接口應(yīng)該做成無狀態(tài)的，當(dāng)前接口的訪問不依賴于接口上次訪問的狀態(tài)。

  
  

推薦閱讀：
怎么接私貨？這個渠道你100%有用！請收藏！
喜歡文章，點個在看