目錄

1.單機架構

2.應用數(shù)據(jù)分離架構

3.應用服務集群架構

4.讀寫分離 / 主從分離架構

5.引入緩存 —— 冷熱分離架構

6.垂直分庫

7.業(yè)務拆分 —— 微服務

8.容器化引入——容器編排架構

總結

1.單機架構

????????初期，我們需要利用我們精干的技術團隊，快速將業(yè)務系統(tǒng)投入市場進行檢驗，并且可以迅速響應變化要求。但好在前期用戶訪問量很少，沒有對我們的性能、安全等提出很高的要求，而且系統(tǒng)架構簡單，無需專業(yè)的運維團隊，所以選擇單機架構是合適的。

用戶在瀏覽器中輸入 www.baidu.com，首先經(jīng)過 DNS 服務將域名解析成 IP 地址10.102.41.1，隨后瀏覽器訪問該 IP 對應的應用服務。

優(yōu)點：部署簡單，成本低

缺點：存在嚴重的性能瓶頸，?數(shù)據(jù)庫和應用互相競爭資源

2.應用數(shù)據(jù)分離架構

????????隨著系統(tǒng)的上線，我們不出意外地獲得了成功。市場上出現(xiàn)了一批忠實于我們的用戶，使得系統(tǒng)的訪問量逐步上升，逐漸逼近了硬件資源的極限，同時團隊也在此期間積累了對業(yè)務流程的一批經(jīng)驗。面對當前的性能壓力，我們需要未雨綢繆去進行系統(tǒng)重構、架構挑戰(zhàn)，以提升系統(tǒng)的承載能力。但由于預算仍然很緊張，我們選擇了將應用和數(shù)據(jù)分離的做法，可以最小代價的提升系統(tǒng)的承載能力。

和之前架構的主要區(qū)別在于將數(shù)據(jù)庫服務獨立部署在同一個數(shù)據(jù)中心的其他服務器上，應用服務通過網(wǎng)絡訪問數(shù)據(jù)。

優(yōu)點：成本相對可控，性能相比單機有提升，數(shù)據(jù)庫單獨隔離，不會因為應用把數(shù)據(jù)庫搞壞，有一定的容災能力

缺點：硬件成本變高，性能有瓶頸，無法應對海量并發(fā)

3.應用服務集群架構

????????我們的系統(tǒng)受到了用戶的歡迎，并且出現(xiàn)了爆款，單臺應用服務器已經(jīng)無法滿足需求了。我們的單機應用服務器首先遇到了瓶頸，擺在我們技術團隊面前的有兩種方案，大家針對方案的優(yōu)劣展示了熱烈的討論：
? 垂直擴展 / 縱向擴展 Scale Up。通過購買性能更優(yōu)、價格更高的應用服務器來應對更多的流量。這種方案的優(yōu)勢在于完全不需要對系統(tǒng)軟件做任何的調整；但劣勢也很明顯：硬件性能和價格的增長關系是非線性的，意味著選擇性能 2 倍的硬件可能需要花費超過 4 倍的價格，其次硬件性能提升是有明顯上限的。
? 水平擴展 / 橫向擴展 Scale Out。通過調整軟件架構，增加應用層硬件，將用戶流量分擔到不同的應用層服務器上，來提升系統(tǒng)的承載能力。這種方案的優(yōu)勢在于成本相對較低，并且提升的上限空間也很大。但劣勢是帶給系統(tǒng)更多的復雜性，需要技術團隊有更豐富的經(jīng)驗。經(jīng)過團隊的學習、調研和討論，最終選擇了水平擴展的方案，來解決該問題，但這需要引入一個新的組件 —— 負載均衡：為了解決用戶流量向哪臺應用服務器分發(fā)的問題，需要一個專門的系統(tǒng)組件做流量分發(fā)。實際中負載均衡不僅僅指的是工作在應用層的，甚至可能是其他的網(wǎng)絡層之中。同時流量調度算法也有很多種，這里簡單介紹幾種較為常見的：
? Round-Robin 輪詢算法。即非常公平地將請求依次分給不同的應用服務器。
? Weight-Round-Robin 輪詢算法。為不同的服務器（比如性能不同）賦予不同的權
重（weight），能者多勞。
? 一致哈希散列算法。通過計算用戶的特征值（比如 IP 地址）得到哈希值，根據(jù)哈希結果做分發(fā)，優(yōu)點是確保來自相同用戶的請求總是被分給指定的服務器。也就是我們平時遇到的專項客戶經(jīng)理服務。

