基于消息中間件的分布式游戲服務(wù)器架構(gòu)設(shè)計(jì)

摘要：對游戲服務(wù)器架構(gòu)進(jìn)行了深入研究，提出了一個(gè)基于消息隊(duì)列的分布式游戲服務(wù)器架構(gòu)設(shè)計(jì)。解決了傳統(tǒng)分布式網(wǎng)狀架構(gòu)在節(jié)點(diǎn)多時(shí)管理成本增加及節(jié)點(diǎn)間消息流量在內(nèi)網(wǎng)中幾何級增長的問題。并在此基礎(chǔ)上設(shè)計(jì)了一個(gè)游戲服務(wù)器通用架構(gòu)，該架構(gòu)在多個(gè)已經(jīng)上線的放置掛機(jī)類網(wǎng)絡(luò)游戲中使用，可以更好地應(yīng)對玩家需求變化引起的架構(gòu)調(diào)整，以及玩家數(shù)量波動(dòng)時(shí)快速擴(kuò)容或減容的需求。

關(guān)鍵詞：分布式；游戲服務(wù)器架構(gòu)；消息中間件；單服架構(gòu)；分服架構(gòu)

一、前言

隨著計(jì)算機(jī)網(wǎng)絡(luò)的發(fā)展和普及，網(wǎng)絡(luò)游戲逐漸成了最常見的娛樂方式。玩家群體的增加對游戲服務(wù)器的架構(gòu)提出了新的要求，傳統(tǒng)的服務(wù)器架構(gòu)已經(jīng)無法適應(yīng)海量玩家同時(shí)在線的需求。分布式逐漸成為主流，微服務(wù)等技術(shù)也開始逐漸應(yīng)用在新的網(wǎng)游架構(gòu)中。本文提出一種基于消息隊(duì)列的分布式網(wǎng)游服務(wù)器架構(gòu)，有效規(guī)避了傳統(tǒng)的基于網(wǎng)狀結(jié)構(gòu)的一系列缺點(diǎn)，為后繼服務(wù)器的負(fù)載均衡，服務(wù)能力動(dòng)態(tài)擴(kuò)容，微服務(wù)，以及跨區(qū)通訊打下了堅(jiān)實(shí)的基礎(chǔ)。

二、服務(wù)器架構(gòu)演變

（一）集中式服務(wù)器架構(gòu)

1.單服架構(gòu)

網(wǎng)絡(luò)游戲剛剛開始發(fā)展時(shí)，由于在線人數(shù)不多，而且游戲的業(yè)務(wù)邏輯也較簡單。早期的服務(wù)器基本是單服結(jié)構(gòu)，即所有的客戶端都連接到一臺單獨(dú)的服務(wù)器上，單獨(dú)的服務(wù)器上運(yùn)行一個(gè)獨(dú)立的服務(wù)進(jìn)程，處理客戶端的連接請求，以及所有的游戲邏輯。

這種結(jié)構(gòu)的特點(diǎn)是架構(gòu)簡單明了，所有的邏輯都在一個(gè)進(jìn)程內(nèi)，邏輯代碼非常簡單直接。在用戶量較小和邏輯簡單時(shí)可以快速開發(fā)出想要的功能，調(diào)試、測試也容易。但是隨著用戶量的增加，這種架構(gòu)的缺點(diǎn)開始慢慢顯露出來，單進(jìn)程的理論處理極限就是進(jìn)程當(dāng)前所在服務(wù)器的硬件處理能力。當(dāng)用戶的增加超過當(dāng)前服務(wù)器的硬件極限時(shí)，就無法承載更多的玩家。

2.分服架構(gòu)

