基于分布式管道模式的管道服務(wù)框架設(shè)計與實(shí)現(xiàn)

戴振邦 江恩杰 劉力嘉 甘江偉 戴振邦 江恩杰 劉力嘉 甘江偉

摘要：集中化，合并任務(wù)的處理是分布式設(shè)計中的一個難點(diǎn)。由于不同任務(wù)中需要頻繁的數(shù)據(jù)交換，且需對不同任務(wù)的結(jié)果進(jìn)行合并，使其難以使用目前主流的分布式設(shè)計模型。分布式管道設(shè)計模式是一種高度解耦合的分布式設(shè)計模型，適合處理業(yè)務(wù)粒度較大，數(shù)據(jù)交換頻發(fā)，IO瓶頸較高的任務(wù)。文章在分布式管道設(shè)計模式的基礎(chǔ)上，參考服務(wù)發(fā)現(xiàn)機(jī)制實(shí)現(xiàn)了一個高性能的管道服務(wù)框架。

關(guān)鍵詞：分布式;服務(wù)發(fā)現(xiàn);動態(tài)負(fù)載均衡;管道任務(wù);高解耦

中圖分類號：TP311? ? ? 文獻(xiàn)標(biāo)識碼：A 文章編號：2096-4706（2021）07-0044-07

Design and Implementation of Pipeline Service Framework Based on

Distributed Pipeline Mode

DAI Zhenbang1，JIANG Enjie2，LIU Lijia2，GAN Jiangwei3

（1.School of Chemical Engineering，Northwest Minzu University，Lanzhou? 730124，China;

2.Information Engineering Department，Chengyi University College，Jimei University，Xiamen? 361021，China;

3.College of Physics and Electronic Information Engineering，Minjiang University，F(xiàn)uzhou? 350108，China）

Abstract：Centralization and combined task processing is a difficulty in distributed design. Due to there are frequent data exchanges in different tasks and the results of different tasks need to be merged，it is difficult to use the current mainstream distributed design model. Distributed pipeline design pattern is a high decoupling distributed design model，which is suitable for the tasks with large business granularity，frequent data exchange and high IO bottleneck. Based on the distributed pipeline design pattern，this paper implements a high performance pipeline service framework with the reference of service discovery mechanism.

Keywords：distributed;service discovery;dynamic load balancing;pipeline task;high decoupling

收稿日期：2021-03-09

基金項(xiàng)目：大學(xué)生創(chuàng)新創(chuàng)業(yè)訓(xùn)練計劃項(xiàng)目 （省級）（202013471013）

0? 引? 言

目前比較流行的分布式解耦合的解決方案中，如微服務(wù)，這是一種將應(yīng)用程序構(gòu)造為一組松散耦合服務(wù)的軟件開發(fā)技術(shù)，是面向服務(wù)的體系結(jié)構(gòu)（Service-Oriented Architecture，SOA）架構(gòu)樣式的一種變體[1]。在微服務(wù)體系結(jié)構(gòu)中，其服務(wù)是細(xì)粒度的，并且協(xié)議是輕量級的[2]，是一種高度解耦合的分布式設(shè)計思想，但微服務(wù)更適合用在解決模塊化可分離的任務(wù)中，可以在不同服務(wù)中通過相互調(diào)用的方式來完成不同服務(wù)中的協(xié)同。對于目前互聯(lián)網(wǎng)大多數(shù)分層業(yè)務(wù)來說，微服務(wù)是一個很好的解決辦法，但對于集中化的，需要合并處理任務(wù)來說，微服務(wù)無法有效地對任務(wù)進(jìn)行分層。本文參考分布式管道設(shè)計模式的解決方案，設(shè)計一個用于分層合并任務(wù)的分布式解耦合任務(wù)處理框架。

本文設(shè)計了一個分布式解耦合任務(wù)處理框架（下文簡稱管道服務(wù)框架），主要解決分布式任務(wù)中的服務(wù)發(fā)現(xiàn)、動態(tài)負(fù)載均衡和管道粒度的拆分，最后通過實(shí)際業(yè)務(wù)中的應(yīng)用效果驗(yàn)證了該框架的可行性和有效性。

1? 分布式管道設(shè)計模式

