編輯

共用方式為


使用 Azure 通知中樞推播通知:常見問題集 (FAQ)

一般

通知中樞的資源結構為何?

Azure 通知中樞有兩個資源層級:中樞和命名空間。 中樞是單一推播資源,可包含一個應用程式的跨平台推播資訊。 命名空間是一個區域中多個中樞的集合。 建議對應是一個應用程式搭配一個命名空間。 在命名空間內,您可以有一個生產中樞來與生產應用程式搭配運作,以及一個測試中樞來與測試應用程式搭配運作,依此類推。

「通知中樞」的價格模式為何?

如需最新的價格詳細資訊,請參閱通知中樞價格頁面。 通知中樞會以命名空間層級計費。 (如需命名空間的定義,請參閱<什麼是通知中樞的資源結構?>) 通知中樞提供三個層級︰

  • 免費:對探索推播功能來說,此層級是很好的起點。 但不建議用於生產應用程式。 每個月可取得 500 個裝置和 1 百萬個推播 (每個訂用帳戶),不包含服務等級協定 (SLA) 的保證。
  • 基本:較小型的生產應用程式建議使用此層級 (或標準層級)。 每月可取得 200,000 個裝置和 1 千萬個推播 (以每個訂用帳戶為基準)。
  • 標準:中大型的生產應用程式建議使用此層級。 每月可取得 1 千萬個裝置和 1 千萬個推播 (以每個訂用帳戶為基準)。 包含豐富的遙測 (提供推播狀態相關的額外資料)。

標準層級功能:

  • 豐富的遙測:您可以使用每個訊息遙測的通知中樞,來追蹤任何推播要求和平台通知系統的意見反應以進行偵錯。
  • 多租用戶:您可以在命名空間層級上使用平台通知系統認證。 此選項可讓您在相同的命名空間內輕鬆地將租用戶分割成多個中樞。
  • 排定推播:您可以排定在任何時間傳送通知。
  • 大量作業:可使用註冊匯出/匯入功能,如註冊匯出/匯入文件中所述。

什麼是通知中樞 SLA?

以基本和標準通知中樞層級來說,若應用程式已正確設定,則可傳送推播通知或執行註冊管理作業的時間至少有 99.9 %。 若要深入了解 SLA,請前往通知中樞 SLA 頁面。

注意

因為推播通知依存於第三方平台通知系統,如 Apple 的 Push Notification Service (APNS) 和 Google 的 Firebase Cloud Messaging (FCM),因此這些訊息的傳遞沒有 SLA 保證。 通知中樞將批次傳送至平台通知系統 (SLA 保證) 後,就由平台通知系統負責傳遞推播 (無 SLA 保證)。

如何將中樞或命名空間升級或降級為不同層級?

移至 Azure 入口網站>通知中樞命名空間通知中樞。 選取您要更新的資源,並移至定價層。 注意下列需求:

  • 更新後的定價層會套用至您正在使用的命名空間中所有中樞。
  • 如果您要降級至某一層,而您的裝置數量超過該層的限制,則必須要先刪除裝置才能降級。

設計與開發

支援哪些伺服器端平台?

伺服器 SDK 適用於 .NET、Java、Node.js、PHP 和 Python。 通知中樞 API 是以 REST 介面為根據,因此如果您要使用不同平台或不想要額外的相依性,則可以直接使用 REST API。 如需詳細資訊,請移至通知中樞 REST API頁面。

支援哪些用戶端平台?

推播通知支援 iOSAndroidWindows UniversalWindows PhoneAndroid China (由百度開發)、Xamarin iOSAndroid,以及 Safari。 如需詳細資訊,請參閱通知中樞入門教學課程頁面。

你們是否支援簡訊、電子郵件、或 Web 通知?

通知中樞會將通知傳送至執行行動應用程式的裝置。 不提供電子郵件或簡訊功能。 通知中樞也不提供現成可用的瀏覽器中推播通知傳送服務。 客戶可以在支援的伺服器端平台上,使用 SignalR 來實作此功能。

如果透過通知中樞傳送推播通知,可以支援多少個裝置?

如需支援的裝置數目詳細資訊,請參閱通知中樞價格頁面。

