【Docker/Redis】服務端高并發分布式結構演進之路

概述

常見概念

基本概念

應用（Application）/ 系統（System）

模塊（Module）/ 組件（Component）

分布式（Distributed）

集群（Cluster）

分布式vs 集群。

主（Master）/ 從（Slave）

中間件（Middleware）

容器（Docker）

容器編排（K8S）

評價指標（Metric）

可用性（Availability）

響應時長（Response Time RT）

吞吐（Throughput）vs 并發（Concurrent）

架構演進

單機架構

出現原因

簡介

技術案例

架構優缺點

相關軟件

應用數據分離架構

出現原因

簡介

技術案例

架構優缺點

應用服務集群架構

出現原因

簡介

技術案例：

架構優缺點

相關軟件

讀寫分離/ 主從分離架構

出現原因

簡介

技術案例

架構優缺點

相關軟件

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

出現原因

簡介

技術案例

架構優缺點：

相關軟件：

垂直分庫

出現原因

簡介

技術案例

架構優缺點

相關軟件

業務拆分—— 微服務

出現原因

簡介

技術案例

架構優缺點

相關軟件

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

出現原因

簡介

技術案例

架構工作原理

架構優缺點

相關軟件

尾聲

概述

在進行技術學習過程中，由于大部分讀者沒有經歷過一些中大型系統的實際經驗，導致無法從全局理解一些概念，所以本文以一個"電子商務" 應用為例，介紹從一百個到千萬級并發情況下服務端的架構的演進過程，同時列舉出每個演進階段會遇到的相關技術，讓大家對架構的演進有一個整體的認知，方便大家對后續知識做深入學習時有一定的整體視野。

常見概念

在正式引入架構演進之前，為避免讀者對架構中的概念完全不了解導致低效溝通，優先對其中一些比較重要的概念做前置介紹：

基本概念

應用（Application）/ 系統（System）

為了完成一整套服務的一個程序或者一組相互配合的程序群。

生活例子類比：為了完成一項任務，而搭建的由一個人或者一群相互配的人組成的團隊。

模塊（Module）/ 組件（Component）

當應用較復雜時，為了分離職責，將其中具有清晰職責的、內聚性強的部分，抽象出概念，便于理解。

生活例子類比：軍隊中為了進行某據點的攻克，將人員分為突擊小組、爆破小組、掩護小組、通信小組等。

分布式（Distributed）

系統中的多個模塊被部署于不同服務器之上，即可以將該系統稱為分布式系統。如Web 服務器與數據庫分別工作在不同的服務器上，或者多臺Web 服務器被分別部署在不同服務器上。

生活例子類比：為了更好的滿足現實需要，一個在同一個辦公場地的工作小組被分散到多個城市的不同工作場地中進行遠程配合工作完成目標。跨主機之間的模塊之間的通信基本要借助網絡支撐完成。

集群（Cluster）

被部署于多臺服務器上的、為了實現特定目標的一個/組特定的組件，整個整體被稱為集群。比如多個MySQL 工作在不同服務器上，共同提供數據庫服務目標，可以被稱為一組數據庫集群。

生活例子類比：為了解決軍隊攻克防守堅固的大城市的作戰目標，指揮部將大批炮兵部隊集中起來形成一個炮兵打擊集群。

分布式vs 集群。

通常不用太嚴格區分兩者的細微概念，細究的話，分布式強調的是物理形態，即工作在不同服務器上并且通過網絡通信配合完成任務；而集群更在意邏輯形態，即是否為了完成特定服務目標。

主（Master）/ 從（Slave）

集群中，通常有一個程序需要承擔更多的職責，被稱為主；其他承擔附屬職責的被稱為從。

比如MySQL 集群中，只有其中一臺服務器上數據庫允許進行數據的寫入（增/刪/改），其他數據庫的數據修改全部要從這臺數據庫同步而來，則把那臺數據庫稱為主庫，其他數據庫稱為從庫。

中間件（Middleware）

一類提供不同應用程序用于相互通信的軟件，即處于不同技術、工具和數據庫之間的橋梁。

生活例子類比：一家飯店開始時，會每天去市場挑選買菜，但隨著飯店業務量變大，成立一個采購部，由采購部專職于采買業務，稱為廚房和菜市場之間的橋梁。

