一種融合不同場景的高并發處理分層架構體系*

張宇光

（1.中國電子科技集團公司第三十研究所，四川 成都 610041；2.網絡空間安全四川省重點實驗室，四川 成都 610041）

0 引 言

隨著我國“互聯網+”戰略的有力推行，各種移動應用、大型網站等互聯網產品給人民生活帶來了極大便利，其業務量和訪問用戶數都在爆炸式增長，這時大量用戶的高并發訪問給服務器的數據交換、處理帶來了巨大壓力。

為了保障業務順利完成，各種各樣的高并發處理技術應運而生，且對應于不同的應用場景呈現出不同的技術架構。李永進等人在民航旅客服務信息系統中引入一種分階段的事件驅動架構，使其擁有更好的處理高并發請求的能力[1]。李建華等人使用Redis緩存技術對微信公眾號進行二次開發，以提高系統的并發度[2]。徐云濤等人應用Nginx反向代理、多進程、多線程以及多核來加快高并發虹膜識別系統的并行搜索速度[3]。李軍鋒等人從負載均衡、頁面優化、緩存設計優化及數據庫優化等方面詳細研究并有效解決了航空機票秒殺系統中的高并發難題[4]。王繼業等人通過可定制數據結構和異步I/O多路復用，實現了大規模異構感知數據的高并發接收、解析和分發處理[5]。除了此類針對具體應用的高并發解決方案之外，很多學者亦研究并推廣主流的高并發處理技術。例如，王亞楠等人分別從Web應用前端、后臺程序代碼、數據庫、Web應用中間件配置以及服務器負載5個方面闡述了高并發優化方案[6]。李科偉分別就互聯網分布式架構中的網絡鏈路、反向代理、應用服務、數據緩存以及數據庫的高并發處理技術做了概述[7]。

上述研究給開發人員提供了應用范本和技術羅列，但是因為具體應用的特殊性導致其使用的高并發技術手段并不全面，且羅列的諸多技術也較為零散，較少按照并發數據接收處理過程進行分解梳理。因此，不少開發人員在面對各自項目時，仍然難以從全局高度對數據流逐個環節中可能用到的技術手段進行考量和篩選。

針對這個問題，本文首先對生活中常見的高并發應用場景進行歸納分類，提出了兩類高并發應用的通用場景，然后融合不同的通用場景提出統一的高并發六層架構體系，最后沿數據流梳理了在不同架構層次中常用的高并發處理技術手段。這種融合不同典型場景的互聯網高并發技術分層架構體系有助于開發人員清晰分解各自項目中的高并發數據接收與處理過程，快速匹配相應的處理技術，基于通用技術架構體系構建出完整且有效的技術方案。

1 高并發訪問的典型通用場景

現代生活中互聯網高并發訪問場景已極為常見，如京東618、淘寶雙11、火車票網上訂票、航空票務秒殺、微信搖一搖搶紅包、在線股票交易、網站訪問流量分析、商品瀏覽情況分析、內容興趣程度統計、民航旅客服務信息查詢系統、農業技術推廣信息管理系統及教務選課系統等。

觀察以上場景可以看出，它們基本上反映了兩類現實需求：一類是提高訪問用戶日常業務辦理的便利性且業務的處理結果直接反饋給用戶的需求；另一類是各類商家、公司企業采集海量訪問日志進行大數據分析，得出感興趣的結果并進行可視化展示的需求，歸納分類如表1所示。

表1 高并發訪問的兩類典型通用場景

分別滿足這兩類需求的諸多場景可以歸納成兩類共通的典型應用場景，第一類歸納成日常業務處理場景，第二類歸納成日志采集分析場景。

2 六層技術架構體系

從系統架構的角度來解決高并發訪問帶來的海量請求與數據處理需求，按照實際數據流位置和作用可將所用到的技術分為六個層次，分別為應用層、資源調度層、服務層、存儲層、數據處理層以及可視化展示層，如圖1所示。這種六層技術架構體系能夠將日常業務處理場景和高并發下的日志采集分析場景兩個典型場景的解決方案統一起來。

