匯出 (0) 列印
全部展開

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

更新日期: 2014年1月

如果您有關於 Windows Azure 服務匯流排 定價結構的問題,請參閱下一節的常見問題集。您也可以造訪 Windows Azure 平台定價常見問題集,以取得一般 Windows Azure 定價資訊。

Service Bus 常見問題集

您如何針對 Service Bus 進行收費?

對這些計費表的收費如下:

  1. 訊息 - 針對 服務匯流排 所收送的訊息,每 10,000 則收費 0.01 美元。根據計費月份期間 服務匯流排 所收送的訊息數量來對訊息收費。為回應空佇列/訂閱的接收要求而傳遞的「null」訊息也會收費。針對大小超過 64KB 的訊息,超過的部分每 64KB 會視為一則訊息加以收費 (無條件進位)。這個計費表適用於轉送以及佇列、主題、訂閱及訊息緩衝區。

  2. 轉送小時 - 這個計費表只適用於使用 服務匯流排 轉送功能時。如果您只有使用 服務匯流排 佇列、主題/訂閱或訊息緩衝區,則不會產生任何轉送小時費用。轉送小時的收費標準是每 100 個轉送小時 0.10 美元,而且會從開啟轉送 (第一個接聽程式在指定的轉送位址上連線) 時開始計費,直到關閉轉送 (最後一個接聽程式從該轉送位址中斷連線) 為止,並會無條件進位至下一個完整的小時。

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

哪些 Service Bus 的使用會受限於資料傳輸?哪些不會?

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

Service Bus「轉送」到底是什麼?

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

「轉送小時」計費表的計算方式為何?

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

如果我有一個以上連線至指定轉送的接聽程式該怎麼辦?

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

「Service Bus 連線」計費表怎麼了?

服務匯流排 不再針對連線進行收費。但是,對於可在任何單一 服務匯流排 實體上同時開啟的連線數目會有配額限制。請參閱下面的Service Bus 是否有任何使用量配額?一節。

針對佇列、主題/訂閱及訊息緩衝區,「訊息」計費表的計算方式為何?

服務匯流排 所收送的每則訊息都會計入為可計費訊息。此作法適用於所有 服務匯流排 實體類型,包括佇列、主題/訂閱、訊息緩衝區及轉送。

訊息的定義為:64KB 或以下大小的資料單位。在代理實體 (佇列、主題/訂閱、訊息緩衝區) 的情況下,任何小於或等於 64KB 大小的訊息都會被視為一則可計費訊息。如果訊息大小大於 64KB,則會根據訊息大小來計算可計費訊息的數目 (以 64KB 的倍數來計算)。例如,傳送至 服務匯流排 的 8 KB 訊息將會視為一則訊息來計費,但傳送至 服務匯流排 的 96 KB 訊息將會視為兩則訊息來計費。在大多數情況下,用以判斷可計費訊息的相同方法也適用於轉送。請參閱針對轉送,「訊息」計費表的計算方式為何?一節,以取得關於轉送例外狀況案例的詳細資料。

多次傳遞相同訊息 (例如,訊息展開傳送至多個接聽程式,或者在放棄、延期或無法傳送信件之後擷取訊息) 將當成獨立的訊息來計算。例如,若是含有三個訂閱的主題,則傳送單一 64 KB 訊息並於隨後收到此訊息將會產生四則可計費訊息 (一則「進」加上三則「出」,前提是所有訊息均會傳遞給所有訂閱)。

通常,管理操作和「控制訊息」(例如,完成和延期) 都不會計入為可計費訊息。但以下兩種情況例外:

  1. 服務匯流排 為回應空佇列、訂閱或訊息緩衝區之要求而傳遞的 Null 訊息也會納入計費。因此,根據 服務匯流排 實體進行輪詢的應用程式實際上將會以每個輪詢一則訊息的方式來收費。

  2. 設定和取得 MessageSession 的狀態也會產生可計費訊息,所使用的計算方式與上述相同,都是以訊息大小為基礎來計算。

針對轉送,「訊息」計費表的計算方式為何?

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

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

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

管理操作和控制訊息是否會計入為可計費訊息?

管理操作 (例如,列舉主題上的訂閱或判斷佇列深度) 和「控制訊息」(例如,完成和延期) 通常都不會計入為可計費訊息。但以下兩種情況例外:

  1. 服務匯流排 為回應空佇列、訂閱或訊息緩衝區之要求而傳遞的「Null」訊息會納入計費。因此,根據 服務匯流排 實體進行輪詢的應用程式實際上將會以每個輪詢一則訊息的方式來收費。

  2. 設定和取得 MessageSession 的狀態也會產生可計費訊息,所使用的計算方式與上述相同,都是以訊息大小為基礎來計算。

Service Bus 是否會針對儲存進行收費?

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