容器（Docker）

Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的鏡像中，然后發布到任何流行的Linux或Windows操作系統的機器上，也可以實現虛擬化。

可以理解為一個集裝箱，集裝箱里面是每個用戶的貨物，整體打包。

容器編排（K8S）

kubernetes，簡稱K8s，是用8代替名字中間的8個字符“ubernete”而成的縮寫。是一個開源的，用于管理云平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單并且高效。

可以理解為一個貨船，安裝集裝箱的大小，貨物情況合理的來組織集裝箱完成整體貨物的搬運。

評價指標（Metric）

可用性（Availability）

考察單位時間段內，系統可以正常提供服務的概率/期望。

例如： 年化系統可用性= 系統正常提供服務時長/ 一年總時長。這里暗含著一個指標，即如何評價系統提供無法是否正常，我們就不深入了。平時我們常說的4 個9 即系統可以提供99.99% 的可用性，5 個9 是99.999% 的可用性，以此類推。我們平時只是用高可用（High Availability HA）這個非量化目標簡要表達我們系統的追求。

響應時長（Response Time RT）

指用戶完成輸入到系統給出用戶反應的時長。

例如點外賣業務的響應時長= 拿到外賣的時刻- 完成點單的時刻。通常我們需要衡量的是最長響應時長、平均響應時長和中位數響應時長。這個指標原則上是越小越好，但很多情況下由于實現的限制，需要根據實際情況具體判斷

吞吐（Throughput）vs 并發（Concurrent）

吞吐考察單位時間段內，系統可以成功處理的請求的數量。并發指系統同一時刻支持的請求最高量。

例如一條2車道高速公路，一分鐘可以通過20 輛車，則并發是2，一分鐘的吞吐量是20。實踐中，并發量往往無法直接獲取，很多時候都是用極短的時間段（比如1 秒）的吞吐量做代替。我們平時用高并發（Hight Concurrnet）這個非量化目標簡要表達系統的追求。

架構演進

單機架構

出現原因

出現在互聯網早期，訪問量比較小，單機足以滿足需求

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

簡介

應用服務和數據庫服務共用一臺服務器，這臺服務器完成所有的工作

技術案例

用戶在瀏覽器中輸入www.bit.com，首先經過DNS 服務將域名解析成IP 地址10.102.41.1，隨后瀏覽器訪問該IP 對應的應用服務（我們通過編程語言完成的程序），應用服務再根據請求通過MySQL查詢數據。

架構優缺點

優點：部署簡單、成本低

缺點：存在嚴重的性能瓶頸、數據庫和應用互相競爭資源

應用數據分離架構

出現原因

單機存在嚴重的資源競爭，導致站點變慢。

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

簡介

應用服務和數據庫服務使用不同服務器

技術案例

用戶在瀏覽器中輸入www.bit.com，首先經過DNS 服務將域名解析成IP 地址10.102.41.1，隨后瀏覽器訪問該IP 對應的應用服務（我們通過編程語言完成的程序），應用服務再根據請求通過網絡訪問數據庫服務器查詢數據。

和之前架構的主要區別在于將數據庫服務獨立部署在同一個數據中心的其他服務器上，。

對于應用服務器來說，往往需要處理更多的業務邏輯，因此更需要CPU、內存資源；而存儲服務器往往是訪問對應的數據，因此需要更大的存儲容量、更快的數據訪問速度，需要可以配合更大硬盤的服務器，甚至還可以上SSD。

這個應用數據分離架構本身不光提升了本身的硬件資源，根據不同的服務特點，我們也可以搭配更加合適的服務器，更具性價比。

架構優缺點

優點：

成本相對可控。

性能相比單機有提升。

數據庫單獨隔離，不會因為應用把數據庫搞壞，有一定的容災能力

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

應用服務集群架構

出現原因

單個應用不足以支持海量的并發請求，高并發的時候站點響應變慢

我們的系統受到了用戶的歡迎，并且出現了爆款，單臺應用服務器已經無法滿足需求了。我們的單機應用服務器首先遇到了瓶頸，擺在我們技術團隊面前的有兩種方案，大家針對方案的優劣展示了熱烈的討論：

? 垂直擴展 / 縱向擴展Scale Up。通過購買性能更優、價格更高的應用服務器來應對更多的流量。

