一種融合不同場景的高并發(fā)處理分層架構(gòu)體系*

張宇光

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

0 引 言

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

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

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

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

1 高并發(fā)訪問的典型通用場景

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

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

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

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

2 六層技術(shù)架構(gòu)體系

從系統(tǒng)架構(gòu)的角度來解決高并發(fā)訪問帶來的海量請求與數(shù)據(jù)處理需求，按照實際數(shù)據(jù)流位置和作用可將所用到的技術(shù)分為六個層次，分別為應用層、資源調(diào)度層、服務層、存儲層、數(shù)據(jù)處理層以及可視化展示層，如圖1所示。這種六層技術(shù)架構(gòu)體系能夠?qū)⑷粘I(yè)務處理場景和高并發(fā)下的日志采集分析場景兩個典型場景的解決方案統(tǒng)一起來。

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

圖1 高并發(fā)處理六層技術(shù)架構(gòu)體系

2.1 應用層

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

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

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

2.2 資源調(diào)度層

資源調(diào)度層主要解決響應用戶請求時的負載均衡問題。這里可先后采取鏈路均衡設備、內(nèi)容分發(fā)網(wǎng)絡和反向代理技術(shù)實現(xiàn)負載均衡。

2.2.1 網(wǎng)絡鏈路均衡

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

2.2.2 內(nèi)容分發(fā)網(wǎng)絡

移動設備數(shù)量的激增導致帶寬消耗過大，容易產(chǎn)生網(wǎng)絡瓶頸，影響移動用戶的訪問體驗質(zhì)量[9]。內(nèi)容分發(fā)網(wǎng)絡（Content Delivery Network，CDN）在網(wǎng)絡上遍布節(jié)點服務器，使得用戶的請求能夠?qū)崟r依據(jù)網(wǎng)絡擁擠情形被分派到最優(yōu)的節(jié)點服務器上，以繞開網(wǎng)絡瓶頸，從而使用戶請求能夠更快更穩(wěn)定地獲取到服務器的響應數(shù)據(jù)。

2.2.3 反向代理

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

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

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

2.3 服務層

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

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

2.3.1 日常業(yè)務處理場景

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

2.3.2 日志采集分析場景

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

2.4 存儲層

2.4.1 日常業(yè)務處理場景

（1）高速緩存

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

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

（2）消息隊列

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

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

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

（3）多線程程序

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

（4）數(shù)據(jù)庫優(yōu)化

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

2.4.2 日志采集分析場景

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

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

表2 實時分析與離線分析的區(qū)別

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

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

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

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

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

（2）離線分析——分布式文件系統(tǒng)

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

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

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

2.5 數(shù)據(jù)處理層

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

2.5.1 實時分析

（1）分布式計算

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

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

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

（2）中間數(shù)據(jù)存儲

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

2.5.2 離線分析

（1）分布式計算

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

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

（2）結(jié)果存儲

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

2.6 前端顯示層

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

目前，大數(shù)據(jù)可視化主要有兩種做法：

（1）通過傳統(tǒng)的WEB和前端技術(shù)實現(xiàn)定制化的可視化；

（2）通過市面上的可視化工具展示數(shù)據(jù)。

2.6.1 WEB和前端技術(shù)

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

2.6.2 可視化工具

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

3 結(jié) 語

本文通過觀察現(xiàn)實生活中常見的互聯(lián)網(wǎng)高并發(fā)訪問場景，歸納出日常業(yè)務處理和日志采集分析兩類高并發(fā)應用的通用場景。融合不同場景，提出了一種高并發(fā)處理六層技術(shù)架構(gòu)體系，將這些場景的解決方案統(tǒng)一起來，并梳理每一層的處理目標和技術(shù)手段，介紹流行的技術(shù)工具。

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

互聯(lián)網(wǎng)新技術(shù)新方法層出不窮，提出的架構(gòu)層次必然還有許多流行技術(shù)沒有收集進來，未來還應繼續(xù)大量收集各種不同的高并發(fā)技術(shù)，以豐富體系中的技術(shù)手段，同時也可以對其他高并發(fā)場景中的其他架構(gòu)進行研究，從而對分層結(jié)構(gòu)本身進行迭代與優(yōu)化。