如果您需要支援超過 1000 萬個已註冊的裝置,您必須將裝置分割到多個命名空間。

我可以傳送多少推播通知?

端視選取的層次而定,Azure 通知朱書會自動根據通知數目相應增加透過系統傳送的通知數目。

注意

整體使用成本可能會隨著傳送的推播通知數目而增加。 請務必留意通知中樞價格頁面上概述的層級限制。

我們的客戶每天使用通知中樞來傳送數百萬則推播通知。 只要使用 Azure 通知中樞,您就不需要採取任何特別動作來調整推播通知可及範圍。

送出的推播通知多久才會到達我的裝置?

在一般使用案例中,Azure 通知中樞能在 1 分鐘處理至少 1 百萬個推播通知傳送作業 ,能處理的連入負載數目大致上一樣。 此速率可能視標記數目、連入傳送作業本質和其他外部因子而異。

在預估的傳送時間內,服務能計算每個平台的目標數,並根據已註冊的標記或標記運算式將訊息路由傳送到推播通知服務 (PNS) 。 PNS 負責將通知傳送至裝置。

PNS 不保證任何傳送通知的 SLA。 不過,大部分的推播通知皆會在傳送到通知中樞後的幾分鐘內,傳遞至目標裝置 (通常是 10 分鐘內)。 有些通知可能需要更多時間。

注意

Azure 通知中樞有一個原則,可捨棄無法在 30 分鐘內傳送到 PNS 的任何推播通知。 發生此延遲的原因有數種,但最常見的原因是 PNS 正在為您的應用程式進行節流處理。

是否有任何延遲保證?

因為推播通知的本質 (由外部平台特定 PNS 所傳送),我們無法提供延遲保證。 一般而言,大部分的推播通知會在數分鐘內傳送到目標裝置。

Azure 通知中樞會將資料儲存在哪裡?

Azure 通知中樞會將客戶註冊資料儲存在客戶選取的區域中。 通知中樞會提供中繼資料災害復原範圍 (通知中樞名稱、連接字串和其他重要資訊)。 針對巴西南部和東南亞以外的所有區域,中繼資料備份會裝載在不同的區域中 (通常是 Azure 配對的區域)。 針對巴西南部和東南亞區域,備份會儲存在相同的區域中,以配合這些區域的資料落地需求。

設計具有命名空間與通知中樞的解決方案時,必須考量哪些事項?

行動裝置應用程式/環境

  • 每個環境的每個行動裝置應用程式都使用一個通知中樞。
  • 在多租用戶案例中,每個租用戶都應該有個別的中樞。
  • 絕對不要在生產和測試環境中共用相同的通知中樞。 這種做法可能會在傳送通知時造成問題。 (Apple 提供「沙箱」與「生產推播」端點,而這兩者有個別的認證。)
  • 根據預設,您可以透過 Azure 入口網站或 Visual Studio 中的 Azure 整合式元件,傳送測試通知到已註冊的裝置。 臨界值會設定為從註冊集區中隨機選取的 10 個裝置。

注意

如果您的中樞原本是使用 Apple 沙箱憑證設定,然後重新設定為使用 Apple 生產憑證,則原本的裝置權杖會變得無效。 無效的權杖會造成推播失敗。 請將生產與測試環境分開,並針對不同的環境使用不同的中樞。

PNS 認證

當行動裝置應用程式透過平台的開發人員入口網站 (例如 Apple 或 Google) 進行註冊時,系統會傳送應用程式識別碼和安全性權杖。 應用程式後端會將這些權杖提供給平台的 PNS,藉此推播通知就可以傳送至裝置。 安全性權杖可以是憑證的形式 (例如 Apple iOS 或 Windows Phone),或是安全性金鑰的形式 (例如 Google、Android 或 Windows)。 並且必須在通知中樞加以設定。 設定通常是在通知中樞層級完成,但在多租用戶案例中,這也可以在命名空間層級完成。

命名空間

命名空間可以用於部署分組。 在多租用戶案例中,命名空間可以用來代表相同應用程式中所有租用戶的所有通知中樞。

地區分佈