這種方案的優勢在于完全不需要對系統軟件做任何的調整；但劣勢也很明顯：硬件性能和價格的增長關系是非線性的，意味著選擇性能2 倍的硬件可能需要花費超過4 倍的價格，其次硬件性能提升是有明顯上限的。

? 水平擴展 / 橫向擴展Scale Out。通過調整軟件架構，增加應用層硬件，將用戶流量分擔到不同的應用層服務器上，來提升系統的承載能力。

這種方案的優勢在于成本相對較低，并且提升的上限空間也很大。但劣勢是帶給系統更多的復雜性，需要技術團隊有更豐富的經驗。

經過團隊的學習、調研和討論，最終選擇了水平擴展的方案，來解決該問題，但是這又帶來了新的問題，多臺應用服務器同時存在，我們如何保證應用服務器可以同時均衡的工作呢？

不至于出現忙的忙死，閑的閑死，導致資源的浪費？這需要引入一個新的組件—— 負載均衡：為了解決用戶流量向哪臺應用服務器分發的問題，需要一個專門的系統組件做流量分發。（實際中負載均衡不僅僅指的是工作在應用層的，甚至可能是其他的網絡層之中。）

同時流量調度算法也有很多種，這里簡單介紹幾種較為常見的：

? Round-Robin 輪詢算法。即非常公平地將請求依次分給不同的應用服務器。

? Weight-Round-Robin 輪詢算法。為不同的服務器（比如性能不同）賦予不同的權重（weight），能者多勞。

? 一致哈希散列算法。通過計算用戶的特征值（比如IP 地址）得到哈希值，根據哈希結果做分發，優點是確保來自相同用戶的請求總是被分給指定的服務器。也就是我們平時遇到的專項客戶經理服務。

簡介

引入了負載均衡，應用以集群方式運作

技術案例：

用戶在瀏覽器中輸入www.bit.com，首先經過DNS 服務將域名解析成IP 地址10.102.41.1，隨后瀏覽器訪問該IP 發送請求，請求被負載均衡組件接受，并通過算法，合理派發到臺應用服務器上（比如采用輪詢的方式，將每次的請求挨個派發給應用服務器），應用服務器在根據網絡訪問數據服務器。

注：這里的負載均衡也是部署在獨立的服務器上的，有的人到這可能會疑問：負載均衡不是需要接收所有的請求再進行派發嗎？那負載均衡的服務器可以承受住壓力嗎？

其實負載均衡本身只是進行派發，不進行詳細的業務處理，實際單個請求承受的壓力會小很多。如果壓力過大，我們也可以在每一層上多加一些負載均衡器，如果再大，我們可以考慮在當前負載均衡層上抽象出一層負載均衡軟件層，請求會想通過某一個新負載均衡器，如上圖的LVS/F5，再由其通過算法派發給下一層上的某一個負載均衡器Nginx。比起在一層上堆積負載均衡器，這種多級層狀設計是指數的提升，往往再大的請求量，一般最多三層負載均衡層就夠了。

架構優缺點

優點：

應用服務高可用：應用滿足高可用，不會一個服務出問題整個站點掛掉。

應用服務具備一定高性能：如果不訪問數據庫，應用相關處理通過擴展可以支持海量請求快速響應。

應用服務有一定擴展能力：支持橫向擴展

缺點：

數據庫成為性能瓶頸，無法應對數據庫的海量查詢。

數據庫是單點，沒有高可用。

運維工作增多，擴展后部署運維工作增多，需要開發對應的工具應對快速部署。

硬件成本較高

讀寫分離/ 主從分離架構

出現原因

數據庫成為瓶頸，而互聯網應用一般讀多寫少，數據庫承載壓力大，主要是由這些讀的請求造成的，那么我們可以把讀操作和寫操作分開

上文提到，我們把用戶的請求通過負載均衡分發到不同的應用服務器之后，可以并行處理了，并且可以隨著業務的增長，可以動態擴張服務器的數量來緩解壓力。但是現在的架構里，無論擴展多少臺服務器，這些請求最終都會從同一個數據庫讀寫數據，到一定程度之后，數據的壓力會超過系統承載能力的瓶頸點。

