背景及要求： 現(xiàn)今，隨著軟件開發(fā)規(guī)模的逐漸增大，軟件開發(fā)的規(guī)范準(zhǔn)則也隨之發(fā)生了變化，從最開始只注重程序正確性運(yùn)行的算法，到現(xiàn)如今注重在整個開發(fā)中的架構(gòu)模式，軟件復(fù)用性等等質(zhì)量屬性，軟件體系結(jié)構(gòu)的規(guī)范化與結(jié)構(gòu)化對軟件開發(fā)的影響越來越大。其中，數(shù)據(jù)流風(fēng)格就是軟件體系結(jié)構(gòu)風(fēng)格中一種典型的風(fēng)格，其高耦合低內(nèi)聚的特點(diǎn)和構(gòu)件的獨(dú)立性使得軟件的復(fù)用性很高，適用于需要處理源源不斷的數(shù)據(jù)的系統(tǒng)。

[以上說明來自教材以及自己的理解]

現(xiàn)今，越來越多的企業(yè)面臨著各種各樣的數(shù)據(jù)集成和系統(tǒng)整合的系統(tǒng)需求，掌握開發(fā)、測試、發(fā)布、調(diào)用進(jìn)程間通信的基本方法、工具和流程顯得很重要。在這樣的系統(tǒng)需求之下，RPC中間件技術(shù)也應(yīng)運(yùn)而生，但由于采用RPC同步處理技術(shù)，在性能、健壯性、可擴(kuò)展性上都存在諸多缺點(diǎn)。而基于消息的異步處理模型則采用非阻塞的調(diào)用特性，發(fā)送者將消息發(fā)送給消息服務(wù)器，消息服務(wù)器在合適的時(shí)候再將消息轉(zhuǎn)發(fā)給接收者；發(fā)送和接收是異步的，發(fā)送者無需等待。使用消息中間件作為一個中間層的軟件，掌握使用云計(jì)算技術(shù)來構(gòu)建獨(dú)立構(gòu)件風(fēng)格的相關(guān)技能。

以下題目任意選做一個：

基于 AWS SQS（亞馬遜云）或阿里云等簡單隊(duì)列服務(wù)的消息中間件，使用 Java，C#或者其他語言分別編寫一個發(fā)送程序和接收程序（構(gòu)建兩個進(jìn)程或者程序，一個用于發(fā)送消息–發(fā)到云端隊(duì)列，一個用于接收消息–從云端隊(duì)列訂閱下來），實(shí)現(xiàn)“點(diǎn)對點(diǎn)”的進(jìn)程間通信功能。

提示與思考：

AWS 相關(guān)基本操作，在另外一個文檔中，里面有基本的如何獲取 AWS key，以及如何建立

AWS 連接。

前端頁面簡潔明了，用戶體驗(yàn)較好，重點(diǎn)在后臺通信機(jī)制。

這種消息隊(duì)列服務(wù)是基礎(chǔ)性的，AWS 作為商業(yè)云平臺提供了針對 SQS 的高可用性解決方案。

如果你基于 Kafka 構(gòu)建消息隊(duì)列服務(wù)，如何確保其高可用性？

相關(guān)鏈接：

AWS .NET API,你可以在該鏈接找到你想要的類及相關(guān)方法 Java API:

SQS 官方文檔鏈接：

基于 AWS SNS（亞馬遜云），或阿里云消息推送服務(wù)，使用 Java、C#或者其他語言編寫一個

發(fā)送程序和一個接收程序，實(shí)現(xiàn)發(fā)布-訂閱的選擇廣播式功能，要求訂閱者程序?yàn)猷]件和 SQS 隊(duì)列。

發(fā)布-訂閱模式

基于一款開源 JMS 消息中間件（如 Active MQ、Rabbit MQ、kafaka），使用 Java 編寫一個發(fā)送程序和接收程序，實(shí)現(xiàn)點(diǎn)對點(diǎn)和發(fā)布-訂閱的選擇廣播式功能，并進(jìn)行測試。

JMS 選型參考資料：要求：

程序應(yīng)具有 GUI，發(fā)送程序和接收程序可選擇發(fā)送和接收方式；

通過對話框可以輸入發(fā)送消息，接收結(jié)果可顯示于對話框中。

報(bào)告結(jié)果中要有對于“點(diǎn)對點(diǎn)”和“發(fā)布-訂閱”兩種模式的比較分析。

實(shí)驗(yàn)設(shè)計(jì)

(給出你的實(shí)習(xí)內(nèi)容的設(shè)計(jì)方案，可根據(jù)實(shí)際情況調(diào)整條目)

系統(tǒng)需求

環(huán)境需求：

用戶需要在 C:\Users\用戶名.aws 目錄下設(shè)置 credentials 和 config 文件，用以保存自己的 AWS 賬號信息。

功能需求：

實(shí)現(xiàn)發(fā)布-訂閱模型，完成一對多的異步消息發(fā)送，使用數(shù)據(jù)流體系風(fēng)格提高復(fù)用性。

質(zhì)量需求：

在遇到錯誤指令或者系統(tǒng)內(nèi)部發(fā)生錯誤后可以顯示出來，不會因此導(dǎo)致程序崩潰。

架構(gòu)設(shè)計(jì)

圖 1 數(shù)據(jù)流架構(gòu)設(shè)計(jì)

接口設(shè)計(jì)

發(fā)布者和發(fā)送數(shù)據(jù)功能之間的接口，僅用來傳輸數(shù)據(jù)，發(fā)布者無需了解數(shù)據(jù)以怎樣的方式發(fā)送出去，只需要發(fā)送數(shù)據(jù)。