為了解決單服架構(gòu)承載能力不足的問題，人們又提出了分服架構(gòu)。分服架構(gòu)的總體思想與集中式架構(gòu)類似，區(qū)別是引入了一個(gè)登錄服務(wù)器，玩家在登錄的時(shí)候先通過登錄服務(wù)器確定自己在哪個(gè)區(qū)服，等確定了區(qū)服地址后再登錄到相應(yīng)的服務(wù)器上面，后面的處理流程與單服架構(gòu)類似。通過分區(qū)服的引入，在玩家超過一個(gè)服務(wù)器的承載范圍后，將后面新加入的玩家加入新的服務(wù)器上面去，這樣可以有效規(guī)避單服務(wù)器承載能力不足的問題[1]。

分服架構(gòu)雖然解決了玩家增加后單服承載力不足的問題，但是還有一些其他的問題沒有解決。第一個(gè)問題是單區(qū)服的承載力依然有上限。當(dāng)游戲類型需要同一個(gè)區(qū)服的玩家數(shù)量多到一定程度才可以玩時(shí)，分服架構(gòu)依然滿足不了這種需求。第二個(gè)問題是隨著游戲類型的增加，游戲的復(fù)雜度也隨之增加。在傳統(tǒng)的單進(jìn)程模式下，所有的游戲邏輯都寫在同一個(gè)進(jìn)程內(nèi)，功能會相互耦合，對軟件的架構(gòu)能力要求變高。如果設(shè)計(jì)者沒有很好的架構(gòu)能力，很容易導(dǎo)致后期邏輯復(fù)雜化，耦合度增加，維護(hù)成本變高。由于復(fù)雜度增加，開發(fā)效率也會受到影響，系統(tǒng)的穩(wěn)定性無法保證。

（二）分布式服務(wù)器架構(gòu)

為了解決上面兩個(gè)問題，人們又提出了分布式的網(wǎng)游服務(wù)器架構(gòu)。分布式架構(gòu)是在單服架構(gòu)的基礎(chǔ)上演化出來的，它主要針對以下兩個(gè)方面做了改進(jìn)。

一是分布式架構(gòu)在物理上將單進(jìn)程拆分成多個(gè)進(jìn)程，并引入了進(jìn)程間的通信機(jī)制。多個(gè)進(jìn)程以某種方式自組織在一起，以進(jìn)程組的形式為一個(gè)區(qū)服提供服務(wù)。通過這種方式，突破了單區(qū)服承載能力有上限的問題，可以提供近乎無限的處理能力。

另外，分布式架構(gòu)在邏輯上將單進(jìn)程拆分成多個(gè)進(jìn)程。單服架構(gòu)中，一個(gè)游戲所有的邏輯都在同一個(gè)進(jìn)程中，所以結(jié)構(gòu)會變得很復(fù)雜。在分布式架構(gòu)中，區(qū)服中可包含多個(gè)不同類型的進(jìn)程。特定類型的進(jìn)程處理特定的問題，如客戶端接入進(jìn)程、聊天服務(wù)進(jìn)程等。不同類型的進(jìn)程通過進(jìn)程間通信能力互相協(xié)作，最終可以提供完整的游戲服務(wù)。由于特定類型的進(jìn)程只會處理特定的邏輯，所以它本身的邏輯結(jié)構(gòu)也會更清晰簡單，與其他系統(tǒng)的耦合性可以降到最低，后繼的邏輯開發(fā)與維護(hù)的成本也會下降到最低。

分布式架構(gòu)在解決了單服架構(gòu)問題的情況下，又引入了新的復(fù)雜度。由于分布式服務(wù)是分布在不同硬件上的很多進(jìn)程協(xié)作提供的，所以進(jìn)程間信息共享以及同步能力就變得非常重要，而這一切的基礎(chǔ)就是進(jìn)程間的通信能力。

進(jìn)程間的通信需要兩個(gè)要素，第一個(gè)是進(jìn)程必須知道當(dāng)前區(qū)服中還有哪些其他的進(jìn)程存在，并通過某種方式獲得它的標(biāo)識符或地址以及它們所能提供的服務(wù)。第二個(gè)是進(jìn)程必須由某種安全高效的方法投遞信息到其他的進(jìn)程。

