1 引言
在互聯(lián)網(wǎng)支持的大數(shù)據(jù)應(yīng)用系統(tǒng)中，實(shí)體行為通常通過(guò)消息交流產(chǎn)生相互影響，實(shí)體行為之間是并發(fā)的、獨(dú)立的、自演化的。所有實(shí)體的行為決定了系統(tǒng)的行為，在系統(tǒng)的穩(wěn)定態(tài)下個(gè)別實(shí)體的變異不會(huì)影響整個(gè)系統(tǒng)的功能，雖然每個(gè)實(shí)體的行為具有確定性，但它們所作用的系統(tǒng)演化結(jié)果具有不確定性。也就是說(shuō)，互聯(lián)網(wǎng)中的所有個(gè)體構(gòu)成了巨大的并發(fā)計(jì)算機(jī)，每一個(gè)個(gè)體通過(guò)與其他個(gè)體進(jìn)行信息交互實(shí)現(xiàn)各自的計(jì)算，并且得出整個(gè)系統(tǒng)的運(yùn)行結(jié)果。如果將這種在互聯(lián)網(wǎng)世界表現(xiàn)出來(lái)的行為方式運(yùn)用到程序架構(gòu)設(shè)計(jì)中，由個(gè)體的消息來(lái)驅(qū)動(dòng)程序，降低個(gè)體變異對(duì)整個(gè)系統(tǒng)的影響，形成一種新的開(kāi)發(fā)框架，將會(huì)是程序設(shè)計(jì)的一種新思路，可以看作在程序?qū)用婺M自然系統(tǒng)的行為。比如，很多大數(shù)據(jù)應(yīng)用系統(tǒng)由于個(gè)體行為與整個(gè)系統(tǒng)性能有著強(qiáng)關(guān)聯(lián)性，其編程方法和開(kāi)發(fā)模式就需要解決實(shí)體的動(dòng)態(tài)性、不確定性、并發(fā)性，通過(guò)模擬自然系統(tǒng)的行為和演化模式，實(shí)現(xiàn)程序的靈活性、頑健性等問(wèn)題。
在大數(shù)據(jù)應(yīng)用系統(tǒng)中，已出現(xiàn)很多實(shí)際問(wèn)題需要采用新的程序架構(gòu)來(lái)完成特定的功能要求。比如在智慧城市中，許多用戶(hù)之間共用一套消息管理系統(tǒng)，消息管理系統(tǒng)可將消息主動(dòng)推送給相應(yīng)的用戶(hù)，而用戶(hù)之間很少進(jìn)行聯(lián)系。在傳統(tǒng)的面向?qū)ο蟮某绦蛟O(shè)計(jì)方法中，對(duì)象之間是相互通信且彼此聯(lián)系的，任何一個(gè)對(duì)象的加入或者退出都需要告知其他對(duì)象，簡(jiǎn)單來(lái)說(shuō)就是每個(gè)對(duì)象內(nèi)部都有一套自己的消息管理系統(tǒng)。但是在大數(shù)據(jù)應(yīng)用中，多元數(shù)據(jù)的融合卻成為重要的問(wèn)題，這就給程序設(shè)計(jì)帶來(lái)新的問(wèn)題，即動(dòng)態(tài)融合的數(shù)據(jù)如何更好地應(yīng)用于系統(tǒng)，以實(shí)現(xiàn)“融合、跨界、基礎(chǔ)、突破”。
針對(duì)這類(lèi)大數(shù)據(jù)應(yīng)用，一種新的程序開(kāi)發(fā)架構(gòu)正在形成，這就是面向?qū)嶓w、基于消息驅(qū)動(dòng)的開(kāi)發(fā)架構(gòu)——消息驅(qū)動(dòng)架構(gòu)（massage drivenframework，MDF）。MDF在結(jié)構(gòu)上沒(méi)有傳統(tǒng)的主程序，而是分為3個(gè)模塊，即實(shí)體模塊、消息模塊和數(shù)據(jù)及顯示模塊。實(shí)體類(lèi)似于對(duì)象，封裝了數(shù)據(jù)和操作，形成獨(dú)立的運(yùn)行單元。但是實(shí)體之間沒(méi)有直接聯(lián)系，所有的實(shí)體都是基于消息控制的。MDF提供了一種在網(wǎng)絡(luò)環(huán)境下，共同開(kāi)發(fā)系統(tǒng)的機(jī)制，遵守事先規(guī)定好的規(guī)范，開(kāi)發(fā)人員不需要有溝通聯(lián)系，根據(jù)規(guī)范自行開(kāi)發(fā)應(yīng)用模塊（實(shí)體），然后加入系統(tǒng)中運(yùn)行，并且還可以隨時(shí)退出，這些操作都無(wú)需與系統(tǒng)其他用戶(hù)和管理人員打招呼。所有這些實(shí)體（用戶(hù)）行為決定了系統(tǒng)的行為，個(gè)別實(shí)體的消亡或變化不影響整個(gè)系統(tǒng)的功能。MDF是一種在互聯(lián)網(wǎng)環(huán)境下的編程框架，支持眾多實(shí)體參與的共同開(kāi)發(fā)模式，它建立一種直接模擬自然和社會(huì)系統(tǒng)復(fù)雜行為運(yùn)行的編程方法，排除個(gè)別變異實(shí)體對(duì)整個(gè)系統(tǒng)功能的影響；探索一種新的應(yīng)對(duì)大數(shù)據(jù)問(wèn)題高并發(fā)、大流量、用戶(hù)獨(dú)立的解決方案，滿(mǎn)足新的應(yīng)用需求。
消息管理是MDF重要的組成部分，可以說(shuō)是整個(gè)系統(tǒng)的中樞，所有實(shí)體的運(yùn)行要靠消息管理進(jìn)行協(xié)同，因此消息管理模塊的設(shè)計(jì)與開(kāi)發(fā)是整個(gè)系統(tǒng)的關(guān)鍵內(nèi)容。這里面主要有三大挑戰(zhàn)：一是在MDF中，所有的通信方式都被嚴(yán)格定義為消息，不同類(lèi)型的消息有著不同的處理方式，消息管理器如何在消息數(shù)量龐大的情況下識(shí)別消息類(lèi)型，盡可能提高消息的處理準(zhǔn)確率；二是在消息維護(hù)過(guò)程中，如何通過(guò)調(diào)度策略，以?xún)?yōu)化各種不同類(lèi)型消息的處理和管理，使得在消息交互過(guò)程中盡量減少資源開(kāi)銷(xiāo)和成本；三是在消息接收和發(fā)送過(guò)程中，尤其在消息數(shù)量龐大的情況下，消息必然出現(xiàn)排隊(duì)情況，如何設(shè)計(jì)合理算法，保證不同優(yōu)先級(jí)的消息能夠及時(shí)得到發(fā)送，又避免出現(xiàn)消息長(zhǎng)期等待不被處理的情況。
本文中指的消息，相對(duì)于已有的事件驅(qū)動(dòng)（event-driven）中的事件有所不同，事件的定義更加廣泛，可以是程序本身發(fā)出的信息，也可以是終端設(shè)備發(fā)出的請(qǐng)求。事件的管理和處理需要有一套復(fù)雜的硬軟件設(shè)備來(lái)完成。消息只是用戶(hù)程序（終端應(yīng)用程序）發(fā)出的一些文字序列，因此比起事件來(lái)說(shuō)，在類(lèi)型和內(nèi)容上要簡(jiǎn)單的多。理論上說(shuō)，事件驅(qū)動(dòng)的技術(shù)可以用來(lái)產(chǎn)生消息驅(qū)動(dòng)程序，但是不如另外為消息驅(qū)動(dòng)重新定制一種架構(gòu)，在應(yīng)用系統(tǒng)開(kāi)發(fā)中會(huì)更加有效和簡(jiǎn)單。
消息管理模塊在MDF中起到了中心的作用。本文設(shè)計(jì)并實(shí)現(xiàn)了MDF的消息管理模塊，包括以下3個(gè)方面：
● 定義了消息的基本格式，制定了消息池的語(yǔ)言規(guī)范，通過(guò)消息表單的配置，實(shí)現(xiàn)不同類(lèi)型消息的區(qū)別管理；
● 利用現(xiàn)有的編程語(yǔ)言Java開(kāi)發(fā)了消息維護(hù)中間件，根據(jù)消息規(guī)范的表單配置自動(dòng)生成消息類(lèi)型管理，實(shí)現(xiàn)消息的接收、維護(hù)、存儲(chǔ)和發(fā)送等核心功能；
● 開(kāi)發(fā)了中間件，接受實(shí)體對(duì)于消息管理模塊的操作，包括查詢(xún)、檢索以及對(duì)于各種類(lèi)型消息的定義變更，滿(mǎn)足了MDF中實(shí)體運(yùn)行和變化的需要。
在MDF中，實(shí)體的數(shù)量是可變的，實(shí)體的類(lèi)型是多樣的。所有實(shí)體發(fā)送的消息和接收的消息將遵循統(tǒng)一的格式，實(shí)體需要向系統(tǒng)聲明的是它的URL地址、消息類(lèi)型、消息發(fā)送要求等。URL 地址提供了該實(shí)體消息發(fā)送和接收的接口。消息類(lèi)型和消息發(fā)送要求提供了消息的處理方式，這種要求被消息管理模塊響應(yīng)，并被正確維護(hù)。一個(gè)系統(tǒng)中的實(shí)體類(lèi)型是多種的，每一種實(shí)體類(lèi)型被定義了消息格式，同一類(lèi)型的實(shí)體必須按照相同的消息格式發(fā)送消息，系統(tǒng)的消息管理模塊在邏輯上是唯一的。所以消息管理模塊的設(shè)計(jì)為實(shí)現(xiàn)MDF的并發(fā)性、動(dòng)態(tài)性、頑健性、不確定性和跨平臺(tái)性等重要特性奠定了基礎(chǔ)。
2 相關(guān)工作
隨著計(jì)算機(jī)經(jīng)驗(yàn)和軟件技術(shù)的發(fā)展，計(jì)算機(jī)編程語(yǔ)言經(jīng)歷了機(jī)器語(yǔ)言、匯編語(yǔ)言、面向過(guò)程的程序設(shè)計(jì)語(yǔ)言以及面向?qū)ο蟮某绦蛟O(shè)計(jì)語(yǔ)言階段[6]。具體的語(yǔ)言不勝枚舉，見(jiàn)表1。
表1 編程語(yǔ)言的發(fā)展
隨著編程語(yǔ)言的發(fā)展，計(jì)算機(jī)程序設(shè)計(jì)的方法也主要經(jīng)歷了3個(gè)階段的發(fā)展：面向機(jī)器的程序設(shè)計(jì)、面向過(guò)程的程序設(shè)計(jì)和面向?qū)ο蟮某绦蛟O(shè)計(jì)。
人類(lèi)和計(jì)算機(jī)進(jìn)行交流最開(kāi)始的語(yǔ)言是由計(jì)算機(jī)可以直接識(shí)別的二進(jìn)制指令組成的機(jī)器語(yǔ)言，在這個(gè)時(shí)期，計(jì)算機(jī)的程序架構(gòu)就是直接描述機(jī)器操作，因此這時(shí)的程序稱(chēng)為面向機(jī)器的程序架構(gòu)。隨著高級(jí)程序語(yǔ)言的出現(xiàn)，面向過(guò)程的程序架構(gòu)被提出，這種結(jié)構(gòu)化的程序設(shè)計(jì)采用了“自頂向下，逐步求精”的思想，將計(jì)算問(wèn)題模塊分化，功能分解，大的問(wèn)題化解為若干個(gè)小問(wèn)題，大大提高了工作效率，也利于程序的維護(hù)。當(dāng)然，面向過(guò)程的設(shè)計(jì)方法也存在一定缺點(diǎn)，最主要的是該方法編寫(xiě)的程序是一系列的線(xiàn)性步驟，這種編程方式必須按照線(xiàn)性步驟從頭到尾編寫(xiě)代碼，過(guò)程枯燥且不易修改，代碼的靈活性和可移植性都較差。為了克服這一困難，面向?qū)ο蟮某绦蚣軜?gòu)應(yīng)運(yùn)而生，其主要思想是“注重對(duì)象，抽象成類(lèi)”，不再?gòu)?qiáng)調(diào)過(guò)程，更側(cè)重于對(duì)對(duì)象的操作。對(duì)象是數(shù)據(jù)和操作的封裝體，與客觀實(shí)體直接對(duì)應(yīng)。通過(guò)封裝使對(duì)象變得獨(dú)立，只能通過(guò)預(yù)先設(shè)定的方法與對(duì)象交談，在構(gòu)建代碼的過(guò)程中通過(guò)繼承，減少冗余代碼的同時(shí)又可擴(kuò)展現(xiàn)有代碼；封裝可減少外界對(duì)程序的干擾；且面向?qū)ο蟮南到y(tǒng)很容易切分成很多獨(dú)立的部分，將系統(tǒng)化繁為簡(jiǎn)，同時(shí)這種方法可以使系統(tǒng)從小到大逐步升級(jí)。但傳統(tǒng)的面向?qū)ο蠹軜?gòu)仍存在不足，對(duì)象之間需要建立自己的通信通道，所有對(duì)象都需要了解一定的環(huán)境參數(shù)。但是在互聯(lián)網(wǎng)環(huán)境中某些由眾多用戶(hù)動(dòng)態(tài)參與的應(yīng)用系統(tǒng)中，例如購(gòu)物、游戲、社區(qū)等，它們的特點(diǎn)是用戶(hù)眾多且不確定，并且在大多數(shù)情況下，用戶(hù)不需要了解過(guò)多的運(yùn)行要求和參數(shù)，而且用戶(hù)之間是透明的，也就是用戶(hù)之間可能不知道對(duì)方的存在，因此也不能有直接的溝通，對(duì)于這類(lèi)程序的開(kāi)發(fā)就需要提供一種更為自由和開(kāi)放的編程模式。從目前主要是個(gè)人和小團(tuán)隊(duì)開(kāi)發(fā)的模式，逐步過(guò)渡到可以由彼此互不認(rèn)識(shí)的眾多用戶(hù)共同開(kāi)發(fā)的模式，讓眾多的用戶(hù)包括非計(jì)算機(jī)專(zhuān)業(yè)的用戶(hù)也可以參與到系統(tǒng)的開(kāi)發(fā)和運(yùn)行中，使得每一個(gè)用戶(hù)既是程序的應(yīng)用者也是程序的開(kāi)發(fā)者，將更加能夠體現(xiàn)大數(shù)據(jù)應(yīng)用的特點(diǎn)。
本文提出的MDF的程序設(shè)計(jì)方法的主要思想是“實(shí)體獨(dú)立，消息驅(qū)動(dòng)”，各個(gè)實(shí)體之間遵循相同的消息通信協(xié)議，參與設(shè)計(jì)和開(kāi)發(fā)的人員只需輸入框架指定的幾個(gè)參數(shù)就可參與開(kāi)發(fā)，因此開(kāi)發(fā)人員不需要相互溝通，大家只需要根據(jù)協(xié)議和規(guī)范就可以進(jìn)行各自的應(yīng)用開(kāi)發(fā)，最終組成一個(gè)龐大的應(yīng)用系統(tǒng)，讓更多的用戶(hù)根據(jù)個(gè)性化的要求方便地使用。
3 MDF架構(gòu)與消息管理模塊
3.1 MDF架構(gòu)
MDF沒(méi)有傳統(tǒng)意義上的主體程序，而是由實(shí)體、消息和數(shù)據(jù)顯示3個(gè)部分組成�？傮w來(lái)說(shuō)，MDF是模擬自然和社會(huì)系統(tǒng)的運(yùn)行模式，MDF所有運(yùn)行都是通過(guò)消息驅(qū)動(dòng)的。任何用戶(hù)都可以成為系統(tǒng)的組成部分，稱(chēng)之為實(shí)體，或者系統(tǒng)對(duì)象。程序開(kāi)發(fā)者只發(fā)布系統(tǒng)規(guī)范，系統(tǒng)規(guī)范指明實(shí)體的類(lèi)型、實(shí)體的動(dòng)作定義、實(shí)體的消息構(gòu)成、實(shí)體消息的內(nèi)容格式與解釋以及實(shí)體的登錄方法、實(shí)體生命周期等。一般地，規(guī)范提供實(shí)體樣式。系統(tǒng)規(guī)范還會(huì)提供實(shí)體與數(shù)據(jù)顯示部分的數(shù)據(jù)交換方式、運(yùn)行結(jié)果顯示的方式以及相應(yīng)的顯示控制軟件，由數(shù)據(jù)顯示部分具體執(zhí)行。規(guī)范是開(kāi)放的，用戶(hù)可以根據(jù)系統(tǒng)規(guī)范開(kāi)發(fā)實(shí)體，或者實(shí)體樣式填好參數(shù)進(jìn)行注冊(cè)，進(jìn)入系統(tǒng)運(yùn)行；也可以根據(jù)規(guī)范自行開(kāi)發(fā)顯示模塊，獲取個(gè)性化的顯示方式。實(shí)體的地位是平等的，實(shí)體的加入和退出完全是自由的，雖然會(huì)影響系統(tǒng)的運(yùn)行結(jié)果，但是一般不會(huì)影響系統(tǒng)的功能。消息部分是實(shí)體之間進(jìn)行信息交互的中介，實(shí)體之間并不直接通信，而是借助消息部分進(jìn)行轉(zhuǎn)發(fā)。實(shí)體的動(dòng)作由消息定義，實(shí)體通過(guò)發(fā)送和接收消息來(lái)實(shí)行具體動(dòng)作。實(shí)體的功能以及如何由消息定義動(dòng)作在系統(tǒng)規(guī)范中予以說(shuō)明。數(shù)據(jù)顯示部分提供運(yùn)行結(jié)果和過(guò)程的顯示。MDF通過(guò)3個(gè)模塊實(shí)現(xiàn)這些功能，分別是實(shí)體管理模塊、消息管理模塊和由數(shù)據(jù)庫(kù)和輸出控制組成的數(shù)據(jù)顯示模塊。其具體架構(gòu)如圖1所示。
圖1 MDF架構(gòu)
●實(shí)體管理模塊：是整個(gè)軟件開(kāi)發(fā)的主要部分。開(kāi)發(fā)者編制、發(fā)布實(shí)體規(guī)范，規(guī)范提供實(shí)體描述定義、實(shí)體動(dòng)作定義以及消息內(nèi)容格式與解釋?zhuān)脩?hù)根據(jù)規(guī)范自行開(kāi)發(fā)實(shí)體程序，或者根據(jù)開(kāi)發(fā)者提供的實(shí)體樣板注冊(cè)登錄。實(shí)體管理模塊根據(jù)實(shí)體規(guī)范協(xié)議管理所有的實(shí)體，包括實(shí)體的登錄和退出以及生存期間的運(yùn)行管理。
●消息管理模塊：管理實(shí)體之間用于交互的消息。消息管理模塊發(fā)布一個(gè)消息格式協(xié)議，其中定義了消息格式的內(nèi)容與解釋。消息管理模塊根據(jù)消息格式協(xié)議管理消息的接收、發(fā)行、維護(hù)以及存儲(chǔ)等。
●數(shù)據(jù)顯示模塊：提供系統(tǒng)運(yùn)行數(shù)據(jù)的顯示，包括結(jié)果顯示和過(guò)程顯示，數(shù)據(jù)顯示模塊與實(shí)體進(jìn)行通信，接收實(shí)體提供的數(shù)據(jù)，通過(guò)輸出控制器執(zhí)行數(shù)據(jù)顯示的功能。同時(shí)該模塊還提供公共性數(shù)據(jù)和永久性數(shù)據(jù)的存儲(chǔ)和查詢(xún)，這些功能同樣通過(guò)與實(shí)體消息交互來(lái)驅(qū)動(dòng)和實(shí)現(xiàn)。
本文主要介紹消息管理模塊的設(shè)計(jì)原理和實(shí)現(xiàn)，其他兩個(gè)模塊將另文撰寫(xiě)。
3.2 消息格式協(xié)議
消息管理模塊最重要的是消息格式協(xié)議（message format propotol，MFP）。M FP定義消息為一個(gè)文本信息，分為4種類(lèi)型，分別為：發(fā)送消息、查詢(xún)消息、測(cè)試消息和名單消息，所有消息都用表示消息類(lèi)型的代碼開(kāi)頭，后面跟隨消息本體。其中，A表示發(fā)送消息，即實(shí)體之間傳遞的消息；B表示查詢(xún)消息，即實(shí)體發(fā)出的查詢(xún)某個(gè)消息的請(qǐng)求；C表示測(cè)試消息，即實(shí)體用于測(cè)試通信鏈路狀態(tài)的消息；D表示名單消息，即實(shí)體發(fā)出的名單，這個(gè)名單提供當(dāng)前實(shí)體的變動(dòng)，或者在多播狀態(tài)下提供接收實(shí)體的列表。
MFP定義消息head部分有7個(gè)屬性（見(jiàn)表2）。各部分內(nèi)容如下。
●name：符號(hào)串類(lèi)型，表示消息的名稱(chēng)。字長(zhǎng)限制為128 byte。
●from：URL類(lèi)型+時(shí)間類(lèi)型，消息發(fā)送方的URL地址，后跟發(fā)送時(shí)間，中間用“+”號(hào)隔開(kāi)。
●to：消息接收方地址，使用“X+P”形式表示，其中，X表示發(fā)送形式，分別是U（單播）、M（多播）和B（廣播）。P表示發(fā)送對(duì)象，在單播時(shí)為URL地址，多播時(shí)為接收方的URL地址，最多為16個(gè)地址，或者是分組文件名稱(chēng)，這個(gè)分組文件事先存放在消息管理模塊中。廣播時(shí)，P為空，此時(shí)由消息管理模塊根據(jù)內(nèi)部存放的實(shí)體名單向各實(shí)體發(fā)送消息。X和P之間用“+”隔開(kāi)。
●type：消息發(fā)送類(lèi)型，使用單個(gè)字符表示，其中A表示主動(dòng)發(fā)送，即該消息根據(jù)設(shè)定的時(shí)間自動(dòng)發(fā)送到接收方；P表示消息只在接收方查詢(xún)時(shí)發(fā)送。
●life：消息生存時(shí)間，使用“單個(gè)字符+時(shí)間類(lèi)型”形式表示，單個(gè)字符表示消息銷(xiāo)毀時(shí)間，后面是具體的時(shí)間，中間用“+”隔開(kāi)。其中，單個(gè)字符L表示該消息發(fā)送后即銷(xiāo)毀；L+time表示該消息在time這個(gè)時(shí)間點(diǎn)銷(xiāo)毀；K+time表示消息在保存time時(shí)間后銷(xiāo)毀。
●time：時(shí)間類(lèi)型，表示消息發(fā)送的時(shí)間，這個(gè)參數(shù)只在主動(dòng)發(fā)送時(shí)有效，在查詢(xún)發(fā)送的消息中，該欄目可以為空。
●priority：整數(shù)類(lèi)型，取值為1~3，表示該消息的優(yōu)先等級(jí)，消息的優(yōu)先等級(jí)由系統(tǒng)規(guī)范定義。
表2 消息的基本格式
表2列出了發(fā)送消息name、from、to、type、life、time、priority的全部7種屬性。消息管理模塊會(huì)針對(duì)消息的屬性描述進(jìn)行不同的處理。
發(fā)送消息（以A開(kāi)頭）的消息內(nèi)容由head和body兩段組成。head定義了消息的聲明部分，用以描述消息的屬性；body定義了消息的內(nèi)容部分，用以描述消息的正文。MFP僅對(duì)消息的head部分進(jìn)行了格式要求，其屬性值對(duì)消息的傳輸、保留、銷(xiāo)毀、發(fā)送以及與實(shí)體之間的交互起著重要的作用。MFP對(duì)body未做要求，只是限定了body的長(zhǎng)度。body的內(nèi)容語(yǔ)義解釋由程序開(kāi)發(fā)者定義，所有實(shí)體必須按照這個(gè)定義來(lái)編排消息內(nèi)容。在MFP和消息管理模塊中，不涉及對(duì)于消息內(nèi)容的任何讀寫(xiě)，只是根據(jù)消息head部分的要求進(jìn)行消息管理，而消息body部分的內(nèi)容理解是由實(shí)體完成的。
查詢(xún)消息（以B開(kāi)頭）由消息名稱(chēng)（name）（必有）、查詢(xún)方的URL地址（to）以及查詢(xún)內(nèi)容（body）組成。查詢(xún)內(nèi)容是消息的屬性，該模塊支持屬性匹配查詢(xún)，消息管理模塊在匹配檢查完成后，將符合條件的消息根據(jù)URL地址發(fā)送給查詢(xún)方。查詢(xún)內(nèi)容部分可以是空，表示這部分不用匹配。在本文的版本中，暫不支持模糊查詢(xún)和通配符查詢(xún)，也暫不支持多條件查詢(xún)。
測(cè)試消息（以C開(kāi)頭）是由發(fā)送方的URL地址加上任意的64byte的文本，中間用“+”隔開(kāi)。消息管理模塊在收到該消息后，向發(fā)送方返回該64 byte的文本。測(cè)試消息是為了檢查當(dāng)前通信線(xiàn)路是否可用，當(dāng)實(shí)體發(fā)送測(cè)試消息并正確回收發(fā)送的文本后，就可以執(zhí)行正常的消息傳送了。
名單消息（以D開(kāi)頭）有兩種格式：名單定義與名單刪除。名單定義用于表示實(shí)體定義的多播名單，一般情況下，實(shí)體可以隨時(shí)發(fā)送多播名單，多播名單有多個(gè)，編號(hào)加以區(qū)別，該多播名單聲明實(shí)體名稱(chēng)和多播對(duì)象URL地址。當(dāng)實(shí)體提交一個(gè)多播消息時(shí)，應(yīng)在屬性to中指明多播名單的編號(hào)，以便于消息管理模塊生成發(fā)送消息對(duì)象。名單刪除表示需要?jiǎng)h除的名單，所有名單通過(guò)名單名稱(chēng)進(jìn)行識(shí)別。
3.3 消息管理模塊
消息由實(shí)體產(chǎn)生，并以消息格式協(xié)議規(guī)定的形式由消息管理模塊處理，其中消息名稱(chēng)name是消息的唯一標(biāo)識(shí)。
每一個(gè)實(shí)體在登錄系統(tǒng)時(shí)，會(huì)向消息管理模塊發(fā)送一個(gè)身份登錄信息，從而在消息管理模塊中產(chǎn)生一個(gè)動(dòng)態(tài)的實(shí)體名單，該名單維護(hù)當(dāng)前登錄實(shí)體名稱(chēng)。同時(shí)每一個(gè)實(shí)體需要發(fā)送多播消息時(shí)，會(huì)向消息管理模塊提交多播名單編號(hào)。如果未提交多播名單，協(xié)議允許發(fā)送方在消息屬性to部分臨時(shí)指定不超過(guò)16個(gè)發(fā)送對(duì)象的URL地址。實(shí)體名單和多播名單都由消息管理模塊維護(hù)。
圖2演示了消息從接收到發(fā)送的完整流程。實(shí)體1發(fā)送控制指令與通信線(xiàn)程1建立消息傳輸通道1，發(fā)送消息msg2。消息管理模塊接收到msg2，經(jīng)過(guò)合法性和完整性的驗(yàn)證，將消息存放在消息池中。如果消息屬于主動(dòng)發(fā)送類(lèi)型，則將該消息加入發(fā)送隊(duì)列，根據(jù)指定的優(yōu)先級(jí)發(fā)送消息。如果是被動(dòng)發(fā)送消息，則在接收到查詢(xún)消息后，將該消息加入發(fā)送消息隊(duì)列，根據(jù)該消息的優(yōu)先級(jí)發(fā)送到實(shí)體2。
由圖2可以看出，消息管理模塊主要分為2個(gè)部分：消息池和消息數(shù)據(jù)庫(kù)。
圖2 消息的流向
消息池是3個(gè)消息隊(duì)列，分別對(duì)應(yīng)MFP中的3個(gè)優(yōu)先級(jí)。需要發(fā)送的消息根據(jù)優(yōu)先級(jí)放入相應(yīng)的消息隊(duì)列進(jìn)行排隊(duì)。消息隊(duì)列的管理算法在下面單獨(dú)說(shuō)明。
消息數(shù)據(jù)庫(kù)是一個(gè)數(shù)據(jù)庫(kù)，消息被接收后，經(jīng)過(guò)消息管理模塊的解析，如果不是即時(shí)發(fā)送，則存入相應(yīng)的數(shù)據(jù)庫(kù)。消息數(shù)據(jù)庫(kù)隨時(shí)檢查消息，當(dāng)某條消息達(dá)到發(fā)送條件時(shí)，即將該消息送入消息池排隊(duì)。如果接收到的消息是查詢(xún)消息，則進(jìn)行相應(yīng)的查詢(xún)，并將查詢(xún)的信息返回發(fā)送方。如果某條消息需要銷(xiāo)毀，則消息數(shù)據(jù)庫(kù)進(jìn)行相應(yīng)的操作。
除了這兩部分外，消息管理模塊還負(fù)責(zé)消息池和消息數(shù)據(jù)庫(kù)的維護(hù)，保證其正常運(yùn)行和通信暢通。當(dāng)實(shí)體發(fā)送測(cè)試消息時(shí)，該模塊負(fù)責(zé)響應(yīng)該測(cè)試消息。當(dāng)實(shí)體發(fā)送名單消息時(shí)，該模塊負(fù)責(zé)讀取并存入相應(yīng)的存儲(chǔ)器管理，或從存儲(chǔ)器中刪除名單。
（1） 消息管理
消息與實(shí)體之間的聯(lián)系采取socket通信協(xié)議。socket為消息管理模塊和實(shí)體模塊之間的通信提供了進(jìn)程通信的端點(diǎn)，每個(gè)socket都用一個(gè)半相關(guān)的描述（協(xié)議、本地IP地址、本地端口）。系統(tǒng)會(huì)根據(jù)實(shí)體的URL地址和端口號(hào)為其生成一個(gè)socket號(hào)；消息管理模塊向所有實(shí)體公布唯一的socket號(hào)，任何知道該socket號(hào)的實(shí)體都可以向消息管理器發(fā)出連接請(qǐng)求。
消息管理模塊與實(shí)體之間的連接過(guò)程分為3個(gè)步驟：通信線(xiàn)程的監(jiān)聽(tīng)、實(shí)體端請(qǐng)求和消息管理模塊的連接確認(rèn)。由于消息在網(wǎng)絡(luò)中進(jìn)行傳輸會(huì)有較大的時(shí)延，為了提高系統(tǒng)的實(shí)時(shí)性和吞吐量，每個(gè)實(shí)體與消息管理器之間都有一個(gè)消息傳輸通道。對(duì)于每一個(gè)消息傳輸通道，消息管理器中有一個(gè)用來(lái)收發(fā)消息的通信線(xiàn)程與其對(duì)應(yīng)。
通信線(xiàn)程接收到用戶(hù)實(shí)體發(fā)送的消息后，首先對(duì)消息進(jìn)行完整性、合法性檢驗(yàn)，然后再對(duì)檢驗(yàn)合格的消息進(jìn)行處理。
● 如果是發(fā)送消息，則解析消息head中的各個(gè)屬性，對(duì)于滿(mǎn)足發(fā)送條件的，則根據(jù)屬性中的指示，將消息加上需送達(dá)的實(shí)體URL地址以及其他一些輔助信息，根據(jù)其優(yōu)先級(jí)，加入相應(yīng)的發(fā)送隊(duì)列等待發(fā)送。
● 如果是查詢(xún)消息，根據(jù)查詢(xún)消息中的查詢(xún)內(nèi)容在消息庫(kù)中進(jìn)行查詢(xún)；將查詢(xún)到的消息加上送達(dá)實(shí)體的UR L地址以及其他一些輔助信息，并根據(jù)其優(yōu)先級(jí)，加入相應(yīng)的發(fā)送隊(duì)列等待發(fā)送。
● 如果是測(cè)試消息，則根據(jù)協(xié)議規(guī)定，返回測(cè)試實(shí)體64 byte的文本。
● 如果是名單消息，則將名單加上發(fā)送實(shí)體的URL地址與編號(hào)作為文件名稱(chēng)，存入相應(yīng)的存儲(chǔ)器，以備使用。
同時(shí)，消息管理模塊也支持一些控制指令，以保證系統(tǒng)通信的正常和完好。
（2） 消息池
消息池負(fù)責(zé)管理消息的發(fā)送，主要包括多個(gè)發(fā)送隊(duì)列（本文中是3個(gè)）、發(fā)送隊(duì)列維護(hù)線(xiàn)程、消息的發(fā)送線(xiàn)程。消息管理模塊與實(shí)體連接后，就會(huì)進(jìn)行消息的傳遞，在消息的傳送過(guò)程中，將根據(jù)優(yōu)先隊(duì)列進(jìn)行消息發(fā)送。
消息池經(jīng)常處于并發(fā)工作狀態(tài)，為此在消息池中對(duì)每條消息都標(biāo)記了優(yōu)先級(jí)，同優(yōu)先級(jí)的消息位于同一發(fā)送隊(duì)列，如圖3所示。具體算法如下。采用優(yōu)先隊(duì)列發(fā)送（priority queuesent，PQS）算法。
圖3 發(fā)送隊(duì)列設(shè)計(jì)
①讀取最高優(yōu)先級(jí)（priority=3）的隊(duì)列消息，如果該消息信道空閑，則發(fā)送該消息；如果信道繁忙，則轉(zhuǎn)向同隊(duì)列的下一條消息；如果下一條消息不存在，則將下一優(yōu)先級(jí)的第1個(gè)消息移入該隊(duì)列，并發(fā)送該消息。
②消息發(fā)出后，等待時(shí)間間隔γ，如果收到消息發(fā)送成功信息，則在隊(duì)列中刪去此消息。將次高優(yōu)先級(jí)（priority=2）和最低優(yōu)先級(jí)（priority=1）的隊(duì)列中的最前消息優(yōu)先級(jí)加1，并排到前一優(yōu)先級(jí)的隊(duì)尾；返回第①步。
③如果時(shí)間間隔γ后，未收到消息發(fā)送成功信息，則再次發(fā)送該消息。
④如果再次時(shí)間間隔γ后，仍未收到消息發(fā)送成功信息，將該消息移到同一優(yōu)先級(jí)的隊(duì)尾，返回第①步。
該算法可以設(shè)立通信進(jìn)程而支持消息的并行發(fā)送，在前一個(gè)消息發(fā)出而未收到確認(rèn)信息時(shí)，后一條消息仍可以發(fā)送，而且確認(rèn)信息回復(fù)的次序可以與發(fā)送次序不同，后發(fā)的消息回復(fù)可能先收到。
消息池在消息隊(duì)列的內(nèi)部采用FIFO（first in first out，先進(jìn)先出）算法；在隊(duì)列間，采用動(dòng)態(tài)優(yōu)先權(quán)調(diào)度算法，即將消息加入發(fā)送隊(duì)列時(shí)，按其優(yōu)先級(jí)加入相應(yīng)的發(fā)送隊(duì)列，消息發(fā)送總是在最高優(yōu)先級(jí)隊(duì)列中進(jìn)行，每處理一條消息后，就將其余隊(duì)列中的第1條消息的優(yōu)先級(jí)加1，并按更新后的優(yōu)先級(jí)將消息轉(zhuǎn)至相應(yīng)的發(fā)送隊(duì)列隊(duì)尾。梯度發(fā)送隊(duì)列之間用鏈表實(shí)現(xiàn)。發(fā)送隊(duì)列維護(hù)線(xiàn)程用于動(dòng)態(tài)（按時(shí)間片）更新消息的優(yōu)先級(jí)。消息的發(fā)送線(xiàn)程用于從優(yōu)先級(jí)最高的發(fā)送隊(duì)列中取出消息，并根據(jù)消息head中的to字段調(diào)用相應(yīng)的通信線(xiàn)程發(fā)送消息。由于系統(tǒng)中有多個(gè)消息傳輸通道，等待一個(gè)消息被接收后再發(fā)送另一個(gè)消息會(huì)導(dǎo)致傳輸通道的空閑時(shí)間過(guò)長(zhǎng)，為了提高系統(tǒng)的吞吐量，本文采用了多線(xiàn)程的消息發(fā)送模式，只要待發(fā)消息的信道空閑，就發(fā)送該消息，這樣的方法可以提高信道的利用率。
（1） 消息庫(kù)
消息庫(kù)是一個(gè)關(guān)系數(shù)據(jù)庫(kù)，本文使用的是MySQL。消息庫(kù)存放所有未被刪除的消息以及名單消息中提供的名單，并實(shí)現(xiàn)以下的操作。
● 接收消息后，經(jīng)過(guò)解析，如果需要立即發(fā)送，則按照優(yōu)先級(jí)送到相應(yīng)的發(fā)送隊(duì)列排隊(duì)，并存入信息庫(kù)；若不需要發(fā)送，則送入消息庫(kù)，消息的各屬性作為消息庫(kù)的字段，以便于按屬性查詢(xún)。
● 檢查消息庫(kù)：如果某條消息符合發(fā)送條件，則取出該消息，送入發(fā)送隊(duì)列；如果某條消息需要銷(xiāo)毀，則銷(xiāo)毀該消息。
● 收到查詢(xún)消息后，進(jìn)行按屬性查詢(xún)，并將查詢(xún)結(jié)果返回查詢(xún)實(shí)體。如果被查詢(xún)消息需要發(fā)送，則送入發(fā)送隊(duì)列。
● 收到名單消息后，如果是名單定義，則將名單追加到消息庫(kù)；如果是名單刪除，則從消息庫(kù)中刪除指示名稱(chēng)的名單
4 實(shí)驗(yàn)設(shè)計(jì)
本文提供一個(gè)基于M D F 開(kāi)發(fā)的實(shí)例——天文大數(shù)據(jù)模擬系統(tǒng)。天文科學(xué)是一個(gè)產(chǎn)生大數(shù)據(jù)的學(xué)科，例如在太陽(yáng)與小行星的運(yùn)行系統(tǒng)中，就有數(shù)以萬(wàn)計(jì)的小行星，計(jì)算這些小行星的軌跡是一個(gè)典型的大數(shù)據(jù)應(yīng)用。這些小行星還會(huì)不斷增加和消失，如果把小行星看作用戶(hù)，這是非常有代表性的多用戶(hù)動(dòng)態(tài)運(yùn)行系統(tǒng)。因此通過(guò)MDF開(kāi)發(fā)一個(gè)系統(tǒng)，隨時(shí)模擬小行星的運(yùn)行，該系統(tǒng)支持小行星的隨時(shí)更新。在本文中，筆者做了一個(gè)簡(jiǎn)化的實(shí)驗(yàn)性版本，用以說(shuō)明原理，以太陽(yáng)、地球、火星、金星4個(gè)星體為例，模擬星體的運(yùn)行軌跡。星體之間由于受到引力作用，以太陽(yáng)為中心做橢圓軌跡的運(yùn)動(dòng)。太陽(yáng)系的運(yùn)行是包括太陽(yáng)在內(nèi)的所有星體共同作用的結(jié)果，由于每個(gè)星體都是不停運(yùn)動(dòng)的，對(duì)其他星體引力的大小和方向在時(shí)刻變動(dòng)。消息驅(qū)動(dòng)框架正適宜去描述這類(lèi)問(wèn)題。在該模型中，每個(gè)星體都是一個(gè)實(shí)體，它們都具備相同的功能，而一個(gè)星體對(duì)另一個(gè)星體的引力影響可以認(rèn)為是該星體發(fā)出了一個(gè)消息給另一個(gè)星體，星體根據(jù)消息內(nèi)容做出自己的運(yùn)行。在MDF方式下，每個(gè)星體只要給出自己的物理參數(shù)（質(zhì)量、位置、速度），整個(gè)太陽(yáng)系的運(yùn)行就可以自動(dòng)建立起來(lái)，而且可以隨時(shí)添加新發(fā)現(xiàn)的星體（小行星），也可以隨時(shí)刪去星體。
圖4顯示了金星在太陽(yáng)、地球和火星作用下的引力模型。金星有一個(gè)質(zhì)量和初速度V0使其能在引力作用下圍繞太陽(yáng)轉(zhuǎn)動(dòng)。
圖4 三行星的運(yùn)行模型
在該引力模型中，實(shí)體管理模塊有兩種實(shí)體類(lèi)型：太陽(yáng)和行星。地球、火星、金星為行星類(lèi)型。實(shí)體管理模塊定義太陽(yáng)的位置固定不動(dòng)，行星在引力的牽引下圍繞太陽(yáng)作公轉(zhuǎn)運(yùn)動(dòng)。太陽(yáng)實(shí)體具有質(zhì)量（weight）和位置（position）兩種屬性，以（weight， position）的消息格式發(fā)送并存放在消息管理模塊。每個(gè)行星實(shí)體都有質(zhì)量（weight）、位置（position）、速度（velocity）、時(shí)間（time）4種屬性，并將這4種屬性以（weight ，position， velocity， time）的形式加以封裝，作為消息相互傳遞通信。太陽(yáng)的消息是被動(dòng)查詢(xún)類(lèi)型，而每個(gè)行星實(shí)體的消息都是主動(dòng)廣播類(lèi)型。以火星為例，火星實(shí)體向消息管理器發(fā)送一條查詢(xún)消息，消息管理器解析火星實(shí)體發(fā)送來(lái)的查詢(xún)消息的head部分，將查詢(xún)到太陽(yáng)的消息發(fā)送給火星，火星實(shí)體解析出太陽(yáng)的位置和質(zhì)量，又得到其他行星推送的消息，就可以計(jì)算出自己在當(dāng)前位置受到的來(lái)自太陽(yáng)和其他行星的引力，并計(jì)算下一步的位移。
為了觀察實(shí)驗(yàn)結(jié)果，將太陽(yáng)、地球、金星和火星的運(yùn)動(dòng)軌跡以圖像的形式展現(xiàn)出來(lái)，本次實(shí)例使用的質(zhì)量、位置、速度數(shù)據(jù)均以目前太陽(yáng)系運(yùn)行模型為基準(zhǔn)，參數(shù)設(shè)置在表3中，而圖5則將表3的參數(shù)圖形化，顯示了各個(gè)星體的初始位置。
表3 行星參數(shù)
圖6顯示了太陽(yáng)在靜止不動(dòng)的情況下，地球、金星和火星圍繞太陽(yáng)的運(yùn)行軌跡。
圖5 星體的初始位置
圖6 星體的運(yùn)行軌跡
在該天體模型中，可以隨時(shí)加入或撤銷(xiāo)星體。當(dāng)發(fā)現(xiàn)新的星體時(shí)，只要在實(shí)體管理模塊輸入星體正確的質(zhì)量、速度和初始位置，就可以加入該天體模型中。新星體的加入或撤銷(xiāo)會(huì)影響其他星體的運(yùn)行軌跡，但不會(huì)導(dǎo)致整個(gè)模型的崩潰。
5 結(jié)束語(yǔ)：
在大數(shù)據(jù)應(yīng)用背景下，編程語(yǔ)言顯示出與機(jī)器的相關(guān)性越來(lái)越小，與客觀世界越來(lái)越貼近，程序的開(kāi)發(fā)架構(gòu)也越來(lái)越與計(jì)算機(jī)執(zhí)行的過(guò)程脫離，而趨向于和問(wèn)題結(jié)構(gòu)越來(lái)越靠近，“描述就是編程”已經(jīng)成為當(dāng)前編程架構(gòu)的關(guān)注點(diǎn)。編程語(yǔ)言已經(jīng)逐漸從專(zhuān)業(yè)高端走向普通大眾。本文研究的消息驅(qū)動(dòng)框架的開(kāi)發(fā)模式是一種典型的聲明式編程，其中，消息管理模塊是消息驅(qū)動(dòng)框架的交通樞紐、神經(jīng)中樞，它控制著通信唯一媒介——消息的接收、存儲(chǔ)、發(fā)送以及維護(hù)等相關(guān)工作。這種編程框架模擬了許多自然和社會(huì)系統(tǒng)的行為方式，改變了人們的解決問(wèn)題的方式，也將處理邏輯的重點(diǎn)從內(nèi)部轉(zhuǎn)移到外部，簡(jiǎn)化了問(wèn)題求解的復(fù)雜度。
在消息驅(qū)動(dòng)的開(kāi)發(fā)框架中，消息管理模塊的定義與設(shè)計(jì)是重點(diǎn)，目前也只是完成初步的描述，還有很多細(xì)節(jié)和功能方面需要改進(jìn)，以下幾點(diǎn)是需要完善和考量的。
● 程序的頑健性：在消息管理模塊中有大量的中間件，要保證每個(gè)中間件必須是頑健的。因此建立錯(cuò)誤恢復(fù)機(jī)制、為開(kāi)發(fā)人員提供測(cè)試和調(diào)試的接口以及提供較為明確的錯(cuò)誤報(bào)告對(duì)消息驅(qū)動(dòng)框架的發(fā)展是相當(dāng)必要的。
● 消息管理：本文雖然對(duì)消息管理做了初步的約定和設(shè)計(jì)，但是在實(shí)際系統(tǒng)運(yùn)行中，消息管理的要求是多樣的，如何適應(yīng)不同需求的消息管理模式，仍有待于繼續(xù)探討。
● 消息管理模塊與實(shí)體模塊和顯示模塊的對(duì)接：本文的工作主要是針對(duì)MDF的消息管理模塊，實(shí)體模塊以及數(shù)據(jù)管理和顯示模塊仍需要進(jìn)一步完成和完善。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴(lài)品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：大數(shù)據(jù)應(yīng)用系統(tǒng)的消息驅(qū)動(dòng)架構(gòu)
本文網(wǎng)址：http://www.ezxoed.cn/html/solutions/14019319924.html
相關(guān)文章