發(fā)送數(shù)據(jù)和 AWS 代理之間的接口，僅用來傳輸數(shù)據(jù)，發(fā)送數(shù)據(jù)的構(gòu)件無需了解 AWS 代理如何處理數(shù)據(jù)，只需要發(fā)送數(shù)據(jù)。

AWS 代理和發(fā)送構(gòu)件之間的接口，僅用來傳輸數(shù)據(jù)，發(fā)送數(shù)據(jù)的構(gòu)件無需了解數(shù)據(jù)如何發(fā)送，只需要將數(shù)據(jù)傳輸過去，剩下的無需管理。

接受數(shù)據(jù)和訂閱者之間的接口，數(shù)據(jù)存儲在這里，等用戶在線的時(shí)候推送到用戶眼前。

實(shí)驗(yàn)過程

軟件實(shí)現(xiàn)

首先我將該數(shù)據(jù)流架構(gòu)分成了三部分，分別是發(fā)布者客戶端，AWS代理，以及訂閱者客戶端。數(shù)據(jù)從發(fā)布者發(fā)送，流向AWS代理，最終流向訂閱者客戶段。每個客戶端再分別有向AWS 代理發(fā)送數(shù)據(jù)和向AWS接受數(shù)據(jù)的功能，由兩個客戶端分別調(diào)用。

客戶端：

① 客戶端涉及自動登錄的步驟，如果沒有更新AWS的key的話會導(dǎo)致登錄失敗，拋出對話框顯示錯誤：

圖2 登陸界面

② 登錄成功后會顯示用戶界面，用戶界面有文本輸入框，發(fā)送按鈕，郵箱接受按鈕，以及 SQS 接受按鈕，布局方式如右圖所示：

其中，每個功能都有自己對應(yīng)的構(gòu)件來執(zhí)行不同的操作。構(gòu)件之間并沒有直接的聯(lián)系，之間調(diào)用的關(guān)系都是通過字符串的傳輸?shù)确绞絹磉M(jìn)行調(diào)用。當(dāng)點(diǎn)擊發(fā)送消息后會開啟

發(fā)送消息線程，消息會

發(fā)送到 AWS 代理服務(wù) 圖 3 用戶界面

器，代理服務(wù)器再發(fā)送給所有訂閱者，其中郵箱訂閱能夠通過 QQ 的提示直接查詢到消息，形成同步發(fā)送接受的通信。

AWS 代理

AWS代理是在AWS控制臺線上完成的，只需要確定主題，連接訂閱者，就可以發(fā)送數(shù)據(jù)了。

只要我通過代碼訪問該AWS上的SNS，傳入字符串后，就可以完成分發(fā)操作了。

圖 4 SNS 界面

SQS 接收端

訂閱者（SQS）客戶端專門負(fù)責(zé)接受數(shù)據(jù)，只需要傳入隊(duì)列的名字就可以查詢隊(duì)列收到的消息，也可以選擇刪除消息，刪除在SQS中所查詢到的消息。界面如下圖所示：

圖 5 SQS 隊(duì)列接受界面

實(shí)驗(yàn)環(huán)境

首先我分別寫出了兩個界面，分別對兩個界面進(jìn)行調(diào)試，如下圖所示：

圖 6 三個界面所對應(yīng)的函數(shù)

每個界面我都分別對界面的布局進(jìn)行了大量的設(shè)置（其實(shí)個人感覺這些有些多余，不需要特別炫酷的界面，能用就完事了…）

分別測試了界面的按鈕功能以及鏈接亞馬遜后的接受和發(fā)送功能，都以打印的方式輸出在面板上，供以觀察是否出現(xiàn) bug，

如下圖所示：

圖7 打印出信息

最后分別調(diào)試完畢后，將模塊通過數(shù)據(jù)的發(fā)送鏈接起來，再進(jìn)行微小的錯誤調(diào)試，就完成了。

實(shí)驗(yàn)評價(jià)

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

本次實(shí)驗(yàn)完成了題目 1 和題目 2 的內(nèi)容，實(shí)現(xiàn)了基于管道數(shù)據(jù)流風(fēng)格的點(diǎn)對點(diǎn)消息發(fā)送和發(fā)布訂閱者一對多的消息發(fā)布，在設(shè)計(jì)構(gòu)件的時(shí)候盡量實(shí)現(xiàn)了構(gòu)件的獨(dú)立性，減少與其他構(gòu)件之間的耦合程度，僅通過數(shù)據(jù)（即消息字符串）的傳輸來串聯(lián)起整個系統(tǒng)。

我所設(shè)計(jì)的系統(tǒng)類圖如下所示：

結(jié)果分析

本次實(shí)習(xí)基本上完成了目標(biāo)，實(shí)現(xiàn)了點(diǎn)對點(diǎn)和發(fā)布訂閱的異步通信，和學(xué)長交流后發(fā)現(xiàn)實(shí)際中這是一個將異步通信做成同步通信的過程，當(dāng)發(fā)布者發(fā)送消息的時(shí)候，如果用戶剛好在線，那就會收到發(fā)布者的消息，如果不在線，也可以等到自己上線后從接收端接受發(fā)布給自己的消息。本次實(shí)習(xí)的訂閱者都需要去主動接受消息，實(shí)際中應(yīng)該會有更完善的機(jī)制來通知訂閱者消息的到達(dá)。這就是本次實(shí)習(xí)略有局限的地方了。

到此這篇關(guān)于Python實(shí)現(xiàn)一個發(fā)送程序和接收程序的文章就介紹到這了,更多相關(guān)Python發(fā)送程序與接收程序內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！