那我們可以像擴展應用服務器一樣擴展數據庫服務器么？答案是否定的，因為數據庫服務有其特殊性：如果將數據分散到各臺服務器之后，數據的一致性將無法得到保障。所謂數據的一致性，此處是指：針對同一個系統，無論何時何地，我們都應該看到一個始終維持統一的數據。想象一下，銀行管理的賬戶金額，如果收到一筆轉賬之后，一份數據庫的數據修改了，但另外的數據庫沒有修改，則用戶得到的存款金額將是錯誤的。

我們采用的解決辦法是這樣的，保留一個主要的數據庫作為寫入數據庫，其他的數據庫作為從屬數據庫。從庫的所有數據全部來自主庫的數據，經過同步后，從庫可以維護著與主庫一致的數據。然后為了分擔數據庫的壓力，我們可以將寫數據請求全部交給主庫處理，但讀請求分散到各個從庫中。由于大部分的系統中，讀寫請求都是不成比例的，例如100 次讀往往只會有1 次寫，所以只要將讀請求由各個從庫分擔之后，數據庫的壓力就沒有那么大了。當然這個過程不是無代價的，主庫到從庫的數據同步是通過網絡進行的，其實是有時間以及其他成本的，但這個問題我們暫時不做進一步探討。

簡介

將數據庫讀寫操作分散到不同的節點上，數據庫服務器搭建主從集群，一主一從、一主多從都可以，數據庫主機負責寫操作，從機只負責讀操作

技術案例

用戶在瀏覽器中輸入www.bit.com，首先經過DNS 服務將域名解析成IP 地址10.102.41.1，隨后瀏覽器訪問該IP 發送請求，請求被負載均衡組件接受，并通過算法，合理派發到每臺應用服務器上，應用中需要對讀寫請求做分離處理，所以可以利用一些數據庫中間件，將請求分離的職責托管出去，請求通過數據庫中間件，寫請求會被派發到主數據庫，讀請求會被派發到從數據庫，因為讀數據需要較大，我們可以設置多個從數據庫服務器，如果這個過程中主數據發生修改，會進行數據同步。

架構優缺點

優點：

數據庫的讀取性能提升、讀取被其他服務器分擔，寫的性能間接提升。

數據庫有從庫，數據庫的可用性提高了

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

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

出現原因

海量的請求導致數據庫負載過高，站點響應再度變慢

隨著訪問量繼續增加，發現業務中一些數據的讀取頻率遠大于其他數據的讀取頻率。我們把這部分數據稱為熱點數據，與之相對應的是冷數據。計算機中這部分存在一個二八定律：20%的數據能支撐80%的訪問率，有的甚至能達到一比九。所以這些熱數據的請求往往是大量重復的，而訪問數據往往是貫穿整個架構的，尤其是存儲服務器層的IO是非常耗時的，所以重復請求造成巨大的浪費以及壓力

所以針對熱數據，為了提升其讀取的響應時間，可以增加本地緩存，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的html 頁面等。通過緩存能把絕大多數請求在讀寫數據庫前攔截掉，大大降低數據庫壓力。

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

簡介

引入緩存，實行冷熱分離，將熱點數據放到緩存中快速響應

技術案例

用戶在瀏覽器中輸入www.bit.com，首先經過DNS 服務將域名解析成IP 地址10.102.41.1，隨后瀏覽器訪問該IP 發送請求，請求被負載均衡組件接收，并通過算法，合理派發到每臺應用服務器上

如果當前的數據能夠在緩存中獲取到，則直接將數據返回給上層，不在訪問數據庫，如果是冷數據，則請求通過數據庫中間件，寫請求會被派發到主數據庫，讀請求會被派發到從數據庫。

注：這里的緩存也是單獨部署在一臺服務器上的，可以有多個緩存，這里的緩存之所以效率可以比數據庫查詢的效率高，是因為緩存是內存存儲，請求直接在內存中查找數據，不需要IO,效率大大提高，但是內存本身價格較高且存儲空間小據，所以適合儲存熱數。

架構優缺點：

優點：

大幅降低對數據庫的訪問請求，性能提升非常明顯

缺點：

帶來了緩存一致性，緩存擊穿，緩存失效，緩存雪崩等問題。

服務器成本需要進一步增加。

業務體量支持變大后，數據不斷增加，數據庫單庫太大，單個表體量也太大，數據查詢會很慢，導致數據庫再度成為系統瓶頸

垂直分庫

出現原因