在推播通知案例中,地理分散不一定是關鍵。 傳送推播通知至裝置的不同 PNS (例如 APN 或 FCM) 並非平均分散。

如果您有一個在全球使用的應用程式,您可以透過在世界上不同的 Azure 區域中使用通知中樞,以在不同命名空間中建立中樞。

注意

但我們不建議此安排,因為這會增加您的管理成本,特別是對註冊而言。 建議只在確實有此需求時這麼做。

應該從應用程式後端註冊或直接透過用戶端裝置註冊?

如果您必須在建立註冊前進行驗證,則從應用程式後端註冊較為實用。 而且當您必須基於應用程式邏輯,讓應用程式後端建立或修改標籤時,這些註冊也十分實用。 如需詳細資訊,請移至後端註冊指引後端註冊指引 2 頁面。

什麼是推播通知傳送資訊安全模型?

Azure 通知中樞使用共用存取簽章 型資訊安全模型。 您可以在根命名空間層級或更細微的通知中樞層級使用共用存取簽章權杖。 共用存取簽章權杖可設定為依循不同授權規則,例如傳送訊息權限或接聽通知權限。 如需詳細資訊,請參閱通知中樞資訊安全模型文件。

應如何處理推播通知中的機密承載?

所有通知皆是由平台的 PNS 傳送至目標裝置。 通知傳送給 Azure 通知中樞,並在進行處理後散佈至各別的 PNS。

傳送者與 Azure 通知中樞之間的連線以及 Azure 通知中樞與 PNS 之間的連線都使用 HTTPS。

注意

Azure 通知中樞不會記錄訊息的承載。

若要傳送機密乘載,我們建議您使用「安全推播」模式。 傳送者會傳送 Ping 通知與訊息識別碼給裝置 (不含機密承載)。 當裝置上的應用程式收到此承載時,就能夠直接呼叫安全 API 以擷取訊息詳細資料。 您可以在通知中樞安全推播教學課程頁面上,取得如何實作此模式的指南。

Operations

我可以得到哪些災害復原支援?

我所有的資料都是以加密形式儲存的嗎?

Azure 通知中樞會加密所有的待用客戶資料,但註冊標籤除外。 因此,您不應使用標籤來儲存個人或機密資料。

是否有稽核記錄功能?

是。 所有「通知中樞」管理作業都會更新在 Azure 入口網站中公開的「Azure 活動記錄」。 「Azure 活動記錄」可讓您深入了解在您訂用帳戶中資源上執行的作業。 藉由使用「活動記錄」,您可以判斷出為訂用帳戶中資源進行的任何寫入作業 (PUT、POST、DELETE) 的內容、對象及時間。 您也可以了解作業的狀態和其他相關屬性。 不過。 「活動記錄」不包含讀取 (GET) 作業。

通知中樞是否偵測到解除安裝?

如果您將裝置儲存為 Registration,則第一次傳送至該註冊時,PNS 會以錯誤狀態代碼回應,指出裝置無效,裝置會從通知中樞刪除。

如果您使用 Installation API 儲存裝置,則上述案例中不會刪除這些裝置。 這項決定是針對使用者重新安裝時,保留與特定使用者相關的標記和其他中繼資料。

針對註冊和安裝,您可以設定到期日,讓裝置在指定時間自動清除。 常見模式是讓您的用戶端應用程式每天更新一次到期日,只要使用者使用您的應用程式,就將其移回。

監視與疑難排解

可用的疑難排解功能有哪些?

Azure 通知中樞提供數個功能以進行疑難排解,特別是在已捨棄通知的最常見案例中。 如需詳細資訊,請參閱通知中樞疑難排解技術白皮書。

可用的遙測功能有哪些?

您可透過 Azure 通知中樞,在 Azure 入口網站中檢視遙測資料。 您可以在通知中樞計量頁面上取得計量的詳細資料。

您也可以透過程式設計方式來存取計量。 如需詳細資訊,請參閱下列文章:

注意

成功通知就是表示推播通知已傳送到外部 PNS (例如 iOS 或 macOS 的 APNS,或 Android 裝置的 FCM)。 PNS 負責將通知傳送至目標裝置。 PNS 通常不會向第三方公開計量。