了解區(qū)服中的活動(dòng)進(jìn)程信息有多種方式，比如通過共享的數(shù)據(jù)庫記錄當(dāng)前的進(jìn)程信息，然后進(jìn)程以輪詢的方式查詢這些信息，并維護(hù)一個(gè)當(dāng)前的進(jìn)程列表，包含其他進(jìn)程需要知道的一切信息（地址，標(biāo)識符，服務(wù)列表等）。也可以通過注冊進(jìn)程信息到服務(wù)發(fā)現(xiàn)服務(wù)（ETCD，ZooKeeper等），然后再通過監(jiān)控服務(wù)發(fā)現(xiàn)框架中的信息變化來獲取類似的信息。

進(jìn)程間的通信分幾種情況，如果不同進(jìn)程在同一臺服務(wù)器上，可以通過操作系統(tǒng)提供的共享內(nèi)存或管道等功能通信。如果進(jìn)程在不同的服務(wù)器上，可以通過標(biāo)準(zhǔn)的Socket網(wǎng)絡(luò)接口通信，視具體情況可以使用TCP或UDP協(xié)議。有些時(shí)候，為了統(tǒng)一協(xié)議，可以不區(qū)分本地或遠(yuǎn)程進(jìn)程，均采用相同的Socket接口通信。在本地情況下，會比原生的共享內(nèi)存等方式效率低一些，但幾乎可以忽略不計(jì)[2]。

（三）傳統(tǒng)分布式服務(wù)器架構(gòu)的拓?fù)浣Y(jié)構(gòu)

傳統(tǒng)的分布式服務(wù)器架構(gòu)一般采用網(wǎng)狀的拓?fù)浣Y(jié)構(gòu)，即每個(gè)進(jìn)程都擁有與其他進(jìn)程通信的通信鏈路。一個(gè)典型的進(jìn)程節(jié)點(diǎn)生命周期分為以下幾個(gè)階段。

當(dāng)一個(gè)進(jìn)程啟動(dòng)時(shí)，先注冊自己到服務(wù)發(fā)現(xiàn)服務(wù)上。再從服務(wù)發(fā)現(xiàn)服務(wù)上查詢當(dāng)前區(qū)服中活動(dòng)的進(jìn)程節(jié)點(diǎn)列表。遍歷所有的列表，然后和列表中的其他節(jié)點(diǎn)建立連接。當(dāng)所有的節(jié)點(diǎn)連接都建立完成后，當(dāng)前節(jié)點(diǎn)啟動(dòng)成功。

節(jié)點(diǎn)在正常運(yùn)行過程中，不斷地給自己關(guān)心的節(jié)點(diǎn)發(fā)送心跳消息，一旦發(fā)現(xiàn)鏈路斷開，立即發(fā)起重連請求，節(jié)點(diǎn)主要保持與其他節(jié)點(diǎn)的鏈路正常通信。

當(dāng)有新的節(jié)點(diǎn)啟動(dòng)時(shí)，由于它會主動(dòng)注冊自己到服務(wù)器的發(fā)現(xiàn)服務(wù)，所以在區(qū)服中的其他節(jié)點(diǎn)都可以收到通知，然后主要與新加入的節(jié)點(diǎn)建立聯(lián)系。所以每一對節(jié)點(diǎn)都會有兩個(gè)鏈路，每個(gè)鏈路都是單向的。網(wǎng)狀結(jié)構(gòu)的拓?fù)潢P(guān)系基本上是現(xiàn)在游戲服務(wù)器架構(gòu)的共識。

（四）傳統(tǒng)分布式網(wǎng)狀結(jié)構(gòu)的問題

網(wǎng)狀結(jié)構(gòu)已經(jīng)可以滿足大多數(shù)的業(yè)務(wù)需求，但隨著行業(yè)的發(fā)展，游戲邏輯進(jìn)一步復(fù)雜，分布式節(jié)點(diǎn)數(shù)量變得越來越多，網(wǎng)狀架構(gòu)開始出現(xiàn)一些顯著的問題。