單機的寫庫會逐漸會達到性能瓶頸，需要拆分數據庫，數據表的數據量太大，處理壓力太大，需要進行分表，為降低運維難度，業界逐漸研發了分布式數據庫，庫表天然支持分布式

隨著業務的數據量增大，大量的數據存儲在同一個庫中已經顯得有些力不從心了，所以可以按照業務，將數據分別存儲。

比如針對評論數據，可按照商品ID進行hash，路由到對應的表中存儲；針對支付記錄，可按照小時創建表，每個小時表繼續拆分為小表，使用用戶ID或記錄編號來路由數據。只要實時操作的表數據量足夠小，請求能夠足夠均勻的分發到多臺服務器上的小表，那數據庫就能通過水平擴展的方式來提高性能。

其中前面提到的Mycat也支持在大表拆分為小表情況下的訪問控制。這種做法顯著的增加了數據庫運維的難度，對DBA的要求較高。數據庫設計到這種結構時，已經可以稱為分布式數據庫，但是這只是一個邏輯的數據庫整體，數據庫里不同的組成部分是由不同的組件單獨來實現的，如分庫分表的管理和請求分發，由Mycat實現，SQL的解析由單機的數據庫實現，讀寫分離可能由網關和消息隊列來實現，查詢結果的匯總可能由數據庫接口層來實現等等，這種架構其實是MPP（大規模并行處理）架構的一類實現。

簡介

數據庫的數據被拆分，數據庫數據分布式存儲，分布式處理，分布式查詢，也可以理解為分布式數據庫架構

技術案例

如果當前的數據能夠在緩存中獲取到，則直接將數據返回給上層，不在訪問數據庫，如果是冷數據，則請求通過數據庫中間件，根據業務將原本數據庫進一步拆分，比如“用戶-商品-交易表”拆封成三幾個集群，集群內部有拆分成主從庫模式，寫請求會被派發到主數據庫，讀請求會被派發到從數據庫，但是這里不同點是由于拆分成三個庫，請求會先訪問一個集群中的數據，在訪問其他集群的數據，以此拿到完整的數據（此外還有的設計是在上層，直接派發多個請求，同時訪問多個集群，拿到一個完整的請求）

架構優缺點

優點：

數據庫吞吐量大幅提升，不再是瓶頸

缺點：

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

業務拆分—— 微服務

出現原因

上文架構

擴展性差:應用程序無法輕松擴展，因為每次需要更新應用程序時，都必須重新構建整個系統；

持續開發困難:一個很小的代碼改動，也需要重新部署整個應用,無法頻繁并輕松的發布版本；不可靠:即使系統的一個功能不起作用，可能導致整個系統無法工作；

不靈活:無法使用不同的技術構建單體應用程序、代碼維護難:所有功能耦合在一起，新人不知道何從下手

隨著人員增加，業務發展，系統本身體量的增加帶來的維護成本的大大增強，我們將業務的每個模塊抽象化并進行拆分，交給不同的開發團隊去維護，每個團隊獨立實現自己的微服務，然后互相之間對數據的直接訪問進行隔離，可以利用Gateway、消息總線等技術，實現相互之間的調用關聯。甚至可以把一些類似用戶管理等業務提成公共服務。這樣每個部門或小組就可以獨立負責自己的微服務，實現各個微服務的解耦。并且抽象出來的微服務后續如果有其他業務需要類似功能也可以直接復用。從公司部門管理上，各服務功能拆分出對應小組也降低整體的管理成本。

簡介

微服務是一種架構風格，按照業務板塊來劃分應用代碼，使單個應用的職責更清晰，相互之間可以做到獨立升級迭代。

技術案例

以電子商城為例，一個商城應用拆分成了多個微服務，如用戶服務、交易服務和商品服務，相互之間協作支持整個商城的應用。

架構優缺點

優點：

靈活性高：服務獨立測試、部署、升級、發布；

獨立擴展：每個服務可以各自進行擴展；提高容錯性：一個服務問題并不會讓整個系統癱瘓；

新技術的應用容易:支持多種編程語言

缺點：

運維復雜度高：業務不斷發展，應用和服務都會不斷變多，應用和服務的部署變得復雜，同一臺服務器上部署多個服務還要解決運行環境沖突的問題。

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

