本文以淘寶為例，介紹從一百個并發(fā)到***并發(fā)下服務端架構的演進過程，同時列舉出每個演進階段遇到的相關技術，讓大家對架構的演進有一個整體的認知，文章***匯總了一些架構設計的原則。

在介紹架構之前，為了避免部分讀者對架構設計中的一些概念不了解，下面對幾個最基礎的概念進行介紹：

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

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

③集群：一個特定領域的軟件部署在多臺服務器上并作為一個整體提供一類服務，這個整體稱為集群。

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

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

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

⑤正向代理和反向代理：系統(tǒng)內部要訪問外部網絡時，統(tǒng)一通過一個代理服務器把請求轉發(fā)出去，在外部網絡看來就是代理服務器發(fā)起的訪問，此時代理服務器實現(xiàn)的是正向代理。

當外部請求進入系統(tǒng)時，代理服務器把該請求轉發(fā)到系統(tǒng)中的某臺服務器上，對外部請求來說，與之交互的只有代理服務器，此時代理服務器實現(xiàn)的是反向代理。

簡單來說，正向代理是代理服務器代替系統(tǒng)內部來訪問外部網絡的過程，反向代理是外部請求訪問系統(tǒng)時通過代理服務器轉發(fā)到內部服務器的過程。

架構演進

單機架構

 

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

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

隨著用戶數(shù)的增長，Tomcat 和數(shù)據(jù)庫之間競爭資源，單機性能不足以支撐業(yè)務。

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

 

Tomcat 和數(shù)據(jù)庫分別獨占服務器資源，顯著提高兩者各自性能。隨著用戶數(shù)的增長，并發(fā)讀寫數(shù)據(jù)庫成為瓶頸。

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

 

在 Tomcat 同服務器上或同 JVM 中增加本地緩存，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的 HTML 頁面等。

通過緩存能把絕大多數(shù)請求在讀寫數(shù)據(jù)庫前攔截掉，大大降低數(shù)據(jù)庫壓力。

其中涉及的技術包括：使用 Memcached 作為本地緩存，使用 Redis 作為分布式緩存，還會涉及緩存一致性、緩存穿透/擊穿、緩存雪崩、熱點數(shù)據(jù)集中失效等問題。

緩存抗住了大部分的訪問請求，隨著用戶數(shù)的增長，并發(fā)壓力主要落在單機的 Tomcat 上，響應逐漸變慢。

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

 

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

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

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

反向代理使應用服務器可支持的并發(fā)量大大增加，但并發(fā)量的增長也意味著更多請求穿透到數(shù)據(jù)庫，單機的數(shù)據(jù)庫最終成為瓶頸。

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

 

把數(shù)據(jù)庫劃分為讀庫和寫庫，讀庫可以有多個，通過同步機制把寫庫的數(shù)據(jù)同步到讀庫，對于需要查詢***寫入數(shù)據(jù)場景，可通過在緩存中多寫一份，通過緩存獲得***數(shù)據(jù)。

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

業(yè)務逐漸變多，不同業(yè)務之間的訪問量差距較大，不同業(yè)務直接競爭數(shù)據(jù)庫，相互影響性能。

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

 

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

這樣同時導致跨業(yè)務的表無法直接做關聯(lián)分析，需要通過其他途徑來解決，但這不是本文討論的重點，有興趣的可以自行搜索解決方案。隨著用戶數(shù)的增長，單機的寫庫會逐漸達到性能瓶頸。

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

 

比如針對評論數(shù)據(jù)，可按照商品 ID 進行 Hash，路由到對應的表中存儲;針對支付記錄，可按照小時創(chuàng)建表，每個小時表繼續(xù)拆分為小表，使用用戶 ID 或記錄編號來路由數(shù)據(jù)。

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

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

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

如分庫分表的管理和請求分發(fā)，由 Mycat 實現(xiàn)，SQL 的解析由單機的數(shù)據(jù)庫實現(xiàn)，讀寫分離可能由網關和消息隊列來實現(xiàn)，查詢結果的匯總可能由數(shù)據(jù)庫接口層來實現(xiàn)等等，這種架構其實是 MPP(大規(guī)模并行處理)架構的一類實現(xiàn)。

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

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

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

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