優(yōu)點：?應用服務高可用：應用滿足高可用，不會一個服務出問題整個站點掛掉；應用服務具備一定高性能：如果不訪問數(shù)據(jù)庫，應用相關處理通過擴展可以支持海量請求快速響應；應用服務有一定擴展能力：支持橫向擴展

缺點：數(shù)據(jù)庫成為性能瓶頸，無法應對數(shù)據(jù)庫的海量查詢；數(shù)據(jù)庫是單點，沒有高可用；運維工作增多，擴展后部署運維工作增多，需要開發(fā)對應的工具應對快速部署；硬件成本較高

4.讀寫分離 / 主從分離架構

????????前面提到，我們把用戶的請求通過負載均衡分發(fā)到不同的應用服務器之后，可以并行處理了，并且可以隨著業(yè)務的增長，可以動態(tài)擴張服務器的數(shù)量來緩解壓力。但是現(xiàn)在的架構里，無論擴展多少臺服務器，這些請求最終都會從數(shù)據(jù)庫讀寫數(shù)據(jù)，到一定程度之后，數(shù)據(jù)的壓力稱為系統(tǒng)承載能力的瓶頸點。我們可以像擴展應用服務器一樣擴展數(shù)據(jù)庫服務器么？答案是否定的，因為數(shù)據(jù)庫服務有其特殊性：如果將數(shù)據(jù)分散到各臺服務器之后，數(shù)據(jù)的一致性將無法得到保障。所謂數(shù)據(jù)的一致性，此處是指：針對同一個系統(tǒng)，無論何時何地，我們都應該看到一個始終維持統(tǒng)一的數(shù)據(jù)。想象一下，銀行管理的賬戶金額，如果收到一筆轉賬之后，一份數(shù)據(jù)庫的數(shù)據(jù)修改了，但另外的數(shù)據(jù)庫沒有修改，則用戶得到的存款金額將是錯誤的。我們采用的解決辦法是這樣的，保留一個主要的數(shù)據(jù)庫作為寫入數(shù)據(jù)庫，其他的數(shù)據(jù)庫作為從屬數(shù)據(jù)庫。從庫的所有數(shù)據(jù)全部來自主庫的數(shù)據(jù)，經(jīng)過同步后，從庫可以維護著與主庫一致的數(shù)據(jù)。然后為了分擔數(shù)據(jù)庫的壓力，我們可以將寫數(shù)據(jù)請求全部交給主庫處理，但讀請求分散到各個從庫中。由于大部分的系統(tǒng)中，讀寫請求都是不成比例的，例如 100 次讀 1 次寫，所以只要將讀請求由各個從庫分擔之后，數(shù)據(jù)庫的壓力就沒有那么大了。當然這個過程不是無代價的，主庫到從庫的數(shù)據(jù)同步其實是有時間成本的，但這個問題我們暫時不做進一步探討。

優(yōu)點：?數(shù)據(jù)庫的讀取性能提升；讀取被其他服務器分擔，寫的性能間接提升；數(shù)據(jù)庫有從庫，數(shù)據(jù)庫的可用性提高了

缺點：熱點數(shù)據(jù)的頻繁讀取導致數(shù)據(jù)庫負載很高；當同步掛掉，或者同步延遲比較大時，寫庫和讀庫的數(shù)據(jù)不一致；服務器成本需要進一步增加

5.引入緩存 —— 冷熱分離架構

