選擇是要使用訊息還是事件
假設您正在規劃分散式音樂分享應用程式的架構。 您希望確保應用程式盡量可靠且可調整，而且想要使用 Azure 技術來建置健全的通訊基礎結構。
您必須先了解應用程式元件所交換的每個個別通訊，以選擇適當的 Azure 技術。 針對每個通訊，您可以選擇不同的 Azure 技術。
首先要了解的是，通訊會傳送訊息或事件。 此知識可幫助您選擇要使用的適當 Azure 服務。
Azure (API) 中的通訊策略
什麼是訊息？
在分散式應用程式的術語中，訊息具有下列特性：
- 訊息包含由某個元件產生、可供另一個元件使用的未經處理資料。
- 訊息包含資料本身，而不僅是該資料的參考。
- 傳送端元件預期目的地元件會以特定方式處理訊息內容。 整個系統的完整性可能取決於執行特定作業的傳送端和接收端。
例如，假設使用者利用行動裝置音樂分享應用程式上傳一首新歌。 行動應用程式必須將該歌曲傳送到在 Azure 中執行的 Web API。 必須傳送歌曲的媒體檔案本身，而不只是指出已新增一首新歌的通知。 行動應用程式預期 Web API 會在資料庫中儲存這首新歌，並提供給其他使用者。 這是訊息的範例。
什麼是事件？
事件比訊息更輕巧，最常用於廣播通訊。 傳送事件的元件稱為發佈者，而接收者稱為訂閱者。
使用事件時，接收端元件會決定其感興趣的通訊，並「訂閱」這些事件。 訂閱由 Azure 事件方格或 Azure 事件中樞之類的媒介管理。 當發行者傳送事件時，媒介會將該事件路由傳送給感興趣的訂閱者。 此模式稱為「發佈/訂閱架構」，這不是處理事件的唯一方式，卻是最常見的方式。
事件具有下列特性：
- 事件是輕量型通知，指出有狀況發生。
- 事件可能傳送給多個接收者，或完全不傳送。
- 事件通常會「散開」，或每個發佈者有大量訂閱者。
- 事件發佈者不會預期接收元件所採取的動作。
- 某些事件是離散單元，與其他事件無關。
- 某些事件則屬於相關的排序序列。
例如，假設音樂檔案上傳已完成，且新歌已新增至資料庫。 為了通知使用者有新的檔案，Web API 必須通知 Web 前端和行動裝置應用程式使用者有新的檔案。 使用者可以選擇是否要收聽新的歌曲，因此初始通知不會包含音樂檔案，而只是通知使用者該歌曲存在。 傳送端並不預期事件接收端會執行任何特定動作來回應此事件。
此案例是離散事件的範例。
如何選擇訊息或事件
單一應用程式可能會將事件用於一些用途，而將訊息用於其他用途。 在選擇之前，您必須先分析您的應用程式架構及其所有使用案例，以識別其元件必須彼此通訊的所有不同用途。
事件較可能用於廣播，且通常很短暫。 這是指如果接收端目前都未訂閱，則可能沒有任何接收端會處理通訊。 當分散式應用程式需要保證通訊會經過處理時，比較可能使用訊息。
對於每個通訊，請考慮下列問題：傳送的元件是否會預期目的地元件以特定方式處理通訊？
如果答案為是，請選擇使用訊息。 如果答案為否，則可以使用事件。
了解元件的通訊需求，可協助您選擇元件的通訊方式。 讓我們從訊息開始。