數(shù)據(jù)庫和 Tomcat 都能夠水平擴展，可支撐的并發(fā)大幅提高，隨著用戶數(shù)的增長，最終單機的 Nginx 會成為瓶頸。

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

 

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

圖中的 LVS 和 F5 是工作在網絡第四層的負載均衡解決方案，其中 LVS 是軟件，運行在操作系統(tǒng)內核態(tài)，可對 TCP 請求或更高層級的網絡協(xié)議進行轉發(fā)。

因此支持的協(xié)議更豐富，并且性能也遠高于 Nginx，可假設單機的 LVS 可支持幾十萬個并發(fā)的請求轉發(fā);F5 是一種負載均衡硬件，與 LVS 提供的能力類似，性能比 LVS 更高，但價格昂貴。

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

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

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

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

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

由于 LVS 也是單機的，隨著并發(fā)數(shù)增長到幾十萬時，LVS 服務器最終會達到瓶頸，此時用戶數(shù)達到千萬甚至上億級別，用戶分布在不同的地區(qū)，與服務器機房距離不同，導致了訪問的延遲會明顯不同。

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

 

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

當用戶訪問 www.taobao.com 時，DNS 服務器會使用輪詢策略或其他策略，來選擇某個 IP 供用戶訪問。

此方式能實現(xiàn)機房間的負載均衡，至此，系統(tǒng)可做到機房級別的水平擴展，***到億級的并發(fā)量都可通過增加機房來解決，系統(tǒng)入口處的請求并發(fā)量不再是問題。

隨著數(shù)據(jù)的豐富程度和業(yè)務的發(fā)展，檢索、分析等需求越來越豐富，單單依靠數(shù)據(jù)庫無法解決如此豐富的需求。

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

 

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

對于統(tǒng)計報表場景，在數(shù)據(jù)量大時不一定能跑出結果，而且在跑復雜查詢時會導致其他查詢變慢，對于全文檢索、可變數(shù)據(jù)結構等場景，數(shù)據(jù)庫天生不適用。

因此需要針對特定的場景，引入合適的解決方案。如對于海量文件存儲，可通過分布式文件系統(tǒng) HDFS 解決。

對于 Key Value 類型的數(shù)據(jù)，可通過 HBase 和 Redis 等方案解決，對于全文檢索場景，可通過搜索引擎如 ElasticSearch 解決，對于多維分析場景，可通過 Kylin 或 Druid 等方案解決。

當然，引入更多組件同時會提高系統(tǒng)的復雜度，不同的組件保存的數(shù)據(jù)需要同步，需要考慮一致性的問題，需要有更多的運維手段來管理這些組件等。

引入更多組件解決了豐富的需求，業(yè)務維度能夠極大擴充，隨之而來的是一個應用中包含了太多的業(yè)務代碼，業(yè)務的升級迭代變得困難。

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

 

按照業(yè)務板塊來劃分應用代碼，使單個應用的職責更清晰，相互之間可以做到獨立升級迭代。

這時候應用之間可能會涉及到一些公共配置，可以通過分布式配置中心 Zookeeper 來解決。

不同應用之間存在共用的模塊，由應用單獨管理會導致相同代碼存在多份，導致公共功能升級時全部應用代碼都要跟著升級。

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

 

如用戶管理、訂單、支付、鑒權等功能在多個應用中都存在，那么可以把這些功能的代碼單獨抽取出來形成一個單獨的服務來管理。

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

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

不同服務的接口訪問方式不同，應用代碼需要適配多種訪問方式才能使用服務。

此外，應用訪問服務，服務之間也可能相互訪問，調用鏈將會變得非常復雜，邏輯變得混亂。

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

 

通過 ESB 統(tǒng)一進行訪問協(xié)議轉換，應用統(tǒng)一通過 ESB 來訪問后端服務，服務與服務之間也通過 ESB 來相互調用，以此降低系統(tǒng)的耦合程度。

這種單個應用拆分為多個應用，公共服務單獨抽取出來來管理，并使用企業(yè)消息總線來解除服務之間耦合問題的架構，就是所謂的 SOA(面向服務)架構，這種架構與微服務架構容易混淆，因為表現(xiàn)形式十分相似。