????????隨著訪問量繼續(xù)增加，發(fā)現(xiàn)業(yè)務中一些數(shù)據(jù)的讀取頻率遠大于其他數(shù)據(jù)的讀取頻率。我們把這部分數(shù)據(jù)稱為熱點數(shù)據(jù)，與之相對應的是冷數(shù)據(jù)。針對熱數(shù)據(jù)，為了提升其讀取的響應時間，可以增加本地緩存，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的 html 頁面等。通過緩存能把絕大多數(shù)請求在讀寫數(shù)據(jù)庫前攔截掉，大大降低數(shù)據(jù)庫壓力。其中涉及的技術包括：使用 memcached 作為本地緩存，使用Redis 作為分布式緩存，還會涉及緩存一致性、緩存穿透/擊穿、緩存雪崩、熱點數(shù)據(jù)集中失效等問題。

優(yōu)點：大幅降低對數(shù)據(jù)庫的訪問請求，性能提升非常明顯；

缺點：帶來了緩存一致性，緩存擊穿，緩存失效，緩存雪崩等問題；服務器成本需要進一步增加；業(yè)務體量支持變大后，數(shù)據(jù)不斷增加，數(shù)據(jù)庫單庫太大，單個表體量也太大，數(shù)據(jù)查詢會很慢，導致數(shù)據(jù)庫再度成為系統(tǒng)瓶頸?

6.垂直分庫

????????隨著業(yè)務的數(shù)據(jù)量增大，大量的數(shù)據(jù)存儲在同一個庫中已經(jīng)顯得有些力不從心了，所以可以按照業(yè)務，將數(shù)據(jù)分別存儲。比如針對評論數(shù)據(jù)，可按照商品 ID 進行 hash，路由到對應的表中存儲；針對支付記錄，可按照小時創(chuàng)建表，每個小時表繼續(xù)拆分為小表，使用用戶 ID 或記錄編號來路由數(shù)據(jù)。只要實時操作的表數(shù)據(jù)量足夠小，請求能夠足夠均勻的分發(fā)到多臺服務器上的小表，那數(shù)據(jù)庫就能通過水平擴展的方式來提高性能。其中前面提到的 Mycat 也支持在大表拆分為小表情況下的訪問控制。這種做法顯著的增加了數(shù)據(jù)庫運維的難度，對 DBA 的要求較高。數(shù)據(jù)庫設計到這種結構時，已經(jīng)可以稱為分布式數(shù)據(jù)庫，但是這只是一個邏輯的數(shù)據(jù)庫整體，數(shù)據(jù)庫里不同的組成部分是由不同的組件單獨來實現(xiàn)的，如分庫分表的管理和請求分發(fā)，由 Mycat 實現(xiàn)，SQL 的解析由單機的數(shù)據(jù)庫實現(xiàn)，讀寫分離可能由網(wǎng)關和消息隊列來實現(xiàn)，查詢結果的匯總可能由數(shù)據(jù)庫接口層來實現(xiàn)等等，這種架構其實是 MPP（大規(guī)模并行處理）架構的一類實現(xiàn)。

優(yōu)點：數(shù)據(jù)庫吞吐量大幅提升，不再是瓶頸；

缺點：跨庫join、分布式事務等問題，這些需要對應的去進行解決，目前的mpp都有對應的解決方案；數(shù)據(jù)庫和緩存結合目前能夠抗住海量的請求，但是應用的代碼整體耦合在一起，修改一行代碼需要整體重新發(fā)布?

7.業(yè)務拆分 —— 微服務

????????隨著人員增加，業(yè)務發(fā)展，我們將業(yè)務分給不同的開發(fā)團隊去維護，每個團隊獨立實現(xiàn)自己的微服務，然后互相之間對數(shù)據(jù)的直接訪問進行隔離，可以利用 Gateway、消息總線等技術，實現(xiàn)相互之間的調用關聯(lián)。甚至可以把一些類似用戶管理等業(yè)務提成公共服務。

優(yōu)點：?靈活性高：服務獨立測試、部署、升級、發(fā)布；獨立擴展：每個服務可以各自進行擴展；提高容錯性：一個服務問題并不會讓整個系統(tǒng)癱瘓；新技術的應用容易:支持多種編程語言