分布式管道設(shè)計模式是一種去中心化的分布式設(shè)計模式，其特點(diǎn)是無須任務(wù)分配，每個獨(dú)立的管道（總?cè)蝿?wù)的子集）都可以主動或被動地推送或接收數(shù)據(jù)，并且按照一定的規(guī)則對數(shù)據(jù)進(jìn)行處理，然后執(zhí)行流出或者暫時儲存的操作，管道還可以截留數(shù)據(jù)，在特定條件下對數(shù)據(jù)進(jìn)行合并流出。在管道設(shè)計模式中，管道可以根據(jù)數(shù)據(jù)的標(biāo)記，使用一種類似服務(wù)發(fā)現(xiàn)的方式主動地推送數(shù)據(jù)到處理管道中，即對于任何一個產(chǎn)生的數(shù)據(jù)，無須使用消息隊(duì)列等工具對任務(wù)進(jìn)行推送，只需要交付到任何一個管道的入口由管道進(jìn)行推送即可。

分布式管道設(shè)計模式中道管道類型有進(jìn)程管道、協(xié)程管道、線程管道，不同的管道維護(hù)不同的上下文，同時有不同的處理方案，相對來說，進(jìn)程管道做到了并行處理，適用于計算密集型任務(wù);協(xié)程管道適用于高IO任務(wù)，可以幾乎不需要額外的消耗，進(jìn)行操作系統(tǒng)回調(diào)。

2? 管道服務(wù)框架架構(gòu)

如圖1所示，管道服務(wù)架構(gòu)中，服務(wù)表示轉(zhuǎn)流層負(fù)責(zé)記錄每個處理管道的地址，以及管道數(shù)據(jù)交換以及日志的緩存。數(shù)據(jù)交換層主要負(fù)責(zé)相互隔離的2個管道的數(shù)據(jù)交換。管道工作層主要負(fù)責(zé)用戶邏輯的處理部分，數(shù)據(jù)的合并處理，數(shù)據(jù)的流出處理。日志層主要用于管道崩潰后，根據(jù)日志進(jìn)行數(shù)據(jù)的恢復(fù)，以及管道m(xù)assage的記錄。回調(diào)層，主要用于任務(wù)處理完畢或者管道合并后的結(jié)果輸出。

2.1? 服務(wù)表示轉(zhuǎn)流層

服務(wù)表示轉(zhuǎn)流層主要分為服務(wù)注冊中心、管道全局中心。服務(wù)注冊中心[3]在管道服務(wù)框架中使用，全局管道空間實(shí)現(xiàn)一個簡單的Key-value數(shù)據(jù)庫，當(dāng)然可以使用ETCD[4]或者Redis[5]來作為服務(wù)注冊中心的載體。

服務(wù)注冊中心的作用主要是為了維護(hù)每個管道或者管道組的正常運(yùn)行，維護(hù)每個管道或者管道組的信息，實(shí)際上在使用中會把多個管道合并為一個集合，包括管道集合所在的IP端口，以及它擁有的管道ID。并且每個管道集合必須定時的重新上報自己的情況，否則過期后，服務(wù)注冊中心會刪除這個管道集合的信息。

管道全局中心的主要作用是用于在不同分區(qū)中的管道交換數(shù)據(jù)時，會先在管道全局中心中緩存數(shù)據(jù)，發(fā)送管道先緩存數(shù)據(jù)，然后告知目標(biāo)管道，目標(biāo)管道激活后直接通過管道交換通道獲取到對應(yīng)的數(shù)據(jù)，流入管道。值得注意的是，為了保證在發(fā)生網(wǎng)絡(luò)分區(qū)時，框架的數(shù)據(jù)恢復(fù)能力，管道對全局空間并不會直接操作，而是需要通過管道交換通道進(jìn)行。

2.2? 數(shù)據(jù)交換層

