匯出 (0) 列印
全部展開

服務匯流排價格常見問題集

更新日期: 2014年10月

如果您有關於 Microsoft Azure 服務匯流排 定價結構的問題,請參閱下一節的常見問題集。您也可以造訪 Azure 支援常見問題集,以取得一般 Microsoft Azure 定價資訊。如需 服務匯流排 定價的完整資訊,請參閱<服務匯流排定價詳細資料>。

note附註
服務匯流排 事件中心的定價會在事件中心預覽版可用性與支援中說明。

如需服務匯流排定價的完整資訊,請參閱<服務匯流排定價和計費>和<服務匯流排定價詳細資料>。除了指明的價格外,還會針對您應用程式佈建所在的資料中心外部,為進行傳出作業而衍生的相關聯資料傳輸進行收費。您可以在下方的哪些 Service Bus 的使用會受限於資料傳輸?哪些不會?一節中找到更多詳細資料。

在指定之 Azure 區域內的所有資料傳輸都將免費提供。所有位於區域外部的資料傳輸都會根據以下費率,針對傳出進行收費:從北美洲和歐洲地區傳輸的費率為每 GB 收費 0.15 美元,若是從亞太地區傳輸,則每 GB 收費 0.20 美元。所有的輸入資料傳輸都是免費提供。

轉送是可在用戶端與 Web 服務之間轉送訊息的 服務匯流排 實體。轉送會提供含永久可探索的 服務匯流排 位址的服務、具備防火牆/NAT 周遊功能的可靠連線,以及像是自動負載平衡的其他功能。每當具備轉送功能的 WCF 服務或「轉送接聽程式」第一次連線至指定的 服務匯流排 位址 (命名空間 URL) 時,便會以隱含的方式在該位址具現化及開啟轉送。應用程式會使用 服務匯流排 .NET Managed API 建立轉送接聽程式,此 API 會提供特定已啟用轉送功能版本的標準 WCF 繫結。

轉送小時的計費方式為,在指定的計費期間內,每個 服務匯流排 轉送所累計起來的「開啟」時間量。當具備轉送功能的 WCF 服務或「轉送接聽程式」第一次連線至指定的 服務匯流排 位址 (服務命名空間 URL) 時,便會以隱含的方式在該位址具現化及開啟轉送。唯有當最後一個接聽程式從其位址中斷連線時,才會關閉轉送。因此,為進行計費,轉送在下列期間會被視為處於「開啟」狀態:從第一個轉送接聽程式連線時算起,到最後一個轉送接聽程式從該轉送的 服務匯流排 位址中斷連線為止。換句話說,每當有一或多個轉送接聽程式連線至其 服務匯流排 位址,即會將轉送視為「開啟」。

在某些情況下,服務匯流排 中的單一轉送可能會有多個連線的接聽程式。使用 netTCPRelay 或 *HttpRelay WCF 繫結的負載平衡服務,或是使用 netEventRelay WCF 繫結的廣播事件接聽程式便可能有這樣的情況。當至少有一個轉送接聽程式連線至轉送時,服務匯流排 中的轉送會被視為「開啟」。但就計費而言,將其他接聽程式新增至開啟的轉送並不會變更該轉送的狀態。因此,連線至轉送的轉送傳送者 (叫用或傳送訊息至轉送的用戶端) 數目也不會對轉送小時的計算有任何影響。

一般會使用與上述針對代理實體 (佇列、主題及訂閱) 相同的方法,來針對轉送計算可計費訊息。但是,請注意以下幾點差異:

  1. 傳送訊息至 服務匯流排 轉送會被視為送往接收訊息之轉送接聽程式的「完全通過」傳送作業,而不是在送往 服務匯流排 轉送的傳送作業之後緊接進行送往轉送接聽程式的傳遞作業。因此,針對轉送接聽程式進行的要求回覆樣式服務叫用 (最多 64 KB) 作業將產生兩則可計費訊息:一則是要求的可計費訊息,另一則是回應的可計費訊息 (假設回應也是 <= 64 KB)。這與使用佇列以在用戶端和服務間居中協調不同。後者的情況是,相同的要求回覆模式需要將要求傳送至佇列,緊接著移除佇列或從佇列傳遞至服務,接著將回應傳送至其他佇列,然後移除佇列或從該佇列傳遞至用戶端。從頭到尾使用相同 (<= 64 KB) 大小假設,居中協調的佇列模式會因此產生四則可計費訊息,是使用轉送實作相同模式的計費數目的兩倍。當然,使用佇列來達成此模式還是有優點,例如,持續性和負載調節。有這些優點的話,多付一些費用應該還算合理。

  2. 使用 NetTCPRelay WCF 繫結開啟的轉送不會將訊息視為個別的訊息,而是將它們視為流經系統的資料串流。換句話說,只有傳送者和接聽程式可以看見使用此繫結傳送/接收之個別訊息的框架。因此,對於使用 netTCPRelay 繫結的轉送,所有資料都會視為串流以計算可計費訊息。在此情況下,服務匯流排 將會計算每 5 分鐘透過每個個別轉送傳送或接收的資料總量,然後除以 64 KB,以判斷在該時間內所考慮之轉送的可計費訊息數目。