缺點：運維復雜度高：業(yè)務不斷發(fā)展，應用和服務都會不斷變多，應用和服務的部署變得復雜，同一臺服務器上部署多個服務還要解決運行環(huán)境沖突的問題，此外，對于如大促這類需要動態(tài)擴縮容的場景，需要水平擴展服務的性能，就需要在新增的服務上準備運行環(huán)境，部署服務等，運維將變得十分困難；資源使用變多：所有這些獨立運行的微服務都需要需要占用內存和 CPU ；處理故障困難：一個請求跨多個服務調用，需要查看不同服務的日志完成問題定位

8.容器化引入——容器編排架構

????????隨著業(yè)務增長，然后發(fā)現(xiàn)系統(tǒng)的資源利用率不高，很多資源用來應對短時高并發(fā)，平時又閑置，需要動態(tài)擴縮容，還沒有辦法直接下線服務器，而且開發(fā)、測試、生產(chǎn)每套環(huán)境都要隔離的環(huán)境，運維的工作量變的非常大。容器化技術的出現(xiàn)給這些問題的解決帶來了新的思路。
????????目前最流行的容器化技術是 Docker，最流行的容器管理服務是 Kubernetes(K8S)，應用/服務可以打包為 Docker 鏡像，通過 K8S 來動態(tài)分發(fā)和部署鏡像。Docker 鏡像可理解為一個能運行你的應用/服務的最小的操作系統(tǒng)，里面放著應用/服務的運行代碼，運行環(huán)境根據(jù)實際的需要設置好。把整個“操作系統(tǒng)”打包為一個鏡像后，就可以分發(fā)到需要部署相關服務的機器上，直接啟動 Docker 鏡像就可以把服務起起來，使服務的部署和運維變得簡單。服務
????????通常會有生產(chǎn)和研發(fā) k8s 集群，一般不會公用，而研發(fā)集群通過命名空間來完成應用隔離，有的公司按照研發(fā)目的劃分為研發(fā)和測試集群，有的公司通過組織架構完成部門間的資源復用。

優(yōu)點：部署、運維簡單快速：一條命令就可以完成幾百個服務的部署或者擴縮容；隔離性好：容器與容器之間文件系統(tǒng)、網(wǎng)絡等互相隔離，不會產(chǎn)生環(huán)境沖突；輕松支持滾動更新：版本間切換都可以通過一個命令完成升級或者回滾

缺點：技術棧變多，對研發(fā)團隊要求高；機器還是需要公司自身來管理，在非大促的時候，還是需要閑置著大量的機器資源來應對大促，機器自身成本和運維成本都極高，資源利用率低，可以通過購買云廠商服務器解決。?

總結

????????至此，一個還算合理的高可用、高并發(fā)系統(tǒng)的基本雛形已顯。注意，以上所說的架構演變順序只是針對某個側面進行單獨的改進，在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。如在政府類的并發(fā)量可能不大，但業(yè)務可能很豐富的場景，高并發(fā)就不是重點解決的問題，此時優(yōu)先需要的可能會是豐富需求的解決方案。對于單次實施并且性能指標明確的系統(tǒng)，架構設計到能夠支持系統(tǒng)的性能指標要求就足夠了，但要留有擴展架構的接口以便不備之需。對于不斷發(fā)展的系統(tǒng)，如電商平臺，應設計到能滿足下一階段用戶量和性能指標要求的程度，并根據(jù)業(yè)務的增長不斷的迭代升級架構，以支持更高的并發(fā)和更豐富的業(yè)務。所謂的“大數(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 技術棧、機器學習算法等?？偟膩碚f大數(shù)據(jù)架構就是根據(jù)業(yè)務的需求，整合各種大數(shù)據(jù)組件組合而成的架構，一般會提供分布式存儲、分布式計算、多維分析、數(shù)據(jù)倉庫、機器學習算法等能力。而服務端架構更多指的是應用組織層面的架構，底層能力往往是由大數(shù)據(jù)架構來提供。文章來源地址http://www.zghlxwxcb.cn/news/detail-765560.html

到了這里，關于單機架構到分布式架構的演變的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！