此案例說明如何建構解決方案,以處理 Web 檢視內基礎數據的變更,而不需要使用即時服務重新整理頁面。 使用此案例的範例包括即時追蹤產品和商品,以及社交媒體解決方案。
架構
元件
- Azure 服務匯流排 是應用程式和服務之間的高度可靠的雲端傳訊服務,即使有一或多個脫機也一定。
- Azure SignalR Service 可讓您輕鬆地將即時通訊新增至 Web 應用程式。
- Azure Functions 是事件驅動的無伺服器計算平臺,也可以解決複雜的協調流程問題。
替代項目
解決此案例的替代方案,包括 Pusher。 它是適用於建置可調整即時通訊功能之應用程式開發人員的健全 API 類別領導者。
還有 PubNub。 PubNub 可讓您輕鬆地將即時功能新增至應用程式,而不必擔心基礎結構。 建置應用程式,讓您的使用者能夠跨行動裝置、瀏覽器、桌面和伺服器實時參與。
Ably 是另一個替代方案。 它提供無伺服器發佈/訂閱(pub/sub)傳訊,可根據您的需求可靠地進行調整。 傳訊會使用 WebSockets 在邊緣傳遞。 Ably 平臺會在 API 呼叫時,提供高可用性、可彈性調整且全域分散的即時基礎結構。
雖然 Pusher、PubNub 和 Ably 是即時傳訊最廣泛採用的平臺,但在此案例中,您會在 Azure 中執行所有作業。 我們建議 SignalR 作為移至平臺,因為它允許伺服器與客戶端之間的雙向通訊。 它也是開放原始碼工具,具有7.9萬個 GitHub 明星和2.2千個 GitHub 分支。
如需詳細資訊,請參閱 GitHub 上的 SignalR 開放原始碼存放庫 。
案例詳細資料
在此案例中,您將瞭解如何設定即時傳訊服務,以共用食品遞送服務交易的即時位置。 此範例也適用於嘗試為其 Web 或行動應用程式建置即時位置共享平台的人員。
您將使用以無伺服器模式設定的 SignalR 服務,與服務總線所觸發的 Azure Functions 應用程式整合,其全部都是使用 .NET Core。
潛在使用案例
這些其他使用案例有類似的設計模式:
- 與用戶端裝置共享即時位置
- 將通知推送給使用者
- 更新時程表
- 建立聊天室
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱,這是一組指導原則,可用來改善工作負載的品質。 如需詳細資訊,請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。
以下是在開發此案例時要牢記的幾個事項,包括如何在 ServiceBusTrigger 中的 Azure 服務匯流排 連接字串 中設定參數:
- 中樞:中樞可以與視訊串流服務進行比較。 您可以訂閱中樞來傳送和接收訊息。
- 目標:目標就像無線電信道。 其中包括正在接聽目標通道的每個人,並在上面有新訊息時收到通知。
如果您記得 SignalR 平臺的上述兩項功能,就能快速啟動並執行。
可用性、延展性和安全性
您可以遵循接下來兩節中所述的內容,以使用此解決方案達到高可用性。
區域配對
每個 Azure 區域都會與相同地理位置內的另一個區域配對。 一般而言,請從相同的區域配對中選擇區域(例如美國東部 2 和美國中部)。 這麼做的好處包括:
- 如果發生廣泛的中斷,則會優先復原每對中至少一個區域。
- 已規劃的 Azure 系統更新會循序推出至配對的區域,以將可能的停機時間降到最低。
- 在大部分情況下,區域配對位於相同的地理位置,以符合數據落地需求。
- 不過,請確定這兩個區域都支援應用程式所需的所有 Azure 服務。 請參閱 依區域的服務。 如需區域配對的詳細資訊,請參閱 商務持續性和災害復原(BCDR):Azure 配對區域。
Azure Front Door
Azure Front Door 是可調整且安全的進入點,可讓您快速傳遞全球應用程式。 當您使用 優先順序路由時,如果主要區域變成無法使用,它會自動故障轉移。 多區域結構可以提供比部署到單個區域更高的可用性。 如果區域中斷影響主要區域,您可以使用 Front Door 將故障轉移到次要區域。
如果解決方案的個別子系統失敗,此架構也可以協助。 運用 Web 應用程式防火牆與 DDoS 保護,在邊緣阻止網路與應用程式層的攻擊。 使用Microsoft受控規則集強化您的服務,並撰寫您自己的規則以自定義應用程序保護。
Front Door 是系統中可能的失敗點。 如果服務失敗,用戶端就無法在停機期間存取您的應用程式。 檢閱 Front Door 服務等級協定 (SLA), 並判斷單獨使用 Front Door 是否符合高可用性的商務需求。 如果沒有,請考慮新增另一個流量管理解決方案作為後援。 如果 Front Door 服務失敗,請將 DNS 中的標準名稱 (CNAME) 記錄變更為指向其他流量管理服務。 您必須手動執行此步驟,您的應用程式將無法使用,直到 DNS 變更傳播為止。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用,並提升營運效率。 如需詳細資訊,請參閱成本最佳化要素的概觀。
假設您的企業每天有 1,000 份訂單,且必須同時與其共用位置數據。 根據發行日期的定價,您部署此案例的預估 Azure 使用量將接近每月 192 美元。
服務類型 | 預估每月成本 |
---|---|
Azure Functions | USD119.40 |
Azure SignalR Service | USD48.97 |
Azure 服務匯流排 | USD23.71 |
總數 | USD192.08 |
部署此案例
Azure Functions 開發
使用 Azure Functions 和 Azure SignalR Service 建置的無伺服器即時應用程式通常需要兩個 Azure Functions:
negotiate
用戶端呼叫以取得有效 SignalR 服務存取令牌和服務端點 URL 的函式。- 傳送訊息或管理群組成員資格的一或多個函式。
SignalRFunctionApp
SignalRFunctionApp 是一個函式應用程式,可建立 Azure Functions 實例,並使用 SignalR 的服務總線觸發程式。
Negotiate.cs
此函式是由 HTTP 要求所觸發。 用戶端應用程式會使用它從 SignalR 服務取得令牌,用戶端可用來訂閱中樞。 此函式應命名為 negotiate
。 如需詳細資訊,請參閱 使用 Azure SignalR Service 進行 Azure Functions 開發和設定。
Message.cs
此函式是由服務總線觸發程式所觸發。 它有與 SignalR 服務的系結。 它會從佇列提取訊息,並將其傳遞至 SignalR 中樞。
指示
在開始之前:
- 請確定您已在 Azure 上布建服務總線佇列。
- 請確定您已在 Azure 上的無伺服器模式中布建 SignalR 服務。
- 在local.settings.json檔案中輸入您的 連接字串 (服務匯流排 和 SignalR)。
- 在 CORS 中輸入用戶端應用程式 (SignalR client) 的 URL(跨原始來源資源分享)。 如需最新的語法,請參閱 使用 Azure SignalR Service 進行 Azure Functions 開發和設定。
- 在Message.cs檔案中的服務總線觸發程式中,輸入您的服務總線佇列名稱。
現在,讓我們設定用戶端應用程式來測試它。 首先,從 解決方案架構 GitHub 頁面擷取範例來源。
SignalR 用戶端
這是簡單的 .NET Core Web 應用程式,可訂閱 SignalRFunctionApp 所建立的中樞。 它會顯示即時在服務總線佇列上收到的訊息。 雖然您可以使用 SignalRFunctionApp 與行動用戶端搭配使用,但讓我們堅持此存放庫中此案例的 Web 用戶端。
指示
請確定 SignalRFunctionApp 正在執行。
複製交涉函式所產生的 URL。 它看起來會像這樣:
http://localhost:7071/api/
。將 URL 貼到 chat.js 檔案的 內
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();
。執行應用程式。
當 Web 用戶端成功訂閱 SignalR 中樞時,狀態就會連線。
SendToQueue.js
此node.js腳本會將訊息推送至 服務匯流排,以便測試您剛完成的部署。
指示
安裝節點 Azure 服務匯流排 模組 (@azure/service-bus)。
在文稿中輸入您的 連接字串 和佇列名稱。
執行指令碼。
下一步
您可以將此案例納入生產環境。 不過,請確定您的 Azure 服務已設定為調整。 例如,您的 Azure 服務匯流排 應設定為標準或進階方案。
您可以從 Visual Studio 將程式代碼部署至 Azure Functions。 若要瞭解如何從 Visual Studio 將程式代碼發佈至 Azure Functions,請遵循 您製作軟體 指南的方式。
瞭解如何在 Azure Functions 中使用 Azure 服務匯流排 系結。 Azure Functions 支援服務總線佇列和主題的觸發程式和輸出系結。
瞭解如何 使用 Azure Functions 中的 SignalR 服務系結,向聯機至 Azure SignalR Service 的用戶端驗證和傳送實時訊息 。 Azure Functions 支援 SignalR Service 的輸入和輸出系結。