如果我在 24 小時內操作了 100 個佇列,每一個佇列每分鐘會處理一則 128 KB 的訊息,那麼,我將看見多少可計費的使用量?

  • 假設每個佇列中的所有訊息都只會傳遞一次。

  • 1 則 128 KB 的訊息 = 2 則可計費訊息 (128 KB/64 KB)。

  • 每分鐘傳送 2 則可計費訊息 + 每分鐘傳遞 2 則可計費訊息 = 每分鐘每個佇列有 4 則可計費訊息。

  • 每分鐘每個佇列有 4 則可計費訊息 * 每天 1,440 分鐘 = 每天每個佇列有 5,760 則可計費訊息。

  • 服務匯流排 每天收送的可計費訊息總數 = 每天每個佇列有 5,760 則可計費訊息 * 100 個佇列 = 每天 576,000 則訊息。

  • 576,000 服務匯流排 訊息成本 576,000/10,000 * 0.01 美元 = 58 * 0.01 美元 = 每天 0.58 美元

如果我在 24 小時內操作了一個含有四個訂閱的主題,每秒會處理一則 48 KB 的訊息,那麼,我將看見多少可計費的使用量?

  • 假設所有訂閱都會收到所有訊息,而且每個訂閱中的所有訊息都只會傳遞一次。

  • 1 則 48 KB 的訊息 = 1 則可計費訊息。

  • 每秒 1 則可計費訊息 * 每天 86,400 秒 = 每天有 86,400 則可計費訊息傳送至主題。

  • 每天 86,400 則訊息 * 4 個訂閱 = 每天有 345,600 則訊息傳遞至訂閱用戶端。

  • 服務匯流排 每天收送的可計費訊息總數 = 86,400 + 345,600 = 每天 432,000 則訊息。

  • 432,000 服務匯流排 訊息成本 432,000/10,000 * 0.01 美元 = 44 * 0.01 美元 = 每天 0.44 美元。

如果我在 24 小時內操作了 10 個非 NetTCP 轉送,每一個轉送每秒會處理一則 8 KB 的訊息,那麼,我將看見多少可計費的使用量?

  • 假設要求/回覆模式和所有要求都會收到 <= 64 KB 大小的回覆。

  • 1 則 8 KB 的訊息 = 1 則可計費訊息。

  • 每秒 1 則可計費訊息 * 每天 86,400 秒 = 每天透過每個轉送傳送之要求訊息的可計費訊息有 86,400 個。

  • 由於所有要求都會收到回覆,所以每天透過每個轉送傳送之回覆訊息的可計費訊息也有 86,400 則。

  • 每天每個轉送的可計費訊息總數 = 86,400 * 2 = 172,800。

  • 服務匯流排 每天收送的可計費訊息總數 = 172,800 * 10 個轉送 = 1,728,000。

  • 1,728,000 服務匯流排 訊息成本 1,728,000/10,000 * 0.01 美元 = 173 * 0.01 美元 = 1.73 美元。

  • 10 個轉送開啟 24 小時 = 240 個轉送小時。

  • 240 個轉送小時成本 240/100 * 0.10 美元 = 3 * 0.10 美元 = 0.30 美元。

  • 總成本 = 1.73 美元 + 0.30 美元 = 每天 2.03 美元。

如果我在 24 小時內操作了 10 個 NetTCP 轉送,每一個轉送每秒會處理一則 8 KB 的訊息,那麼,我將看見多少可計費的使用量?

  • 假設要求/回覆模式和所有要求都會收到 <= 64 KB 大小的回覆。

  • 每秒 8 KB * 每小時 3,600 秒 = 每小時透過每個轉送傳送的要求訊息有 28,800 KB。

  • 由於所有要求都會收到回覆,所以每小時透過每個轉送傳送的回覆訊息也有 28,800 KB。

  • 每小時每個轉送的訊息資料總數 = 57,600 KB。

  • 57,600 KB = 57,600/64 或每小時每個轉送有 900 則可計費訊息 = 900 * 24 或每天每個轉送有 21,600 則可計費訊息。

  • 服務匯流排 每天收送的可計費訊息總數 = 21,600 則訊息 * 10 個轉送 = 216,000。

  • 216,000 服務匯流排 訊息成本 216,000/10,000 * 0.01 美元 = 22 * 0.01 美元 = 0.22 美元。

  • 10 個轉送開啟 24 小時 = 240 個轉送小時。

  • 240 個轉送小時成本 240/100 * 0.10 美元 = 3 * 0.10 美元 = 0.30 美元。

  • 總成本 = 0.22 美元 + 0.30 美元 = 每天 0.52 美元。

Service Bus 是否有任何使用量配額?

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

  • 50 億則訊息

  • 200 萬個轉送小時

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

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

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

  • 並行連線數目

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

    • 訊息緩衝區 - 服務匯流排 針對訊息緩衝區僅支援 REST 操作。因此,連線配額不適用。

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

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

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

  • 訊息大小配額

    • 佇列/主題/訂閱

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

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

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

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

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

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

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

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

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

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

社群新增項目

新增
顯示:
© 2014 Microsoft