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

[以上說(shuō)明來(lái)自教材以及自己的理解]

現(xiàn)今，越來(lái)越多的企業(yè)面臨著各種各樣的數(shù)據(jù)集成和系統(tǒng)整合的系統(tǒng)需求，掌握開(kāi)發(fā)、測(cè)試、發(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ā)送者無(wú)需等待。使用消息中間件作為一個(gè)中間層的軟件，掌握使用云計(jì)算技術(shù)來(lái)構(gòu)建獨(dú)立構(gòu)件風(fēng)格的相關(guān)技能。

以下題目任意選做一個(gè)：

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

提示與思考：

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

AWS 連接。

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

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

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

相關(guān)鏈接：

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

SQS 官方文檔鏈接：

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

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

發(fā)布-訂閱模式

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

JMS 選型參考資料：要求：

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

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

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

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

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

系統(tǒng)需求

環(huán)境需求：

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

功能需求：

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

質(zhì)量需求：

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

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

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

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

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

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

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

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

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

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

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

客戶(hù)端：

① 客戶(hù)端涉及自動(dòng)登錄的步驟，如果沒(méi)有更新AWS的key的話(huà)會(huì)導(dǎo)致登錄失敗，拋出對(duì)話(huà)框顯示錯(cuò)誤：

圖2 登陸界面

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

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

發(fā)送消息線(xiàn)程，消息會(huì)

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

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

AWS 代理

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

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

圖 4 SNS 界面

SQS 接收端

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

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

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

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

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

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

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

如下圖所示：

圖7 打印出信息

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

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

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

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

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

結(jié)果分析

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

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