個人理解，微服務架構更多是指把系統(tǒng)里的公共服務抽取出來單獨運維管理的思想，而 SOA 架構則是指一種拆分服務并使服務接口訪問變得統(tǒng)一的架構思想，SOA 架構中包含了微服務的思想。

業(yè)務不斷發(fā)展，應用和服務都會不斷變多，應用和服務的部署變得復雜，同一臺服務器上部署多個服務還要解決運行環(huán)境沖突的問題。

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

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

 

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

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

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

在大促之前，可以在現(xiàn)有的機器集群上劃分出服務器來啟動 Docker 鏡像，增強服務的性能，大促過后就可以關閉鏡像，對機器上的其他服務不造成影響(在之前，服務運行在新增機器上需要修改系統(tǒng)配置來適配服務，這會導致機器上其他服務需要的運行環(huán)境被破壞)。

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

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

 

 

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

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

所謂的云平臺，就是把海量機器資源，通過統(tǒng)一的資源管理，抽象為一個資源整體，在之上可按需動態(tài)申請硬件資源(如 CPU、內存、網絡等)，并且之上提供通用的操作系統(tǒng)。

提供常用的技術組件(如 Hadoop 技術棧，MPP 數(shù)據(jù)庫等)供用戶使用，甚至提供開發(fā)好的應用，用戶不需要關系應用內部使用了什么技術，就能夠解決需求(如音視頻轉碼服務、郵件服務、個人博客等)。

在云平臺中會涉及如下幾個概念：

• IaaS：基礎設施即服務。對應于上面所說的機器資源統(tǒng)一為資源整體，可動態(tài)申請硬件資源的層面。
• PaaS：平臺即服務。對應于上面所說的提供常用的技術組件方便系統(tǒng)的開發(fā)和維護。
• SaaS：軟件即服務。對應于上面所說的提供開發(fā)好的應用或服務，按功能或性能要求付費。

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

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

架構設計總結

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

不是的，以上所說的架構演變順序只是針對某個側面進行單獨的改進，在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。

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

②對于將要實施的系統(tǒng)，架構應該設計到什么程度?

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

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

③服務端架構和大數(shù)據(jù)架構有什么區(qū)別?

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

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

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

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

④有沒有一些架構設計的原則?

設計原則如下：

• N+1 設計。系統(tǒng)中的每個組件都應做到沒有單點故障。
• 回滾設計。確保系統(tǒng)可以向前兼容，在系統(tǒng)升級時應能有辦法回滾版本。
• 禁用設計。應該提供控制具體功能是否可用的配置，在系統(tǒng)出現(xiàn)故障時能夠快速下線功能。
• 監(jiān)控設計。在設計階段就要考慮監(jiān)控的手段。
• 多活數(shù)據(jù)中心設計。若系統(tǒng)需要極高的高可用，應考慮在多地實施數(shù)據(jù)中心進行多活，至少在一個機房斷電的情況下系統(tǒng)依然可用。
• 采用成熟的技術。剛開發(fā)的或開源的技術往往存在很多隱藏的 Bug，出了問題沒有商業(yè)支持可能會是一個災難。
• 資源隔離設計。應避免單一業(yè)務占用全部資源。
• 架構應能水平擴展。系統(tǒng)只有做到能水平擴展，才能有效避免瓶頸問題。
• 非核心則購買。非核心功能若需要占用大量的研發(fā)資源才能解決，則考慮購買成熟的產品。
• 使用商用硬件。商用硬件能有效降低硬件故障的機率。
• 快速迭代。系統(tǒng)應該快速開發(fā)小功能模塊，盡快上線進行驗證，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風險。
• 無狀態(tài)設計。服務接口應該做成無狀態(tài)的，當前接口的訪問不依賴于接口上次訪問的狀態(tài)。

作者：歐仕華

簡介：在大數(shù)據(jù)領域具有多年的開發(fā)經驗，對常用大數(shù)據(jù)技術都有所了解，在架構設計、高并發(fā)、分布式等方面具有一定經驗。喜歡學習新技術，樂于分享，歡迎關注我的 SegmentFault 博客：huashiou。