應用層承接用戶訪問，將大量的訪問請求交給資源調度層進行負載均衡的任務發放。服務層會針對不同的請求目標進行服務操作，由于日常業務處理的請求目標基本上是查詢、下單、數據修改及撤回等數據庫操作，而日志采集分析的目標則一般集中于類似日志集散、數據計算及可視化展示等工作，因此在服務層兩大應用場景的技術路線就此分離。存儲層分別針對日常業務處理和日志采集分析應用承擔了不同的任務目標。對于日常業務處理側重于進行對目標數據及用戶注冊數據的數據庫增、刪、改、查操作，其高并發技術保護多是趨于防止雪崩擊穿、數據庫宕機等運行風險。對于日志采集分析則是收集數據，為下一步數據分析做準備。數據處理層和可視化展示層為大數據分析提供算力和前端結果展示，在這兩個層次中沒有日常業務處理技術，因為在日常業務處理中不存在復雜的數據計算，其數據將反饋到用戶自身的顯示器上做展示，而非在另一個界面中進行新的展示。以下將逐層對各層功能進行進一步介紹，并梳理組成各層技術架構的當今流行的技術手段。

圖1 高并發處理六層技術架構體系

2.1 應用層

應用層直接面對用戶，提供與用戶交互的界面，一般由瀏覽器、移動端APP等組成。在這一層用到的主要技術是本地緩存。

本地緩存通常適合于存儲不更新或較少更新的數據。在第一次訪問時，瀏覽器或移動端APP會從服務器下載所需的資源（文字、圖片等）并存儲到本地設備中。當用戶再一次請求相同資源時，瀏覽器或APP會先檢查本地緩存中是否存在已是最新的數據。如果存在，則直接從本地緩存中提取數據，而不再占用網絡帶寬向服務器請求資源。

在性能優化中，緩存簡單、高效。一個優秀的緩存策略可以縮短網頁請求資源的距離，減少延遲，且緩存文件可以重復利用，還可以減少帶寬，降低網絡負荷[8]。

2.2 資源調度層

資源調度層主要解決響應用戶請求時的負載均衡問題。這里可先后采取鏈路均衡設備、內容分發網絡和反向代理技術實現負載均衡。

2.2.1 網絡鏈路均衡

常見的鏈路均衡設備有radware、F5等，作用是使多運營商網絡鏈路更好地互聯互通。它們通常被部署在承接用戶訪問的最前端，可以顯著提高系統的響應時間（Response Time，RT），消除網絡鏈路瓶頸。

2.2.2 內容分發網絡

移動設備數量的激增導致帶寬消耗過大，容易產生網絡瓶頸，影響移動用戶的訪問體驗質量[9]。內容分發網絡（Content Delivery Network，CDN）在網絡上遍布節點服務器，使得用戶的請求能夠實時依據網絡擁擠情形被分派到最優的節點服務器上，以繞開網絡瓶頸，從而使用戶請求能夠更快更穩定地獲取到服務器的響應數據。

2.2.3 反向代理

反向代理服務器能夠按照預設的規則將訪問請求路由到多個響應服務器，以此實現負載均衡。

反向代理服務器中實現負載均衡的規則多種多樣，如“DNS輪詢”“按權重隨機分發”等，其中“DNS輪詢”較為常見，配置時在dns-server中為一個域名配置多個解析IP。每次DNS解析請求來訪問DNS服務器時，dns-server會循環將這些IP返回，從而起到負載均衡的效果。反向代理服務器需要配合響應服務器集群技術發揮作用。

架構反向代理服務器有很多方法，硬件、軟件部署都可以，如nginx、varnish及HAProxy等。

2.3 服務層

經過前面的反向代理層，原則上能夠部署多個WEB應用服務。若是WEB后端出現瓶頸，只需多增加服務器數量，部署新WEB服務，并在反向代理服務器中配置新的WEB后端服務器IP，就可以增強應用服務層的使用性能。WEB服務器的性能是直接影響互聯網業務性能高低的關鍵因素，現階段市場中有許多種類的WEB服務器，最主流最具代表性的是Apache和Nginx。Apache擁有豐富的模塊組件支持，穩定性強、BUG少、動態內容處理強。Nginx輕量級，占用資源少、負載均衡、高并發處理強，且靜態內容處理高效[10]。