不會,服務匯流排 不會針對儲存進行收費。但是,對於可在每個佇列/主題上保留的最大資料量會有配額限制。請參閱下面的Service Bus 是否有任何使用量配額?一節。

根據預設,Microsoft 會針對所有雲端服務設定每月整體使用量配額,這會跨所有的客戶訂閱進行計算。我們了解您可能需要超過這些限制的配額,所以,請隨時連絡客戶服務中心,以便我們了解您的需求,適當調整這些限制。針對 服務匯流排,整體使用量配額如下:

  • 50 億則訊息

  • 200 萬個轉送小時

對於在給定月份內超過使用量配額的客戶,我們保有在以電子郵件通知多次連絡客戶不成後停用其帳戶的權利。超過這些配額的客戶仍需支付超過配額的費用。

和 Azure 上的其他服務一樣,服務匯流排 會強制執行一組特定的配額,以確保資源使用公平無虞。以下為服務強制執行的使用量配額:

  • 配額/主題大小 - 您可在建立佇列或主題時指定最大的佇列或主題大小。此配額的值可以是 1、2、3、4 或 5 GB。如果到達大小上限,其他的傳入訊息將會遭到拒絕,而且呼叫程式碼將會收到例外狀況。

  • 並行連線數目

    • 佇列/主題/訂閱 - 佇列/主題/訂閱上的並行 TCP 連線數目限制為 100。如果到達此配額,後續對於其他連線的要求將會遭到拒絕,而且呼叫程式碼將會收到例外狀況。針對每一個訊息 Factory,如果任一個由該訊息 Factory 建立的用戶端已暫停作用中的操作,或者已在少於 60 秒之前完成操作,則 服務匯流排 會維護一個 TCP 連線。REST 作業不會計入並行 TCP 連線。

  • 轉送上的並行接聽程式數目 - 轉送上的並行 NetTcpRelayNetHttpRelay 接聽程式的數目限制為 25 (若為 NetOneway 轉送,則為 1)。

  • 每個 服務命名空間 的並行轉送接聽程式數目 - 服務匯流排 會強制執行每個 服務命名空間 2000 個並行轉送接聽程式的限制。如果到達此配額,後續對於開啟其他轉送接聽程式的要求將會遭到拒絕,而且呼叫程式碼將會收到例外狀況。

  • 每個 服務命名空間 的主題/佇列數目 - 服務命名空間 上主題/佇列 (支持長期儲存的實體) 的最大數目限制為 10,000。如果到達此配額,後續對於在 服務命名空間 上建立新主題/佇列的要求將會遭到拒絕。在此情況下,根據是透過入口網站或在用戶端程式碼中嘗試建立,管理入口網站將會顯示錯誤訊息,或者,呼叫用戶端程式碼將會收到例外狀況。

  • 訊息大小配額

    • 佇列/主題/訂閱

      • 訊息大小 - 每則訊息的限制為總大小 256KB,包括訊息標頭在內。

      • 訊息標頭大小 - 每則訊息的標頭限制為 64KB。

    • NetOneway 和 NetEvent 轉送 - 每則訊息的限制為總大小 64KB,包括訊息標頭在內。

    • Http 和 NetTcp 轉送 - 服務匯流排 不會強制執行這些訊息的大小上限。

    超過這些大小配額的訊息將會遭到拒絕,而且呼叫程式碼將會收到例外狀況。

  • 每個主題的訂閱數目 - 每個主題的最大訂閱數目限制為 2,000。如果到達此配額,後續對於為主題建立其他訂閱的要求將會遭到拒絕。在此情況下,根據是透過入口網站或在用戶端程式碼中嘗試建立,管理入口網站將會顯示錯誤訊息,或者,呼叫用戶端程式碼將會收到例外狀況。

  • 每個主題的 SQL 篩選數目 - 每個主題的最大 SQL 篩選數目限制為 2,000。如果到達此配額,後續對於在主題上建立其他篩選的要求將會遭到拒絕,而且呼叫程式碼將會收到例外狀況。

  • 每個主題的相互關聯篩選數目 - 每個主題的最大相互關聯篩選數目限制為 100,000。如果到達此配額,後續對於在主題上建立其他篩選的要求將會遭到拒絕,而且呼叫程式碼將會收到例外狀況。

如需配額的詳細資訊,請參閱 Service Bus 配額

Microsoft 正展開一份線上問卷調查,了解您對於 MSDN 網站的看法。 如果您選擇參加,您離開 MSDN 網站時即會顯示線上問卷調查。

您是否想要參加?
顯示:
© 2015 Microsoft