首先碰到的第一個(gè)問題是復(fù)雜度的增加。任意一對節(jié)點(diǎn)都會有兩個(gè)通信鏈路。當(dāng)區(qū)服中的節(jié)點(diǎn)數(shù)量為n，單個(gè)節(jié)點(diǎn)就需要維護(hù)2（n-1）條通信鏈路。整個(gè)結(jié)構(gòu)中通信鏈路的總數(shù)為2n（n-1）?？梢钥闯?，隨著節(jié)點(diǎn)數(shù)量n的增加，通信鏈路的數(shù)量會以平方數(shù)的速度增加。而現(xiàn)在的游戲，如果游戲類型較復(fù)雜的話，很多都會引入微服務(wù)的架構(gòu)，導(dǎo)致節(jié)點(diǎn)的類型和數(shù)量都快速增加，整個(gè)系統(tǒng)的復(fù)雜度也很容易失控。由于每個(gè)節(jié)點(diǎn)都要維護(hù)2（n-1）條通信鏈路，而每個(gè)通信鏈路一般都會有專有的線程或協(xié)程來處理消息、接收邏輯，當(dāng)鏈路數(shù)量多到一定程度時(shí)，節(jié)點(diǎn)會消耗大量的資源維護(hù)鏈路，但實(shí)際情況也不是所有的鏈路都會被使用，這樣會造成系統(tǒng)資源的大量浪費(fèi)。隨著鏈路數(shù)量的增加，由于單個(gè)節(jié)點(diǎn)啟動(dòng)會創(chuàng)建所有其他節(jié)點(diǎn)的鏈路，會導(dǎo)致整個(gè)系統(tǒng)的耦合性增加，節(jié)點(diǎn)的啟動(dòng)速度變慢，分布式系統(tǒng)帶來的靈活擴(kuò)展性也會受到影響。

網(wǎng)狀系統(tǒng)另一個(gè)嚴(yán)重的問題是可靠性問題。在分布式系統(tǒng)中，維護(hù)數(shù)據(jù)的正確性一定要依賴于完全可靠的通信鏈路，甚至在節(jié)點(diǎn)重新拉起后發(fā)送的消息也應(yīng)該能正常收到。而網(wǎng)狀結(jié)構(gòu)依賴的消息鏈路過于原始。首先，它是和進(jìn)程強(qiáng)綁定的，也就是說當(dāng)節(jié)點(diǎn)進(jìn)程發(fā)生故障需要重新拉起時(shí)，消息鏈路就會被重建；其次，消息隊(duì)列是進(jìn)程間維護(hù)的，當(dāng)網(wǎng)絡(luò)發(fā)生波動(dòng)時(shí)，進(jìn)程間的消息鏈路有可能斷開，觸發(fā)重聯(lián)機(jī)制。換句話來說，消息鏈路是不可靠的，有可能丟失消息。在分布式系統(tǒng)中，如果無法保證消息的可靠性，會對系統(tǒng)造成嚴(yán)重的影響。上層功能需要加入大量的邏輯以確保在消息丟失的情況下，節(jié)點(diǎn)的狀態(tài)不會發(fā)生錯(cuò)亂。這會極大地增加上層邏輯代碼的復(fù)雜度，引入更多不可預(yù)料的漏洞。

三、基于消息總線的架構(gòu)方案

為了應(yīng)對節(jié)點(diǎn)數(shù)量增加時(shí)網(wǎng)狀結(jié)構(gòu)的問題，本文提出了一種新的基于消息總線的架構(gòu)方案。該方案主要依賴兩個(gè)獨(dú)立的組件：服務(wù)發(fā)現(xiàn)以及消息總線。