數(shù)據(jù)交換層主要由多個管道交換通道組成，一般來說管道交換通道的數(shù)目與管道集合的數(shù)目相等，即一個集合一個管道交換通道，管道交換通道主要用于解決數(shù)據(jù)一致性問題;數(shù)據(jù)通道解決事務(wù)一致性問題，保證管道推送的數(shù)據(jù)一定被日志記錄以及被上傳到管道全局中心中。然后去通知接收管道，同時管道交換通道還負(fù)責(zé)負(fù)載均衡的實(shí)現(xiàn)，如果管道在流出數(shù)據(jù)時沒有指定目標(biāo)管道的唯一標(biāo)識ID，而是指定了管道服務(wù)ID，那么數(shù)據(jù)交換層會盡可能均衡的推送數(shù)據(jù)到管道集合中管道服務(wù)ID相同的分組。同時管道交換通道還支持動態(tài)均衡[4]策略，管道交換通道會跟蹤每一個管道分配的拉取時間，對于分配拉取管道拉取時間慢的管道集合地址更新更小的權(quán)重，根據(jù)權(quán)重來進(jìn)行負(fù)載均衡。

交換層代碼為：

func （cr*ConsulResolver） resolveService（ctxcontext.Context） （string， connect.CertURI， error） {

health ：=cr.Client.Health（）

svcs， _， err ：=health.Connect（cr.Name， ""， true， cr.query Options（ctx））

iferr！=nil {

return""， nil， err

}

iflen（svcs） <1 {

return""， nil， fmt.Errorf（"no healthy instances found"）

}

// Services are not shuffled by HTTP API， pick one at （pseudo） random.

idx ：=0

iflen（svcs） >1 {

idx=rand.Intn（len（svcs））

}

returncr.resolveServiceEntry（svcs[idx]）

}

func （cr*ConsulResolver） resolveQuery（ctxcontext.Context） （string， connect.CertURI， error） {

resp， _， err ：=cr.Client.PreparedQuery（）.Execute（cr.Name， cr.queryOptions（ctx））

iferr！=nil {

return""， nil， err

}

svcs ：=resp.Nodes

iflen（svcs） <1 {

return""， nil， fmt.Errorf（"no healthy instances found"）

}

// Services are not shuffled by HTTP API， pick one at （pseudo） random.

idx ：=0

iflen（svcs） >1 {

idx=rand.Intn（len（svcs））

}

returncr.resolveServiceEntry（&svcs[idx]）

}

2.3? 管道工作層

管道工作層作為管道服務(wù)框架中實(shí)際的工作角色，用戶將給每個不同的管道定義不同的工作任務(wù)，同時定義管道的服務(wù)ID或者叫作任務(wù)ID，定義管道的流動條件，定義管道的推送條件，定義管道的合并條件。如在計算階乘和的任務(wù)中，我們可以分解出計算階乘和求和的子任務(wù)，這2個任務(wù)會被定義到2個不同的管道中并且有自己的任務(wù)ID，在這個任務(wù)中我們可以開啟多個計算階乘的管道，一個組合的管道，并且指示計算階乘的管道的流出是組合管道，在組合管道中會對階乘管道的求出結(jié)果做合并，最后輸出到流出器中等待回調(diào)得到最終的結(jié)果。管道的基本工作流出如圖2所示。

管道工作層代碼為：

typePolicystruct {

ID? ? ? ? ? ? ? ? ? ? string? ? ? ? ? ? ? ? ?`hcl："id"`

Revision? ? ? ? ? ? ? uint64? ? ? ? ? ? ? ? ?`hcl："revision"`

ACL? ? ? ? ? ? ? ? ? ?string? ? ? ? ? ? ? ? ?`hcl："acl，expand"`

Agents? ? ? ? ? ? ? ? []*AgentPolicy? ? ? ? ?`hcl："agent，expand"`

AgentPrefixes? ? ? ? ?[]*AgentPolicy? ? ? ? ?`hcl："agent_prefix，expand"`

Keys? ? ? ? ? ? ? ? ? []*KeyPolicy? ? ? ? ? ?`hcl："key，expand"`

KeyPrefixes? ? ? ? ? ?[]*KeyPolicy? ? ? ? ? ?`hcl："key_prefix，expand"`

Nodes? ? ? ? ? ? ? ? ?[]*NodePolicy? ? ? ? ? `hcl："node，expand"`

NodePrefixes? ? ? ? ? []*NodePolicy? ? ? ? ? `hcl："node_prefix，expand"`

Services? ? ? ? ? ? ? []*ServicePolicy? ? ? ?`hcl："service，expand"`

ServicePrefixes? ? ? ?[]*ServicePolicy? ? ? ?`hcl："service_prefix，expand"`

Sessions? ? ? ? ? ? ? []*SessionPolicy? ? ? ?`hcl："session，expand"`

SessionPrefixes? ? ? ?[]*SessionPolicy? ? ? ?`hcl："session_prefix，expand"`

Events? ? ? ? ? ? ? ? []*EventPolicy? ? ? ? ?`hcl："event，expand"`

EventPrefixes? ? ? ? ?[]*EventPolicy? ? ? ? ?`hcl："event_prefix，expand"`

PreparedQueries? ? ? ?[]*PreparedQueryPolicy`hcl："query，expand"`

PreparedQueryPrefixes[]*PreparedQueryPolicy`hcl："query_prefix，expand"`

Keyring? ? ? ? ? ? ? ?string? ? ? ? ? ? ? ? ?`hcl："keyring"`

Operator? ? ? ? ? ? ? string? ? ? ? ? ? ? ? ?`hcl："operator"`

}