資源使用變多：所有這些獨立運行的微服務都需要需要占用內存和 CPU；處理故障困難：一個請求跨多個服務調用，需要查看不同服務的日志完成問題定位

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

出現原因

微服務拆分細，服務多部署工作量大，而且配置復雜，容易出錯；

微服務數量多擴縮容麻煩，而且容易出錯，每次縮容后再擴容又需要重新配置服務對應的環境參數信息；

微服務之間運行環境可能沖突，需要更多的資源來進行部署或者通過修改配置來解決沖突

隨著業務增長，然后運維發現系統的資源利用率不高，很多資源用來應對短時高并發，平時又閑置，需要動態擴縮容，還沒有辦法直接下線服務器，而且開發、測試、生產每套環境都要隔離的環境，運維的工作量會變的非常大。

容器化技術的出現給這些問題的解決帶來了新的思路。

目前最流行的容器化技術是Docker，最流行的容器管理服務是Kubernetes(K8S)，應用/服務可以打包為Docker鏡像，通過K8S來動態分發和部署鏡像。Docker鏡像可理解為一個能運行你的應用/服務的最小的操作系統，里面放著應用/服務的運行代碼，運行環境根據實際的需要設置好。把整個“操作系統”打包為一個鏡像后，就可以分發到需要部署相關服務的機器上，直接啟動Docker鏡像就可以把服務起起來，使服務的部署和運維變得簡單。

服務通常會有生產和研發k8s集群，一般不會公用，而研發集群通過命名空間來完成應用隔離，有的公司按照研發目的劃分為研發和測試集群，有的公司通過組織架構完成部門間的資源復用。

簡介

借助容器化技術(如docker)將應用/服務可以打包為鏡像，通過容器編排工具(如k8s)來動態分發和部署鏡像，服務以容器化方式運行；

技術案例

架構工作原理

以電子商城為例，一個商城應用拆分成了多個微服務，如用戶服務、交易服務和商品服務，每一個微服務打包到容器之中，相互協作來完成系統功能，通過容器編排工具完成部署運維，業務請求的整體流程與前文架構一致。不同的是容器化技術與容器編排技術使得部署與運維大大簡化，運維人員的工作量大大降低。

以上圖為例，java/c++應用需要語言開發的程序文件，依賴的庫、以及特定系統環境，而docker技術可以將所需要的配置一鍵打包成鏡像整體，并通過k8s管家將鏡像直接部署到對應服務器上。

這時候這個鏡像本身就是一個整體，可以獨立運行，不會受服務器環境的影響，也不會影響服務器環境，同一臺服務器上，我們也就可以部署多個環境不同的應用了。

架構優缺點

優點：

部署、運維簡單快速：一條命令就可以完成幾百個服務的部署或者擴縮容；

隔離性好：容器與容器之間文件系統、網絡等互相隔離，不會產生環境沖突；

輕松支持滾動更新：版本間切換都可以通過一個命令完成升級或者回滾；

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

尾聲

至此，一個還算合理的高可用、高并發系統的基本雛形已顯。

注意，以上所說的架構演變順序只是針對某個側面進行單獨的改進，在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。如在政府類的并發量可能不大，但業務可能很豐富的場景，高并發就不是重點解決的問題，此時優先需要的可能會是豐富需求的解決方案。

對于單次實施并且性能指標明確的系統，架構設計到能夠支持系統的性能指標要求就足夠了，但要留有擴展架構的接口以便不備之需。對于不斷發展的系統，如電商平臺，應設計到能滿足下一階段用戶量和性能指標要求的程度，并根據業務的增長不斷的迭代升級架構，以支持更高的并發和更豐富的業務。

所謂的“大數據”其實是海量數據采集清洗轉換、數據存儲、數據分析、數據服務等場景解決方案的一個統稱，在每一個場景都包含了多種可選的技術，如數據采集有Flume、Sqoop、Kettle等，數據存儲有分布式文件系統HDFS、FastDFS，NoSQL數據庫HBase、MongoDB等，數據分析有Spark技術棧、機器學習算法等。總的來說大數據架構就是根據業務的需求，整合各種大數據組件組合而成的架構，一般會提供分布式存儲、分布式計算、多維分析、數據倉庫、機器學習算法等能力。而服務端架構更多指的是應用組織層面的架構，底層能力往往是由大數據架構來提供。