根據具體業務的不同，這里可分為日常業務處理架構和日志采集分析架構兩個分支。其中，日常業務處理架構涉及的數據處理基本上是數據庫的數據讀寫交互，沒有大量的數據運算分析，其高并發承載性能專注于對數據庫的緩存保護和讀寫任務的協調。日志采集分析的典型業務是用戶訪問日志的處理，其高并發訪問技術專注于分布式的日志收集、存儲和并行運算。日常業務的響應最終會返回給消費者交互頁面，而日志采集分析的最終輸出通常是用戶界面之外的可視化界面。

2.3.1 日常業務處理場景

一級緩存是使用站點服務器緩存存儲數據，與應用層中的瀏覽器本地緩存類似。需要注意，站點服務器本身的內存需要有所空閑，以保證站點應用程序的流暢運行。因此，通常只有被高頻率請求的數據才會被存儲到站點服務器中。

2.3.2 日志采集分析場景

日志服務器可能壓力很大，因此應是若干個機器組成的集群。從瀏覽器或其他設備應用收集的信息可通過異步提交技術（AJAX或Img請求）將信息提交到日志服務器中。每一臺日志服務器上都會啟動一個自己的日志代理來收集這一臺機器上的日志信息。日志收集系統比較出名的有Flume和ELK，其中Flume是一個高可用、具有魯棒性、分布式的海量日志采集、聚合和傳輸的系統。

2.4 存儲層

2.4.1 日常業務處理場景

（1）高速緩存

緩存技術可以應用于多個層次，卻由于各層緩存保護對象的不同，在實現方式上有所區別。在日常業務處理應用中，存儲層高速緩存的保護對象是數據庫。把較少變化的數據存在高速緩存中，使得大量請求命中高速緩存，以減少數據庫的壓力。

這里高速緩存的主流實現方式是使用諸如memcache、redis的內存數據庫。由于數據全部存儲在內存中，所以讀寫速度非常快[11]，且內存數據庫服務器允許的連接數很大，可以配置主從集群，所以可以滿足較大的并發查詢。

（2）消息隊列

高速緩存可以為數據庫擋掉許多的讀操作，但是數據庫的寫入操作都是在主庫完成的。當大量的連接數量超出了主庫所能提供的最大連接數時，不可避免有許多寫入請求需要被迫等待，直到有空閑的連接出現，這樣會引發“Connection time out”的情況。

為避免上述情形，可以使用消息隊列來實現對數據庫的異步訪問。消息隊列將用戶的寫請求加入一個隊列中，同時給用戶一個快速響應。當數據庫存在空閑連接時，消息隊列會推送一個請求給數據庫進行入庫操作。這樣消息隊列作為一個緩沖區，可起到削峰限流的作用。

高并發下異步持久化數據可能會影響用戶的體驗，可以通過可配置的方式或者自動化監控資源消耗來切換實時處理或者使用異步。這樣在正常流量的情況下，可以使用實時操作數據庫來提高用戶體驗[12]。

（3）多線程程序

一個或多個消息隊列中的消息可以使用多個線程進行并行的消費，以提高效率。

（4）數據庫優化

數據庫一般可采用主從復制或主主復制以應付高并發請求。對于數據吞吐量特大的應用，一般可以采用分布式集群技術，如Mysql Cluster。數據庫的優化對于勝任高并發場景至關重要，很多數據庫訪問崩潰的最大原因是本身數據庫優化沒有做好，如索引的建立、表結構的優化及字段的合理設置等。

2.4.2 日志采集分析場景

為了將每臺日志服務器的信息匯總存儲，需要一個中心日志服務器。由于如果只有一臺中心服務器往往無法滿足使用需求，因此需要一個中心日志服務器的集群來作為中心服務器使用。在集群中可以配置負載均衡和失敗恢復的機制。

在日志采集分析應用場景下，分析方式根據目標和手段的不同可以被分為實時分析和離線分析。這兩種分析方式的區別如表2所示。