2.4? 管道工作層調(diào)度模型

在管道服務(wù)框架的實(shí)現(xiàn)中，管道的工作使用GMP模型，模型分為M、P、G三個角色，分別代表POSIX Threads，Processor和Go Pipeline。P可以理解為執(zhí)行上下文，也就是context，P負(fù)責(zé)完成對G和M的調(diào)度，我們可以把M理解為操作系統(tǒng)資源的抽象，是真正的執(zhí)行體;把G理解為要執(zhí)行任務(wù)的抽象，是執(zhí)行代碼和數(shù)據(jù)的集合。P用執(zhí)行體M來執(zhí)行G，并且維護(hù)了一個隊(duì)列來存放可執(zhí)行的G，當(dāng)前G執(zhí)行結(jié)束，M就空閑了下來，P就可以從隊(duì)列的頂部取出下一個G在M上繼續(xù)執(zhí)行。

當(dāng)M去執(zhí)行該系統(tǒng)調(diào)用時線程會阻塞并被操作系統(tǒng)掛起，這個時候P會把當(dāng)前的G留在原來的M中處理，然后從隊(duì)列里取出下一個G并創(chuàng)建一個新的M對象來執(zhí)行它。被的G-M對完成系統(tǒng)調(diào)用變成可執(zhí)行狀態(tài)時，又會在合適的時機(jī)被重新調(diào)度執(zhí)行。如圖3所示。

圖中，長矩形為全局可用資源，包括全局隊(duì)列、操作系統(tǒng);圓角長矩形為局部可用資源，圖中為局部隊(duì)列;圓形為虛擬工作角色，即工作管道;正方形為具有調(diào)度功能的角色，圖中為P（虛擬調(diào)度器）以及CPU（調(diào)度器）;三角形為實(shí)際工作內(nèi)核線程;虛線標(biāo)記部分標(biāo)識其為虛擬整體，圖中相對于整個系統(tǒng)CPU為一個整體工作，實(shí)際上CPU獨(dú)立互不干涉。

使用以上模型，可以使管道用更小的開銷異步處理計算密集型以及IO密集型的任務(wù)，相對來說，更適合處理IO任務(wù)，并且解決了分布式管道設(shè)計模式中用戶的管道選擇問題，降低了管道設(shè)計模式的任務(wù)分層時的選擇復(fù)雜度，使得用戶只需要關(guān)注如何拆分任務(wù)。

2.5? 回調(diào)層

回調(diào)層主要為結(jié)果的輸出，用戶最終使用回調(diào)層提供的接口，如圖1中的流出器獲取到管道處理完畢的數(shù)據(jù)。值得注意的是，為了解決管道資源的占用問題，管道使用回調(diào)層流出數(shù)據(jù)后會立刻釋放當(dāng)前的資源，認(rèn)為該任務(wù)集合的本次任務(wù)已經(jīng)完成。

2.6? 日志層

日志層主要分為異常日志和恢復(fù)日志：

（1）異常日志。異常日志主要用于記錄POSIX Threads這里可以理解為操作系統(tǒng)回調(diào)的錯誤日志，以及框架用戶在GOPipeline中手動定義，并且被拋出觸發(fā)的錯誤，異常任務(wù)可以對框架的執(zhí)行情況進(jìn)行簡要的分析，使得框架具有更好的錯誤檢測，中斷分析能力[6]。

