1. 概述
本文以淘寶作為例子喇完，介紹從一百個并發(fā)到千萬級并發(fā)情況下服務端的架構的演進過程枕荞，同時列舉出每個演進階段會遇到的相關技術线欲，讓大家對架構的演進有一個整體的認知造烁，文章最后匯總了一些架構設計的原則辐宾。
2. 基本概念
在介紹架構之前狱从，為了避免部分讀者對架構設計中的一些概念不了解，下面對幾個最基礎的概念進行介紹：
-
分布式
系統(tǒng)中的多個模塊在不同服務器上部署叠纹，即可稱為分布式系統(tǒng)季研，如Tomcat和數據庫分別部署在不同的服務器上，或兩個相同功能的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ā)起的訪問沥阱，此時代理服務器實現的是正向代理缎罢；當外部請求進入系統(tǒng)時，代理服務器把該請求轉發(fā)到系統(tǒng)中的某臺服務器上考杉，對外部請求來說策精，與之交互的只有代理服務器，此時代理服務器實現的是反向代理崇棠。簡單來說咽袜，正向代理是代理服務器代替系統(tǒng)內部來訪問外部網絡的過程，反向代理是外部請求訪問系統(tǒng)時通過代理服務器轉發(fā)到內部服務器的過程易茬。
3. 架構演進
3.1 單機架構
以淘寶作為例子。在網站最初時及老，應用數量與用戶數都較少抽莱，可以把Tomcat和數據庫部署在同一臺服務器上。瀏覽器往www.taobao.com發(fā)起請求時骄恶，首先經過DNS服務器（域名系統(tǒng)）把域名轉換為實際IP地址10.102.4.1食铐，瀏覽器轉而訪問該IP對應的Tomcat。
隨著用戶數的增長僧鲁，Tomcat和數據庫之間競爭資源虐呻，單機性能不足以支撐業(yè)務
3.2 第一次演進：Tomcat與數據庫分開部署
Tomcat和數據庫分別獨占服務器資源象泵，顯著提高兩者各自性能。
隨著用戶數的增長斟叼，并發(fā)讀寫數據庫成為瓶頸
3.3 第二次演進：引入本地緩存和分布式緩存
在Tomcat同服務器上或同JVM中增加本地緩存偶惠，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的html頁面等朗涩。通過緩存能把絕大多數請求在讀寫數據庫前攔截掉忽孽，大大降低數據庫壓力。其中涉及的技術包括：使用memcached作為本地緩存谢床，使用Redis作為分布式緩存兄一，還會涉及緩存一致性、緩存穿透/擊穿识腿、緩存雪崩出革、熱點數據集中失效等問題。
緩存抗住了大部分的訪問請求渡讼，隨著用戶數的增長骂束，并發(fā)壓力主要落在單機的Tomcat上，響應逐漸變慢
3.4 第三次演進：引入反向代理實現負載均衡
![]()
img
在多臺服務器上分別部署Tomcat硝全，使用反向代理軟件（Nginx）把請求均勻分發(fā)到每個Tomcat中栖雾。此處假設Tomcat最多支持100個并發(fā)，Nginx最多支持50000個并發(fā)伟众，那么理論上Nginx把請求分發(fā)到500個Tomcat上析藕，就能抗住50000個并發(fā)。其中涉及的技術包括：Nginx凳厢、HAProxy账胧，兩者都是工作在網絡第七層的反向代理軟件，主要支持http協議先紫，還會涉及session共享治泥、文件上傳下載的問題。
反向代理使應用服務器可支持的并發(fā)量大大增加遮精，但并發(fā)量的增長也意味著更多請求穿透到數據庫居夹，單機的數據庫最終成為瓶頸
3.5 第四次演進：數據庫讀寫分離
把數據庫劃分為讀庫和寫庫，讀庫可以有多個本冲，通過同步機制把寫庫的數據同步到讀庫准脂，對于需要查詢最新寫入數據場景，可通過在緩存中多寫一份檬洞，通過緩存獲得最新數據狸膏。其中涉及的技術包括：Mycat，它是數據庫中間件添怔，可通過它來組織數據庫的分離讀寫和分庫分表湾戳，客戶端通過它來訪問下層數據庫贤旷，還會涉及數據同步，數據一致性的問題砾脑。
業(yè)務逐漸變多幼驶，不同業(yè)務之間的訪問量差距較大，不同業(yè)務直接競爭數據庫拦止，相互影響性能
3.6 第五次演進：數據庫按業(yè)務分庫
把不同業(yè)務的數據保存到不同的數據庫中县遣，使業(yè)務之間的資源競爭降低，對于訪問量大的業(yè)務汹族，可以部署更多的服務器來支撐萧求。這樣同時導致跨業(yè)務的表無法直接做關聯分析，需要通過其他途徑來解決顶瞒，但這不是本文討論的重點夸政，有興趣的可以自行搜索解決方案。
隨著用戶數的增長榴徐，單機的寫庫會逐漸會達到性能瓶頸
3.7 第六次演進：把大表拆分為小表
比如針對評論數據守问，可按照商品ID進行hash，路由到對應的表中存儲坑资；針對支付記錄耗帕，可按照小時創(chuàng)建表，每個小時表繼續(xù)拆分為小表袱贮，使用用戶ID或記錄編號來路由數據仿便。只要實時操作的表數據量足夠小，請求能夠足夠均勻的分發(fā)到多臺服務器上的小表攒巍，那數據庫就能通過水平擴展的方式來提高性能嗽仪。其中前面提到的Mycat也支持在大表拆分為小表情況下的訪問控制。
這種做法顯著的增加了數據庫運維的難度柒莉，對DBA的要求較高闻坚。數據庫設計到這種結構時，已經可以稱為分布式數據庫兢孝，但是這只是一個邏輯的數據庫整體窿凤，數據庫里不同的組成部分是由不同的組件單獨來實現的，如分庫分表的管理和請求分發(fā)跨蟹，由Mycat實現雳殊，SQL的解析由單機的數據庫實現，讀寫分離可能由網關和消息隊列來實現喷市，查詢結果的匯總可能由數據庫接口層來實現等等相种，這種架構其實是MPP（大規(guī)模并行處理）架構的一類實現威恼。
目前開源和商用都已經有不少MPP數據庫品姓，開源中比較流行的有Greenplum寝并、TiDB、Postgresql XC腹备、HAWQ等衬潦，商用的如南大通用的GBase、睿帆科技的雪球DB植酥、華為的LibrA等等镀岛，不同的MPP數據庫的側重點也不一樣，如TiDB更側重于分布式OLTP場景友驮，Greenplum更側重于分布式OLAP場景漂羊，這些MPP數據庫基本都提供了類似Postgresql、Oracle卸留、MySQL那樣的SQL標準支持能力走越，能把一個查詢解析為分布式的執(zhí)行計劃分發(fā)到每臺機器上并行執(zhí)行，最終由數據庫本身匯總數據進行返回耻瑟，也提供了諸如權限管理、分庫分表、事務医增、數據副本等能力虾攻，并且大多能夠支持100個節(jié)點以上的集群，大大降低了數據庫運維的成本框都，并且使數據庫也能夠實現水平擴展搬素。
數據庫和Tomcat都能夠水平擴展，可支撐的并發(fā)大幅提高瞬项，隨著用戶數的增長蔗蹋，最終單機的Nginx會成為瓶頸
3.8 第七次演進：使用LVS或F5來使多個Nginx負載均衡
由于瓶頸在Nginx，因此無法通過兩層的Nginx來實現多個Nginx的負載均衡囱淋。圖中的LVS和F5是工作在網絡第四層的負載均衡解決方案猪杭，其中LVS是軟件，運行在操作系統(tǒng)內核態(tài)妥衣，可對TCP請求或更高層級的網絡協議進行轉發(fā)皂吮，因此支持的協議更豐富，并且性能也遠高于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實現高可用掰读，其他的Nginx接另外的Tomcat秘狞，這樣可接入的Tomcat數量就能成倍的增加。
由于LVS也是單機的蹈集，隨著并發(fā)數增長到幾十萬時烁试，LVS服務器最終會達到瓶頸，此時用戶數達到千萬甚至上億級別拢肆，用戶分布在不同的地區(qū)减响，與服務器機房距離不同，導致了訪問的延遲會明顯不同
3.9 第八次演進：通過DNS輪詢實現機房間的負載均衡
在DNS服務器中可配置一個域名對應多個IP地址郭怪，每個IP地址對應到不同的機房里的虛擬IP支示。當用戶訪問www.taobao.com時，DNS服務器會使用輪詢策略或其他策略鄙才，來選擇某個IP供用戶訪問颂鸿。此方式能實現機房間的負載均衡，至此攒庵，系統(tǒng)可做到機房級別的水平擴展嘴纺，千萬級到億級的并發(fā)量都可通過增加機房來解決，系統(tǒng)入口處的請求并發(fā)量不再是問題浓冒。
隨著數據的豐富程度和業(yè)務的發(fā)展栽渴，檢索、分析等需求越來越豐富稳懒，單單依靠數據庫無法解決如此豐富的需求
3.10 第九次演進：引入NoSQL數據庫和搜索引擎等技術
當數據庫中的數據多到一定規(guī)模時闲擦，數據庫就不適用于復雜的查詢了，往往只能滿足普通查詢的場景。對于統(tǒng)計報表場景墅冷，在數據量大時不一定能跑出結果贮缕，而且在跑復雜查詢時會導致其他查詢變慢，對于全文檢索俺榆、可變數據結構等場景，數據庫天生不適用装哆。因此需要針對特定的場景罐脊，引入合適的解決方案。如對于海量文件存儲蜕琴，可通過分布式文件系統(tǒng)HDFS解決萍桌，對于key value類型的數據，可通過HBase和Redis等方案解決凌简，對于全文檢索場景上炎，可通過搜索引擎如ElasticSearch解決，對于多維分析場景雏搂，可通過Kylin或Druid等方案解決藕施。
當然，引入更多組件同時會提高系統(tǒng)的復雜度凸郑，不同的組件保存的數據需要同步裳食，需要考慮一致性的問題，需要有更多的運維手段來管理這些組件等芙沥。
引入更多組件解決了豐富的需求诲祸，業(yè)務維度能夠極大擴充，隨之而來的是一個應用中包含了太多的業(yè)務代碼而昨，業(yè)務的升級迭代變得困難
3.11 第十次演進：大應用拆分為小應用
按照業(yè)務板塊來劃分應用代碼救氯，使單個應用的職責更清晰，相互之間可以做到獨立升級迭代歌憨。這時候應用之間可能會涉及到一些公共配置着憨，可以通過分布式配置中心Zookeeper來解決。
不同應用之間存在共用的模塊务嫡，由應用單獨管理會導致相同代碼存在多份享扔，導致公共功能升級時全部應用代碼都要跟著升級
3.12 第十一次演進：復用的功能抽離成微服務
如用戶管理、訂單植袍、支付惧眠、鑒權等功能在多個應用中都存在，那么可以把這些功能的代碼單獨抽取出來形成一個單獨的服務來管理于个，這樣的服務就是所謂的微服務氛魁，應用和服務之間通過HTTP、TCP或RPC請求等多種方式來訪問公共服務，每個單獨的服務都可以由單獨的團隊來管理秀存。此外捶码，可以通過Dubbo、SpringCloud等框架實現服務治理或链、限流惫恼、熔斷、降級等功能澳盐，提高服務的穩(wěn)定性和可用性祈纯。
不同服務的接口訪問方式不同，應用代碼需要適配多種訪問方式才能使用服務叼耙，此外腕窥，應用訪問服務，服務之間也可能相互訪問筛婉，調用鏈將會變得非常復雜簇爆，邏輯變得混亂
3.13 第十二次演進：引入企業(yè)服務總線ESB屏蔽服務接口的訪問差異
通過ESB統(tǒng)一進行訪問協議轉換，應用統(tǒng)一通過ESB來訪問后端服務爽撒，服務與服務之間也通過ESB來相互調用入蛆，以此降低系統(tǒng)的耦合程度。這種單個應用拆分為多個應用硕勿，公共服務單獨抽取出來來管理安寺，并使用企業(yè)消息總線來解除服務之間耦合問題的架構，就是所謂的SOA（面向服務）架構首尼，這種架構與微服務架構容易混淆挑庶，因為表現形式十分相似。個人理解软能，微服務架構更多是指把系統(tǒng)里的公共服務抽取出來單獨運維管理的思想迎捺，而SOA架構則是指一種拆分服務并使服務接口訪問變得統(tǒng)一的架構思想，SOA架構中包含了微服務的思想查排。
業(yè)務不斷發(fā)展凳枝，應用和服務都會不斷變多，應用和服務的部署變得復雜跋核，同一臺服務器上部署多個服務還要解決運行環(huán)境沖突的問題岖瑰，此外，對于如大促這類需要動態(tài)擴縮容的場景砂代，需要水平擴展服務的性能蹋订，就需要在新增的服務上準備運行環(huán)境，部署服務等刻伊，運維將變得十分困難
3.14 第十三次演進：引入容器化技術實現運行環(huán)境隔離與動態(tài)服務管理
目前最流行的容器化技術是Docker露戒，最流行的容器管理服務是Kubernetes(K8S)椒功，應用/服務可以打包為Docker鏡像，通過K8S來動態(tài)分發(fā)和部署鏡像智什。Docker鏡像可理解為一個能運行你的應用/服務的最小的操作系統(tǒng)动漾，里面放著應用/服務的運行代碼，運行環(huán)境根據實際的需要設置好荠锭。把整個“操作系統(tǒng)”打包為一個鏡像后旱眯，就可以分發(fā)到需要部署相關服務的機器上，直接啟動Docker鏡像就可以把服務起起來证九，使服務的部署和運維變得簡單删豺。
在大促的之前，可以在現有的機器集群上劃分出服務器來啟動Docker鏡像甫贯，增強服務的性能，大促過后就可以關閉鏡像看蚜，對機器上的其他服務不造成影響（在3.14節(jié)之前叫搁，服務運行在新增機器上需要修改系統(tǒng)配置來適配服務，這會導致機器上其他服務需要的運行環(huán)境被破壞）供炎。
使用容器化技術后服務動態(tài)擴縮容問題得以解決渴逻，但是機器還是需要公司自身來管理，在非大促的時候音诫，還是需要閑置著大量的機器資源來應對大促惨奕，機器自身成本和運維成本都極高，資源利用率低
3.15 第十四次演進：以云平臺承載系統(tǒng)
系統(tǒng)可部署到公有云上竭钝，利用公有云的海量機器資源梨撞，解決動態(tài)硬件資源的問題，在大促的時間段里香罐，在云平臺中臨時申請更多的資源卧波，結合Docker和K8S來快速部署服務，在大促結束后釋放資源庇茫，真正做到按需付費港粱，資源利用率大大提高，同時大大降低了運維成本旦签。
所謂的云平臺查坪，就是把海量機器資源，通過統(tǒng)一的資源管理宁炫，抽象為一個資源整體偿曙，在之上可按需動態(tài)申請硬件資源（如CPU、內存羔巢、網絡等）遥昧，并且之上提供通用的操作系統(tǒng)覆醇，提供常用的技術組件（如Hadoop技術棧，MPP數據庫等）供用戶使用炭臭，甚至提供開發(fā)好的應用永脓，用戶不需要關系應用內部使用了什么技術，就能夠解決需求（如音視頻轉碼服務鞋仍、郵件服務常摧、個人博客等）。在云平臺中會涉及如下幾個概念：
- IaaS：基礎設施即服務威创。對應于上面所說的機器資源統(tǒng)一為資源整體落午，可動態(tài)申請硬件資源的層面；
- PaaS：平臺即服務肚豺。對應于上面所說的提供常用的技術組件方便系統(tǒng)的開發(fā)和維護溃斋；
- SaaS：軟件即服務。對應于上面所說的提供開發(fā)好的應用或服務吸申，按功能或性能要求付費梗劫。
至此，以上所提到的從高并發(fā)訪問問題截碴，到服務的架構和系統(tǒng)實施的層面都有了各自的解決方案梳侨，但同時也應該意識到，在上面的介紹中日丹，其實是有意忽略了諸如跨機房數據同步走哺、分布式事務實現等等的實際問題，這些問題以后有機會再拿出來單獨討論
4. 架構設計總結
-
架構的調整是否必須按照上述演變路徑進行哲虾？
不是的丙躏，以上所說的架構演變順序只是針對某個側面進行單獨的改進，在實際場景中束凑，可能同一時間會有幾個問題需要解決彼哼，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決湘今。如在政府類的并發(fā)量可能不大敢朱，但業(yè)務可能很豐富的場景，高并發(fā)就不是重點解決的問題摩瞎，此時優(yōu)先需要的可能會是豐富需求的解決方案拴签。 -
對于將要實施的系統(tǒng)，架構應該設計到什么程度旗们？
對于單次實施并且性能指標明確的系統(tǒng)蚓哩，架構設計到能夠支持系統(tǒng)的性能指標要求就足夠了，但要留有擴展架構的接口以便不備之需上渴。對于不斷發(fā)展的系統(tǒng)岸梨，如電商平臺喜颁，應設計到能滿足下一階段用戶量和性能指標要求的程度，并根據業(yè)務的增長不斷的迭代升級架構曹阔，以支持更高的并發(fā)和更豐富的業(yè)務半开。 -
服務端架構和大數據架構有什么區(qū)別？
所謂的“大數據”其實是海量數據采集清洗轉換赃份、數據存儲寂拆、數據分析、數據服務等場景解決方案的一個統(tǒng)稱抓韩，在每一個場景都包含了多種可選的技術纠永，如數據采集有Flume、Sqoop谒拴、Kettle等尝江，數據存儲有分布式文件系統(tǒng)HDFS、FastDFS英上，NoSQL數據庫HBase炭序、MongoDB等，數據分析有Spark技術棧善延、機器學習算法等少态〕遣啵總的來說大數據架構就是根據業(yè)務的需求易遣，整合各種大數據組件組合而成的架構，一般會提供分布式存儲嫌佑、分布式計算豆茫、多維分析、數據倉庫屋摇、機器學習算法等能力揩魂。而服務端架構更多指的是應用組織層面的架構，底層能力往往是由大數據架構來提供炮温。 -
有沒有一些架構設計的原則火脉？
- N+1設計。系統(tǒng)中的每個組件都應做到沒有單點故障柒啤；
- 回滾設計倦挂。確保系統(tǒng)可以向前兼容，在系統(tǒng)升級時應能有辦法回滾版本担巩；
- 禁用設計方援。應該提供控制具體功能是否可用的配置，在系統(tǒng)出現故障時能夠快速下線功能涛癌；
- 監(jiān)控設計犯戏。在設計階段就要考慮監(jiān)控的手段送火；
- 多活數據中心設計。若系統(tǒng)需要極高的高可用先匪，應考慮在多地實施數據中心進行多活种吸，至少在一個機房斷電的情況下系統(tǒng)依然可用；
- 采用成熟的技術胚鸯。剛開發(fā)的或開源的技術往往存在很多隱藏的bug骨稿，出了問題沒有商業(yè)支持可能會是一個災難；
- 資源隔離設計姜钳。應避免單一業(yè)務占用全部資源坦冠；
- 架構應能水平擴展。系統(tǒng)只有做到能水平擴展哥桥，才能有效避免瓶頸問題辙浑；
- 非核心則購買。非核心功能若需要占用大量的研發(fā)資源才能解決拟糕，則考慮購買成熟的產品判呕；
- 使用商用硬件。商用硬件能有效降低硬件故障的機率送滞；
- 快速迭代侠草。系統(tǒng)應該快速開發(fā)小功能模塊，盡快上線進行驗證犁嗅，早日發(fā)現問題大大降低系統(tǒng)交付的風險边涕；
- 無狀態(tài)設計。服務接口應該做成無狀態(tài)的褂微，當前接口的訪問不依賴于接口上次訪問的狀態(tài)功蜓。
原文地址： 服務端高并發(fā)分布式架構的演變過程
感謝！