服務(wù)發(fā)現(xiàn)主要解決區(qū)服內(nèi)節(jié)點(diǎn)信息的同步問題。服務(wù)發(fā)現(xiàn)主要提供兩種能力：發(fā)現(xiàn)別人、讓別人發(fā)現(xiàn)自己。當(dāng)節(jié)點(diǎn)連接到服務(wù)發(fā)現(xiàn)服務(wù)時(shí) ，它可以通過服務(wù)發(fā)現(xiàn)的查詢能力查詢到和它一樣連接到同一個(gè)服務(wù)發(fā)現(xiàn)服務(wù)的其他節(jié)點(diǎn)。通過這種機(jī)制，節(jié)點(diǎn)擁有了發(fā)現(xiàn)別人的能力。當(dāng)一個(gè)節(jié)點(diǎn)連接到服務(wù)發(fā)現(xiàn)服務(wù)時(shí)，所有在同一個(gè)服務(wù)上的其他節(jié)點(diǎn)都可以收到新節(jié)點(diǎn)接入的通知。當(dāng)然，當(dāng)一個(gè)節(jié)點(diǎn)從服務(wù)發(fā)現(xiàn)服務(wù)斷開時(shí)，其他節(jié)點(diǎn)也可以收到老節(jié)點(diǎn)離開的通知。通過這種機(jī)制，節(jié)點(diǎn)就擁有了讓別人發(fā)現(xiàn)自己的能力。當(dāng)任意一個(gè)節(jié)點(diǎn)都有發(fā)現(xiàn)別人和被別人發(fā)現(xiàn)的能力時(shí)，就相當(dāng)于掌握了整個(gè)分布式系統(tǒng)的全景信息。

服務(wù)發(fā)現(xiàn)解決的是專有問題，所以可以獨(dú)立于整個(gè)架構(gòu)之外去設(shè)計(jì)，架構(gòu)只是單向依賴服務(wù)發(fā)現(xiàn)，而服務(wù)發(fā)現(xiàn)并不依賴于分布式架構(gòu)本身。服務(wù)發(fā)現(xiàn)目前已經(jīng)有很多成熟的解決方案，如ETCD，ZooKeeper是專業(yè)做服務(wù)發(fā)現(xiàn)的開源項(xiàng)目。Redis新版中的Pub/Sub機(jī)制也可以用來做簡單的服務(wù)發(fā)現(xiàn)。專業(yè)的服務(wù)發(fā)現(xiàn)項(xiàng)目一般支持集群，實(shí)現(xiàn)了嚴(yán)苛的數(shù)據(jù)一致性協(xié)議，可靠性、穩(wěn)定性和可擴(kuò)展性都是可以保證的。

消息總線主要解決的是分布式系統(tǒng)中節(jié)點(diǎn)之間的消息傳遞功能。消息總線隔離了需要通信的進(jìn)程，它們之間不再需要保持單獨(dú)的通信鏈路，也不需要知道彼此的存在。節(jié)點(diǎn)都只是單向地和消息總線保持連接，所有的消息都通過消息總線來統(tǒng)一傳遞。整體的拓?fù)浼軜?gòu)會變成魚骨狀，相比網(wǎng)狀結(jié)構(gòu)，可以極大地減少消息鏈路的數(shù)量。形象點(diǎn)說，消息總線就像一個(gè)全自動(dòng)的包裹投遞系統(tǒng)，每個(gè)節(jié)點(diǎn)都和系統(tǒng)連接，并擁有一個(gè)地址。只要給包裹填好地址，然后提交給消息總線，總線就一定會保證把消息投遞到正確的地方。當(dāng)然，地址正確是前提。在這個(gè)過程中，投遞者完全不用關(guān)心對方在哪里，狀況如何，網(wǎng)絡(luò)有沒有波動(dòng)等[3]。