（2）恢復(fù)日志。在管道設(shè)計模式中全局管道空間儲存每一次管道執(zhí)行任務(wù)后得到的中間態(tài)數(shù)據(jù)，并且管道全局中心中的數(shù)據(jù)保存在內(nèi)存中，一旦發(fā)生宕機(jī)或者進(jìn)程意外終止等問題，管道全局中心中的數(shù)據(jù)會全部損失，對應(yīng)的管道任務(wù)需要重新執(zhí)行。為解決上述問題管道設(shè)計模式參考Redis的持久化策略[5]引入恢復(fù)日志來解決框架的容災(zāi)問題。恢復(fù)日志的工作主要分為以下3個過程。

1）管道全局中心會在計算壓力較小的時候，對管道全局中心的數(shù)據(jù)進(jìn)行磁盤持久化，被稱為備份，并且在恢復(fù)日志中打下一個版本標(biāo)記。

2）管道交換通道每產(chǎn)生一次中間態(tài)數(shù)據(jù)，優(yōu)先記錄操作到恢復(fù)日志中，保證管道全局中心以及恢復(fù)日志的原子性，一致性[7]。

3）一旦發(fā)生導(dǎo)致進(jìn)程崩潰的問題，在管道服務(wù)框架重新啟動時優(yōu)先從最新的備份中恢復(fù)數(shù)據(jù)到管道全局中心中，根據(jù)備份的版本號，到恢復(fù)日志中逐步對該版本號以后的操作進(jìn)行恢復(fù)。

以下為日志層代碼：

