前言

實驗目的：掌握開發(fā)、測試、發(fā)布、調(diào)用進程間通信的基本方法、工具和流程，理解獨立構件體系結構基本原理、結構和特點。掌握使用當今主流云平臺來構建獨立構件風格軟件的相關開發(fā)技能。

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

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

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

以下題目任意選做一個：

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

提示與思考：

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

AWS 連接。

前端頁面簡潔明了，用戶體驗較好，重點在后臺通信機制。

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

如果你基于 Kafka 構建消息隊列服務，如何確保其高可用性？

相關鏈接：

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

SQS 官方文檔鏈接：

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

發(fā)送程序和一個接收程序，實現(xiàn)發(fā)布-訂閱的選擇廣播式功能，要求訂閱者程序為郵件和 SQS 隊列。

發(fā)布-訂閱模式

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

JMS 選型參考資料：要求：

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

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

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

實驗設計

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

系統(tǒng)需求

環(huán)境需求：

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

功能需求：

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

質(zhì)量需求：

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

架構設計

圖 1 數(shù)據(jù)流架構設計

接口設計

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

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

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

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

實驗過程

軟件實現(xiàn)

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

客戶端：

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

圖2 登陸界面

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

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

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

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

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

AWS 代理

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

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

圖 4 SNS 界面

SQS 接收端

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

圖 5 SQS 隊列接受界面

實驗環(huán)境

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

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

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

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

如下圖所示：

圖7 打印出信息

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

實驗評價

實驗結果

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

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

結果分析

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

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

最新評論