消息總線本質(zhì)上是把原來節(jié)點(diǎn)之間的通信鏈路抽象出來統(tǒng)一管理，所以解決的也是專有問題。消息總線和分布式架構(gòu)也是單向依賴。消息總線不依賴于分布式架構(gòu)，而分布式架構(gòu)依賴消息總線。消息總線目前也有很多成熟的開源項(xiàng)目，如RabbitMQ，NSQ，NATS等。每個(gè)項(xiàng)目適合的場景不同，但是解決的問題都是類似的。現(xiàn)代的消息總線不僅可以解決消息投遞的問題，也可以做消息緩存、消息記錄、可靠投遞管理等。在關(guān)閉一些高級特性的情況下，高效的消息總線幾乎可以做到和原生Socket類似的投遞效率，完全可以在游戲服務(wù)器底層大規(guī)模使用。其流程分為節(jié)點(diǎn)啟動(dòng)和節(jié)點(diǎn)消息投遞兩個(gè)步驟。節(jié)點(diǎn)啟動(dòng)時(shí)，將自己注冊到服務(wù)發(fā)現(xiàn)中，并從服務(wù)發(fā)現(xiàn)拿到其他節(jié)點(diǎn)的地址，更新全局信息，連接到消息總線上；節(jié)點(diǎn)需要投遞消息時(shí)，從全局信息中拿到目標(biāo)節(jié)點(diǎn)的地址，然后將消息投遞到消息總線上去。從以上流程可以看出，基于消息總線的架構(gòu)比網(wǎng)狀結(jié)構(gòu)節(jié)點(diǎn)的啟動(dòng)以及消息投遞過程簡化了很多。

基于消息總線的拓?fù)鋱D如圖1所示，新架構(gòu)下節(jié)點(diǎn)的通信鏈路大幅減少，每個(gè)節(jié)點(diǎn)只需要一個(gè)消息鏈路，在n個(gè)節(jié)點(diǎn)的系統(tǒng)中也只存在n個(gè)通信鏈路。通信鏈路的減少對應(yīng)著系統(tǒng)復(fù)雜度的降低，當(dāng)系統(tǒng)需要擴(kuò)容時(shí)，節(jié)點(diǎn)增加完全不會對系統(tǒng)的壓力產(chǎn)生影響。

新架構(gòu)下節(jié)點(diǎn)之間都被消息總線隔開，互相完全不知道對方的存在，也就意味著節(jié)點(diǎn)之間是完全解耦的，整體的架構(gòu)更加清晰合理。

消息總線負(fù)責(zé)了整個(gè)系統(tǒng)消息的傳遞，只需要在消息總線中加入可靠性消息投遞保證。對節(jié)點(diǎn)而言就可以認(rèn)為消息投遞是可靠的，節(jié)點(diǎn)本身可以不用處理由于消息丟失引起的狀態(tài)出錯(cuò)的問題?？梢允构?jié)點(diǎn)本身的上層業(yè)務(wù)邏輯更加清晰簡單，系統(tǒng)的穩(wěn)定性也會提升[4]。

四、基于消息總線架構(gòu)的問題及解決

相對于網(wǎng)狀結(jié)構(gòu)，新的架構(gòu)雖然解決了網(wǎng)狀結(jié)構(gòu)的大多數(shù)問題，但有可能引入一些新的問題，下面是一些可能的問題及其解決方案。

主要碰到的是性能問題，相比傳統(tǒng)的直接通信線路，基于消息總線的消息投遞需要經(jīng)歷消息總線的一次中轉(zhuǎn)，性能上會有所折損，性能包括吞吐量和延時(shí)兩個(gè)部分。

首先來討論吞吐量的問題。測試結(jié)果顯示設(shè)計(jì)良好的消息總線，在合理的設(shè)置下，基本上可以達(dá)到和原生TCP類似的性能。表1為常見消息總線和原生TCP吞吐量的對比?？梢钥闯鰜?，NATS的吞吐量幾乎接近原生的吞吐量。而RabbitMQ差很多，主要原因是RabbitMQ內(nèi)部做了很多額外的事情，如消息的序列化、防重發(fā)等。但是對游戲服務(wù)器來說，NATS的默認(rèn)設(shè)置就足夠使用，所以使用NATS基本上不會碰到吞吐量的問題。表1的測試使用4核8G CentOS7.0系統(tǒng)，單個(gè)消息包大小為1K。