表2 實時分析與離線分析的區別

以上兩種分析方式對存儲層提出了不同的功能需求。實時分析中，存儲層為了后期強實時性的流式計算，必須選擇寫入讀取性能高且能夠在數據中心日志收集服務器（如Flume）和實時計算架構之間起到數據傳輸與緩沖作用的存儲技術。而在離線（或偽實時）分析中，存儲層可以不必過多在意數據的讀取性能，但需要能夠大量、穩定、安全地存儲數據，為離線分析提供接口方法。

（1）實時分析——消息隊列

在實時處理的分支中，由于部分日志收集發送組件（如Flume）發送數據不考慮接收方的消化能力，而部分實時數據計算分析組件（如Storm）本身沒有對數據輸入做任何的支持或限制，所以很可能出現數據分析組件消化不了日志服務器的輸出，甚至造成Topology報錯退出。因此，需要一個消息隊列做緩沖。在大數據分析場景中，kafka是一個常用選項。

Kafka使用Pull模式，消費者主動從kafka拽數據，消費的速率由消費者決定，所以kafka適用于作為實時流架構的中間件，在系統之間起到數據傳輸與緩沖的作用。

另外，順序寫入磁盤保證了Kafka高寫入性能，底層的zero-copy技術減少了網絡傳輸數據時延而造就了很高的讀取性能，其分布式架構提供了高吞吐量和可擴展性，而副本冗余機制保障了其數據存儲的可靠性。目前，越來越多的開源分布式處理系統如Cloudera、Apache Storm及Spark都支持與Kafka集成。

（2）離線分析——分布式文件系統

在大數據場景下的離線分析中，普通的服務器或者單純依靠增加硬盤數量的方式來擴展存儲能力，將無法滿足數據管理、存儲性能、高可用和數據安全等方面的需求。

分布式文件系統（Distributed File System，DFS）可以有效解決數據的存儲和管理難題：將固定于某個地點的某個文件系統擴展到任意多個地點/多個文件系統，眾多的節點組成一個文件系統網絡。每個節點可以分布在不同的地點，通過網絡進行節點間的通信和數據傳輸。人們在使用分布式文件系統時，無需關心數據存儲在哪個節點或者從哪個節點獲取，只需要像使用本地文件系統一樣管理和存儲文件系統中的數據[13]。

國內最廣泛使用的分布式文件系統是Apache的Hadoop分布式文件系統（Hadoop Distributed File System，HDFS）。這是一個開源的、可靠的、可擴展的系統架構，可利用分布式架構存儲海量數據，還可實現分布式計算。Hadoop允許使用簡單的編程模型在計算機集群中對大型數據集進行分布式處理，可以從單個服務器擴展到數千臺機器，每個機器都提供本地計算和存儲，且框架內的機制可以自動檢測和處理故障，而非單靠硬件提供高可用性。

2.5 數據處理層

這里的數據處理層只涉及日志采集分析的部分，一般的日常業務處理應用不涉及大量的數據運算分析，所以不被包含在這個層次。在日志采集分析中，由于實時分析和離線分析對于實時性的需求不同，將采用不同的計算技術與程序工具。

2.5.1 實時分析

（1）分布式計算

大數據的實時分析需要進行分布式的流式計算，比較流行的方案是選用Storm、Spark等實時計算技術。

Storm是一個開源的分布式實時計算系統，利用Spout和Bolt組建數據流處理網絡，簡單、可靠地處理大量的數據流。Storm的使用場景有實時分析、持續計算、在線機器學習及分布式RPC等。這種分布式實時系統支持水平擴展，具有高容錯性，保證每個消息都會得到處理；性能優良，處理速度很快（在一個小集群中，每個結點每秒可以處理數以百萬計的消息）；部署和運維都很便捷，而且更重要的是可以使用任意編程語言來開發應用[14]。

