選擇傳訊平台
許多通訊平台都有助於改善分散式應用程式的可靠性，Microsoft Azure 中就有好幾個。 每個平台都是工具，各有不同用途。 請務必選擇正確的工具，以滿足應用程式的各種需求。 看一下 Azure 服務匯流排中的選項。
提議的 Contoso Bicycles 訂購和追蹤應用程式的分散式架構需要幾個元件，包括網站、資料儲存體和後端服務。 應用程式的元件有許多不同的繫結方式，單一應用程式可以利用多種技術。
您必須決定要在新的 Contoso Bicycles 應用程式中使用哪些技術。 第一步是評估有多個組件彼此通訊的各個地方。 某些元件必須及時執行，才能讓應用程式完成工作。 某些元件可能很重要，但並不急迫。 最後，其他元件 (例如行動應用程式通知) 是更具選擇性的。
在訊息與事件之間做決定
訊息和事件都是資料包：從一個元件傳送至另一個元件的資料套件。 初看差異細小，但這些差異可能造成應用程式的建構大不相同。
訊息
在分散式應用程式的術語中，訊息的明確界定為應用程式的整體完整性可能仰賴接收的訊息。 您可以將傳送訊息視為一個元件將流程交棒給另一個元件。 整個工作流程可能是重要的商務程序，訊息就是將這些元件連在一起的黏合劑。
訊息通常會包含實際資料，而不只是資料的參考 (例如識別碼或 URL)。 相較於傳送參考，資料放在資料包中傳送比較不會損毀。 傳訊結構可保證訊息傳遞，而且因為不需要額外查閱，處理訊息較可靠。 不過，傳送應用程式必須確實知道要包含的資料，以避免傳送太多資料，而需要接收元件執行不必要的工作。 因此，訊息的傳送者和接收者通常會締結嚴格的資料合約。
在 Contoso Bicycles 的新架構中，有人下單時，公司可能使用訊息。 Web 前端或行動應用程式會將訊息傳送給後端處理元件。 在後端會執行步驟，例如安排最靠近客戶的店家路線和以信用卡收費。
事件
事件會觸發通知，指出有狀況發生。 事件比訊息更為「精簡」，最常用於廣播通訊。
事件具有下列特性：
- 事件可能傳送給多個接收者，或完全不傳送。
- 事件通常會「散開」，或每個發佈者有大量訂閱者。
- 事件發行者未設想接收端元件採取的動作。
自行車零件連鎖店可能會使用事件來通知使用者有狀態變更。 狀態變更事件可能傳送到 Azure 事件方格，再到 Azure Functions，然後到 Azure 通知中樞，形成完全無伺服器解決方案。
事件與訊息之間之所以會有此差異，基本上是因為通訊平台通常設計為只能處理其中一種。 服務匯流排專門處理訊息。 如果您想要傳送事件，則應選擇事件方格。
Azure 也有 Azure 事件中樞，但最常用在特定類型的高流量通訊串流 (用於分析)。 例如，如果您的製造倉庫有連線到網路的感應器，您可以使用事件中樞搭配 Azure 串流分析，監看溫度變化的模式，或許能看出不必要的火災或元件磨損。
服務匯流排主題和佇列
Azure 服務匯流排可用兩種不同的方式來交換訊息：佇列和主題。
什麼是佇列？
服務匯流排佇列是訊息的簡易暫存位置。 傳送端元件將訊息新增至佇列。 目的地元件提取佇列前端的訊息。 在一般情況下，每則訊息只會讓一個接收者收到。
佇列會分離來源和目的地元件，以避免目的地元件處於高需求狀態。
在尖峰期間，訊息可能太快傳入，目的地元件來不及處理。 因為來源元件不直接連到目的地，來源不受影響，並且佇列會持續成長。 目的地元件能夠處理訊息時會從佇列中移除訊息。 需求降低時，目的地元件會趕上速度，佇列就會縮小。
佇列無須將資源新增至系統即可因應高度需求。 但如果需要快速處理訊息，則為目的地元件建立更多執行個體可讓它們共同分擔負載。 每個訊息只由一個執行個體處理。 這樣能有效縮放整個應用程式，只有真正需要資源的元件才要增加資源。
什麼是主題？
服務匯流排主題與佇列類似，但主題可以有多個訂用帳戶。 這表示多個目的地元件可以訂閱特定主題，以便將每個訊息傳遞給多個接收者。 訂用帳戶也可以篩選主題中的訊息，只接收相關的訊息。 訂用帳戶提供像佇列一樣的分離通訊，並以相同方式因應高需求。 如果希望每個訊息傳遞給多個目的地元件，請使用主題。
注意
基本定價層不支援主題。
服務匯流排佇列和儲存體佇列
兩個 Azure 服務包含訊息佇列：服務匯流排和 Azure 儲存體。 一般而言，儲存體佇列較容易使用，但精密度和彈性不如服務匯流排佇列。
服務匯流排佇列的主要優點包括：
- 支援較大的訊息，每個訊息為 256 KB (標準層) 或 100 MB (進階層)，而 Azure 儲存體佇列訊息只有 64 KB。
- 支援最多一次和至少一次傳遞。 可選擇幾乎不遺失訊息或幾乎不處理兩次。
- 保證先進先出 (FIFO) 順序。 依新增訊息的順序處理訊息。 雖然 FIFO 是佇列的正常作業，但如果組織設定循序或排程的訊息，或在中斷期間 (例如系統損毀)，就會改變預設 FIFO 模式。 如需詳細資訊，請參閱比較 Azure 儲存體佇列與 Azure 服務匯流排佇列。
- 可以將多個訊息組合成一筆交易。 如果交易中有一個訊息無法傳遞，則交易中的所有訊息都不會傳遞。
- 支援角色型安全性。
- 目的地元件不需要持續輪詢佇列。
儲存體佇列的優點：
- 支援無限制的佇列大小 (服務匯流排佇列有 80 GB 限制)
- 維護所有訊息的記錄
如何選擇通訊技術
您已了解 Azure 提供的不同概念和實作。 接下來，請看您對每個通訊的決策過程。
考量
當您選擇傳送和接收訊息的方法時，請考量下列問題：
通訊是事件嗎？ 如果是的話，請考慮使用事件方格或事件中樞。
要將單一訊息傳遞至多個目的地嗎？ 如果是的話，請使用服務匯流排主題。 否則，請使用服務匯流排佇列。
佇列：服務匯流排與儲存體
如果您決定需要佇列，請進一步縮小選擇範圍。
在下列情況下，請選擇服務匯流排佇列：
- 您需要最多一次傳遞保證。
- 您需要 FIFO 保證 (如果沒有其他設定優先於預設 FIFO 順序)。
- 您需要將訊息分組成交易。
- 您想要接收訊息但不要輪詢佇列。
- 您需要將角色型存取提供給佇列。
- 您需要處理的訊息大於 64 KB，但小於標準層的 256 KB 或進階層的 100 MB。
- 您的佇列大小不會增長到 80 GB 以上。
- 您希望能夠分批發佈及取用訊息。
在下列情況下，請選擇儲存體佇列：
- 您只需要簡單的佇列，無特定的額外需求。
- 您需要通過佇列之所有訊息的稽核線索。
- 您預期佇列的大小超過 80 GB。
- 您想要追蹤佇列內處理訊息的進度。
雖然分散式應用程式的元件可以直接通訊，但您通常可以使用中繼通訊平台 (例如 Azure 事件中樞或 Azure 事件方格) 來提高該通訊的可靠性。
事件中樞和事件方格專用於事件，只向接收者告知事件，而不含該事件相關聯的未經處理資料。 Azure 事件中樞是專為高流量的分析類型事件而設計的。
Azure 服務匯流排和儲存體佇列用於訊息，可供您用來繫結任何應用程式工作流程的核心部分。
如果需求很簡單、如果要將每個訊息只傳送給一個目的地，或如果要盡快撰寫程式碼，則儲存體佇列可能是最佳選擇。 否則，服務匯流排佇列提供更多選項和彈性。
如果您想要將訊息傳送給多個訂閱者，您可以使用服務匯流排主題。