funcSetup（config*Config， uicli.Ui） （*logutils.LevelFilter， *GatedWriter， *LogWriter， io.Writer， bool） {

// The gated writer buffers logs at startup and holds until it's flushed.

logGate ：=&GatedWriter{

Writer： &cli.UiWriter{Ui： ui}，

}

// Set up syslog if it's enabled.

varsyslogio.Writer

ifconfig.EnableSyslog {

retries ：=12

delay ：=5*time.Second

fori ：=0; i<=retries; i++ {

...

// Create a log writer， and wrap a logOutput around it

logWriter ：=NewLogWriter（512）

writers ：= []io.Writer{logFilter， logWriter}

varlogOutputio.Writer

ifsyslog！=nil {

writers=append（writers， syslog）

}

}

3? 管道服務(wù)框架設(shè)計與驗(yàn)證

3.1? 任務(wù)說明

我們對巨潮網(wǎng)上市公司2020年期間的報告數(shù)據(jù)進(jìn)行爬取，同時使用樸素貝葉斯算法進(jìn)行主題抽取，獲取年報中財務(wù)分析部分的報表內(nèi)容，并且對每個提取到數(shù)據(jù)進(jìn)行儲存分析。

3.2? 任務(wù)瓶頸分析

通過對巨潮網(wǎng)爬蟲的年報進(jìn)行估計，全國上市公司共3 869家其中深圳股市有2 241家，上海股市有1 628家，平均每個年度的報告數(shù)據(jù)為900條目，平均年報大小為1 350 kB，粗略估計總IO任務(wù)讀寫大小為4.05 TB，可以確定該任務(wù)為高IO復(fù)雜度任務(wù)。在本次實(shí)驗(yàn)任務(wù)中，假設(shè)樸素貝葉斯模型的訓(xùn)練過程已經(jīng)完成，來分析樸素貝葉斯模型的計算壓力。利用式（1）對離散數(shù)據(jù)進(jìn)行簡單化計算：

P（X|Ci）=P（xk|Cj）? ? ? ? ? ? ? ? ?（1）

式（1）中，P（X|Ci）為Ci文本屬于X的概率，P（xk|Cj）為Cj中包含詞條xk的概率。

樸素貝葉斯分類器[8]，分類的設(shè)計復(fù)雜度大概為O（C× D），其中C為類別，D為特征數(shù)。在本次二分類問題中時間復(fù)雜度為O（2D）屬于線性時間復(fù)雜度，由于在本次實(shí)驗(yàn)任務(wù)中，需要對每個上市公司的報告進(jìn)行分段輸入樸素貝葉斯分類器中進(jìn)行分類，根據(jù)對巨潮網(wǎng)的財報分析平均需要對3 000 byte（每個段落的大小）進(jìn)行分割計算，所以本次任務(wù)也屬于高計算密集型任務(wù)。

綜上所述，本次設(shè)計目標(biāo)為高IO高計算密集型任務(wù)，任務(wù)主要瓶頸為IO瓶頸，其次為計算瓶頸，最后為任務(wù)調(diào)度開銷。

3.3? 任務(wù)分層情況與管道設(shè)計

對于以上任務(wù)，在管道服務(wù)框架中，按照復(fù)雜度分離，可以概括為以下幾個任務(wù)：數(shù)據(jù)請求返回、原始數(shù)據(jù)保存、數(shù)據(jù)分割、樸素貝葉斯分類、報表數(shù)據(jù)統(tǒng)計。其中IO任務(wù)主要集中在數(shù)據(jù)請求，保存部分即數(shù)據(jù)采集部分。計算密集型任務(wù)主要存在于數(shù)據(jù)分割、樸素貝葉斯分類部分。報表數(shù)據(jù)產(chǎn)生的IO相對于數(shù)據(jù)采集部分IO的開銷極小，在本文中不做統(tǒng)計。經(jīng)過以上分析可以建立以下管道任務(wù)模型，如圖4所示。

在圖4中，我們共定義了3個管道集合，管道集合的定義，可以把一類有較高瓶頸任務(wù)的組合在一起，如數(shù)據(jù)請求管道，數(shù)據(jù)采集保存集合代表了高IO任務(wù)，數(shù)據(jù)分段解析集合，數(shù)據(jù)分類集合都是一個高CPU密集型集合任務(wù)。在分布式管道設(shè)計模式理論中，將每個管道分離出來會有更好的處理能力，更小的粒度，但是在我們進(jìn)行分機(jī)部署工作時，就需要指定大量的管道部署，這是一個非常復(fù)雜的過程，同時也會出現(xiàn)數(shù)據(jù)交換管道過多出現(xiàn)管道全局中心搶占問題。在本次設(shè)計的服務(wù)框架中，使用管道集合的方式集中的管理一些管道，這樣的做法會導(dǎo)致管道的高解耦合性有一定影響，但是在一定程度上我們可以在用戶對管道集合的設(shè)計部分分離出可能出現(xiàn)高耦合的任務(wù)。如圖4中分離出了文章分類管道，使得數(shù)據(jù)的處理和我們的分類任務(wù)分離使用不同的數(shù)據(jù)交換管道，來獲取更高的性能和錯誤恢復(fù)能力。

3.4? 對比實(shí)驗(yàn)

本次實(shí)驗(yàn)只采用完整任務(wù)的1/1 000的工作量，并且使用上述的管道服務(wù)框架，以及GoCollaborate框架，一個提供分布式服務(wù)管理搭建的輕量級通用框架，可以輕松地用它進(jìn)行編程，構(gòu)建擴(kuò)展，以及創(chuàng)建自己的高性能分布式服務(wù)。使用上述的2個框架同時實(shí)現(xiàn)對平安銀行、東航物流、中科軟3個企業(yè)在2020的年報分析，并且對2個不同框架做，丟包率、內(nèi)存使用情況、CPU負(fù)載情況、單位請求QPS做了比較研究。

3.5? 實(shí)驗(yàn)結(jié)果

在實(shí)驗(yàn)過程中使用pprof[9]，一種Go自帶的工具，可以做CPU和內(nèi)存的profiling。對2個不同框架對任務(wù)實(shí)現(xiàn)的內(nèi)存以及CPU負(fù)載情況進(jìn)行查看，結(jié)果如圖5所示。

圖5中可以觀察到管道服務(wù)框架的內(nèi)存和CPU的占用率都要大于GoCollaborate框架，換言之，管道服務(wù)框架的開銷較大，這很有可能是管道服務(wù)框架的管道全局中心中，產(chǎn)生大量的數(shù)據(jù)交換，以及恢復(fù)日志的處理導(dǎo)致的。同時在6、7、8時間點(diǎn)，管道服務(wù)框架的CPU占用明顯下降經(jīng)過分析，在6、7、8時間點(diǎn)，全局管道交換中出現(xiàn)高IO占用，管道服務(wù)框架，優(yōu)先處理數(shù)據(jù)保存流出管道的拉取推送任務(wù)，而GoCollaborate框架是平衡的，在高IO任務(wù)到來時，它必須分配更多的CPU資源去管理IO任務(wù)。

在本次實(shí)驗(yàn)中，為檢查每秒請求數(shù)（querypersecond，QPS）情況，使用自搭建Web服務(wù)器，只實(shí)現(xiàn)讀取接口，并對在單位時間內(nèi)，本次實(shí)驗(yàn)采用1分鐘作為運(yùn)行時間，使用Gin框架[10]（一個go語言實(shí)現(xiàn)的高性能web框架）對日志分析獲取單位時間內(nèi)的QPS量。

QPS=req（（請求數(shù)）/sec（秒）），在本次實(shí)驗(yàn)中單位時間一定，QPS=req/60。得到QPS數(shù)據(jù)如表1所示。

在單純QPS的檢測中，框架性能相差不大，對于單純的高IO任務(wù)，管道服務(wù)框架和GoCollaborate框架在宏觀上來看都是平衡的，那么QPS的瓶頸在gin服務(wù)器中。

在本次實(shí)驗(yàn)中丟包率以及總工作時間，使用系統(tǒng)運(yùn)行日志進(jìn)行分析，即在框架層面，每次發(fā)生數(shù)據(jù)傳輸丟失重新傳輸時，或者發(fā)生日志恢復(fù)時，認(rèn)為發(fā)生丟包。在本次使用中的丟包率指的是在應(yīng)用層發(fā)生重發(fā)的概率，忽略傳輸層的情況。使用W=重發(fā)數(shù)據(jù)包/發(fā)送數(shù)據(jù)包，來計算丟包率，結(jié)果如表2所示。

管道服務(wù)框架的丟包率要遠(yuǎn)大于GoCollaborate框架，經(jīng)過分析，這是由于管道服務(wù)框架在交互數(shù)據(jù)需要經(jīng)過，管道、管道交換通道、管道全局中心、管道交換通道、管道，5個過程，GoCollaborate框架只需要從一個服務(wù)到另外一個服務(wù)，2個過程，并且GoCollaborate框架保證數(shù)據(jù)安全在傳輸層中解決，管道服務(wù)框架的數(shù)據(jù)安全保障在應(yīng)用層中處理。在表現(xiàn)上管道服務(wù)框架的數(shù)據(jù)傳輸安全性較差，但在應(yīng)用層中進(jìn)行安全保證，使得在發(fā)生災(zāi)禍時，管道服務(wù)框架有更好的容災(zāi)能力。

4? 結(jié)? 論

特定的計算環(huán)境產(chǎn)生的不同特征的問題，本文的實(shí)驗(yàn)過程在不同特點(diǎn)，不同計算性能要求情況下的處理能力往往不同。在真實(shí)應(yīng)用環(huán)境下的性能可能達(dá)不到預(yù)期要求，隨著更多實(shí)際計算任務(wù)場景的出現(xiàn)，分布式管道如何更高效地解決計算機(jī)資源的處理、調(diào)度仍需更深層次的研究。通過結(jié)合本文研究的不足之處，須在以下方面進(jìn)行相應(yīng)改進(jìn)：

（1）在連續(xù)性任務(wù)中，若中間某一類數(shù)據(jù)管道全部斷開連接，則數(shù)據(jù)將被迫留在管道全局中心中，可能導(dǎo)致全局管道空間數(shù)據(jù)溢出。對于此問題可以在全局管道空間中對每個集合管道的推送添加緩存最大值，同時在管道交換通道中添加緩存和通知機(jī)制，嘗試重新喚醒斷開連接的管道，最終解決管道全局中心數(shù)據(jù)溢出問題。

（2）在數(shù)據(jù)推送過程中，數(shù)據(jù)在原管道—原管道交換通道—全局管道空間—目標(biāo)管道交換通道—目標(biāo)管道轉(zhuǎn)移。在此過程中，由于網(wǎng)絡(luò)交換的次數(shù)較多數(shù)據(jù)更易丟失。對于此問題，可以在數(shù)據(jù)交換頻繁，單次計算量較小的部分定義一個快速管道（實(shí)現(xiàn)管道于管道之間直接通信，犧牲容災(zāi)性），提高數(shù)據(jù)處理效率，降低框架丟包率。

（3）全局管道空間備份的時機(jī)。全局管道空間使用定時器對數(shù)據(jù)進(jìn)行定期備份，且對數(shù)據(jù)加鎖防止其在保存過程中被篡改。在系統(tǒng)在處理高負(fù)載任務(wù)時若全局管道空間進(jìn)行備份加鎖，使得管道交換通道無法進(jìn)行數(shù)據(jù)傳輸，則會影響其高計算密集任務(wù)的工作，導(dǎo)致任務(wù)長期阻塞等待。在此提出一種偵察機(jī)制，使得系統(tǒng)在執(zhí)行高IO任務(wù)時，有更高的備份優(yōu)先級，一定程度避免在進(jìn)行高CPU任務(wù)時進(jìn)行全局管道備份，將其和定時器相結(jié)合，有效提高系統(tǒng)計算能力。

參考文獻(xiàn)：

[1] HU H R，F(xiàn)ANG L L，YANG C H，et al. Research on Cloud Architecture of Enterprise Distributed Business Information System Based on SOA [J].Journal of Physics：Conference Series，2020，1684（1）：1-8.

[2] 徐旻洋，高承勇，周向東，等.基于微服務(wù)架構(gòu)的大型建筑設(shè)計企業(yè)生產(chǎn)業(yè)務(wù)平臺構(gòu)建 [J].土木建筑工程信息技術(shù)，2019，11（3）：89-95.

[3] 袁曉晨，張衛(wèi)山，高紹姝，等.基于微服務(wù)架構(gòu)的眾包圖像數(shù)據(jù)集標(biāo)注系統(tǒng) [J].計算機(jī)系統(tǒng)應(yīng)用，2021，30（5）：83-91.

[4] 鄧兆森.一種云平臺服務(wù)狀態(tài)顯示方法及相關(guān)裝置：CN1 12737882A [P].2021-04-30.

[5] DONG Y，ZHU P F，JIANG Z Y，et al. Real Time Data Distribution Technology of SCADA based on Redis [C]//Proceedings of 2016 International Conference on Computer，Mechatronics and Electronic Engineering （CMEE 2016）.Beijing：DEStech Publications，2016：190-194.

[6] 賈統(tǒng)，李影，吳中海.基于日志數(shù)據(jù)的分布式軟件系統(tǒng)故障診斷綜述 [J].軟件學(xué)報，2020，31（7）：1997-2018.

[7] 孫志龍，沙行勉，諸葛晴鳳，等.面向內(nèi)存文件系統(tǒng)的數(shù)據(jù)一致性更新機(jī)制研究 [J].計算機(jī)科學(xué)，2017，44（2）：222-227.

[8] 張晨躍，劉黎志，鄧開巍，等.基于MapReduce的樸素貝葉斯算法文本分類方法 [J].武漢工程大學(xué)學(xué)報，2021，43（1）：102-105.

[9] 向勇，湯衛(wèi)東，杜香燕，等.基于內(nèi)核跟蹤的動態(tài)函數(shù)調(diào)用圖生成方法 [J].計算機(jī)應(yīng)用研究，2015，32（4）：1095-1099.

[10] 張晶，黃小鋒.一種基于微服務(wù)的應(yīng)用框架 [J].計算機(jī)系統(tǒng)應(yīng)用，2016，25（9）：265-270.

作者簡介：戴振邦（2000—），男，漢族，福建莆田人，本科在讀，研究方向：分布式、數(shù)據(jù)挖掘、集群計算;江恩杰（2000—），男，漢族，福建漳州人，本科在讀，研究方向：人工智能、模式識別、云服務(wù);劉力嘉：（2000—），男，漢族，福建漳州人，本科在讀，研究方向：虛擬化;甘江偉（2000—），男，漢族，福建永安人，本科在讀，研究方向：微電子。