第二個(gè)是消息延時(shí)的問題。相比直連的通信鏈路，經(jīng)過消息總線的延時(shí)主要由以下部分組成：消息從節(jié)點(diǎn)到消息總線；消到目標(biāo)節(jié)點(diǎn)的時(shí)間。由于節(jié)點(diǎn)和消息總線一般都在內(nèi)網(wǎng)，所以它們的延時(shí)基本在1ms以內(nèi)，可以忽略不計(jì)。而在消息中間件中停留的時(shí)間如表2所示。可以看出NATS的延時(shí)時(shí)間都在2ms以內(nèi)，基本可以忽略不計(jì)。NATS延時(shí)比較低的原因是它采用了特殊的設(shè)計(jì)來降低延時(shí)。表2測試使用4核8G CentOS7.0系統(tǒng)，單個(gè)消息包大小為1K，發(fā)送10000次取平均值。

由于服務(wù)器一般都工作在內(nèi)網(wǎng)環(huán)境，而且節(jié)點(diǎn)之間的消息頻率一般都不高，所以使用NATS完全可以滿足節(jié)點(diǎn)之間日常的消息投遞需求。另外，消息總線一般都支持集群，當(dāng)需要的吞吐量沒辦法滿足需求時(shí)，還可以通過增加集群的節(jié)點(diǎn)來提升消息總線的處理能力。

五、結(jié)語

基于消息中間件的新架構(gòu)不僅解決了傳統(tǒng)網(wǎng)狀架構(gòu)的種種問題，而且還帶來了一些額外的好處，網(wǎng)絡(luò)游戲一般都會有個(gè)跨區(qū)的功能，傳統(tǒng)架構(gòu)下開發(fā)相關(guān)的功能為了實(shí)現(xiàn)跨區(qū)通信都要引入很多復(fù)雜的邏輯。而在新架構(gòu)中，處理跨區(qū)的問題只需要通過配置一個(gè)消息總線的網(wǎng)關(guān)，把兩個(gè)服務(wù)區(qū)的消息總線打通即可，上層幾乎不需要額外的工作處理跨服邏輯，極大地簡化了相關(guān)功能的開發(fā)。該架構(gòu)設(shè)計(jì)已經(jīng)在生產(chǎn)環(huán)境中成功部署運(yùn)行，反映良好。

參考文獻(xiàn)

[1]胡棟梁，秦曉軍，王曉鋒.基于消息中間件的分布式網(wǎng)絡(luò)掃描[J].計(jì)算機(jī)工程，2020，46（12）：163-170.

[2]姜夢蘭. 于消息中間件服務(wù)可靠性保障方案的研究與實(shí)現(xiàn)[D].北京：電子科技大學(xué)，2010.

[3]李文逍，楊小虎.基于分布式緩存的消息中間件存儲模型[J].計(jì)算機(jī)工程，2010，36（13）：93-95.

[4]馬躍，何雨婷，尹震宇，等.一種面向OPC UA消息通信的多優(yōu)先級動(dòng)態(tài)調(diào)度算法的設(shè)計(jì)與實(shí)現(xiàn)[J].小型微型計(jì)算機(jī)系統(tǒng)，2021，42（08）：1747-1752.

基金項(xiàng)目：蘇州市科技發(fā)展規(guī)劃項(xiàng)目（項(xiàng)目編號：SYG201803）

作者單位：胡鵬昱，上海農(nóng)林職業(yè)技術(shù)學(xué)院；王曉軍，上海征途信息技術(shù)有限公司中臺研究所

■ 責(zé)任編輯：尚丹