Spark是一種大數據內存計算框架，設計初衷是盡量使用內存進行計算，減少數據落地寫磁盤的情況，從而提升效率和性能，特別是針對連續多步運算優勢更明顯。Spark使用有向無環圖結構（Directed Acyclic Graph，DAG）將若干步運算流程組織起來，基于彈性分布式數據集（Resilient Distributed Dataset，RDD）進行運算，既滿足了復雜運算中大量連續運算的需求，又將計算邏輯和計算資源隔離，方便于對集群資源進行管理。

（2）中間數據存儲

在進行計算的過程中，很有可能會產生一些“中間數據（中間的計算結果）”。這些中間數據如果量大，會選擇把它們存儲到外部存儲設備（redis、HDFS、mysql、hbase以及kafka等）中。

2.5.2 離線分析

（1）分布式計算

離線分析中的分布式計算由于處理的是大規模的持久化數據集，存在許多數據讀取與落地的操作，因此處理速度與實時分析相比相對緩慢，如 MapReduce、YARN（Yet Another Resource Negotiator）及Hive等并行運算工具。

MapReduce是一個分布式的計算框架（編程模型），是一種簡單易用的軟件編程框架。它采用“分而治之”的思想，把對大數據的處理分發到集群的各個節點上并行完成，通過整合各個節點的中間結果得到最終的處理結果[15]。YARN又稱MapReduceV2.0，在資源管理分配和任務調度監控方面對MapReduce進行了升級，在資源利用率、資源統一管理和數據共享方面提升明顯。Hive建立在Hadoop生態圈上是一個數據倉庫。Hive提供的是一種結構化數據的機制[16]，可以將結構化的數據文件映射為一張數據庫表，并提供完整的sql查詢功能，可以通過類SQL語句快速實現簡單的MapReduce統計，不必開發專門的MapReduce應用，十分適合數據倉庫的統計分析。但是，Hive的執行速度慢，不能支持用戶實時的查詢[17]。

（2）結果存儲

在經歷數據存儲、處理后，一般不會把Hive等組件暴露出來，而是會把數據導出到外部存儲中，如mysql、redis等都可以。

2.6 前端顯示層

將日志采集分析完的結果展現為可直觀觀察的圖表、報表等形式的過程，稱之為大數據的可視化過程。大數據的可視化并不算日志采集分析的核心技術，但是日志采集分析完成后是否能夠直觀展現給用戶直接關系到用戶的使用體驗，所以目前大數據可視化也是大數據生態中非常熱門的話題。

目前，大數據可視化主要有兩種做法：

（1）通過傳統的WEB和前端技術實現定制化的可視化；

（2）通過市面上的可視化工具展示數據。

2.6.1 WEB和前端技術

使用WEB和前端技術，如WEB開發技術、數據庫技術及前端展示技術（Echars等），可以實現定制化能力很強的展示界面，可以自定義數據展示的交互形式，缺點是需要進行代碼開發，開發周期和難度相對較大。

2.6.2 可視化工具

常用的可視化工具有Tableau、DataV等，使用工具開發簡單便捷，基本不會涉及太多的代碼編寫，且專業化的可視化工具的展示效果通常比較絢麗。缺點在于定制化能力較差，如果工具本身沒有提供相應組件，基本無法擴展；可視化的工具基本都會收費，且通常依賴廠商提供的平臺，較難本地化部署。

3 結 語

本文通過觀察現實生活中常見的互聯網高并發訪問場景，歸納出日常業務處理和日志采集分析兩類高并發應用的通用場景。融合不同場景，提出了一種高并發處理六層技術架構體系，將這些場景的解決方案統一起來，并梳理每一層的處理目標和技術手段，介紹流行的技術工具。

這種融合不同典型場景的互聯網高并發處理分層技術架構體系，有助于開發人員通過歸類業務目標來清晰分解各自項目中高并發數據接收與處理過程，快速匹配相應的處理技術，基于通用技術架構體系構建出完整且有效的技術方案。

互聯網新技術新方法層出不窮，提出的架構層次必然還有許多流行技術沒有收集進來，未來還應繼續大量收集各種不同的高并發技術，以豐富體系中的技術手段，同時也可以對其他高并發場景中的其他架構進行研究，從而對分層結構本身進行迭代與優化。