適用於：
SQL Server Azure SQL 受控執行個體
Service Broker 可以協助開發人員建置非同步、鬆散耦合的應用程式，使獨立的元件可一起運作來完成工作。 這些應用程式元件會交換包含完成工作所需資訊的訊息。 此主題描述下列 Service Broker 層面：
交談
訊息排序和協調
交易式非同步程式設計
對鬆散偶合之應用程式的支援
Service Broker 元件
交談
Service Broker 是圍繞傳送及接收訊息的基本功能而設計。 每個訊息都會形成交談的一部分。 每個交談都是一個可靠、永續性的通訊通道。 每個訊息與交談都具有 Service Broker 強制使用的特定類型，以協助開發人員撰寫可靠的應用程式。
新的 Transact-SQL 陳述式讓應用程式能夠可靠地傳送及接收這些訊息。 一個應用程式將訊息傳送至「服務」(一組相關工作的名稱)。 另一個應用程式則從「佇列」(內部資料表的檢視) 接收訊息。
同一工作的訊息是同一交談的一部份。 在每個交談中，Service Broker 保證應用程式只會接收每個訊息一次，並依照傳送訊息的順序接收。 實作服務的程式可以針對交談群組中的相同服務，將相關的交談關聯在一起。
憑證式安全性可以協助您保護機密訊息並控制對服務的存取。 打個比喻，可將 Service Broker 視為郵政服務。 若要與遠方同事進行交談，您可以透過郵遞服務傳送郵件來進行通訊。 郵遞服務會排序並傳遞郵件。 接著，您和您的同事會從信箱擷取郵件、讀取郵件、撰寫回應，然後傳送新的郵件，直到交談結束為止。 當您和您的同事處理其他工作時，郵件傳遞會非同步發生。
程式可將 Service Broker 當做郵政服務使用，以支援與其他程式進行非同步交談。 Service Broker 訊息的功能類似郵件。 Service Broker 服務則是郵局投遞郵件的地址。 佇列則是郵件傳遞後保留郵件的信箱。 應用程式會接收訊息、處理訊息並傳送回應。
當應用程式將訊息傳送到 Service Broker 服務時，它會與交談另一端的應用程式實作詳細資料隔離開來。 接收應用程式可以動態進行重新設定，或取代為新的程式碼，而不影響傳送應用程式。 接收應用程式甚至可以暫時關機；唯一的影響是，Service Broker 會不斷將新訊息加入到佇列，直到重新啟動接收應用程式為止。
訊息排序和協調
Service Broker 會以與傳統產品不同的方式來處理佇列 (一種常見的資料庫程式設計技術)，且不同方式在於兩個主要方面：
Service Broker 佇列已整合到資料庫。
佇列會協調並排序相關訊息。
整合的佇列表示資料庫的定期維護和管理也包括 Service Broker。 通常，管理員沒有與 Service Broker 相關的例行性維護工作。
Service Broker 架構提供簡單的 Transact-SQL 介面，可用來傳送及接收合併了一組對訊息傳遞和處理之強式保證的訊息。 Service Broker 保證程式在交談中，只會依照訊息傳送的順序 (而非訊息進入佇列的順序) 接收每個訊息一次。 傳統的佇列產品會以訊息進入佇列的順序提供訊息。 這需要應用程式判斷訊息的順序與分組。 Service Broker 保證兩個佇列讀取器無法同步處理相同交談的訊息或相關交談之相同群組的訊息。
每個 Service Broker 交談都有兩面。 開始交談的一端稱為起始端；另一端則稱為目標端。 兩端各有一個服務；分別是起始端服務與目標端服務。 每個服務都有一個相關聯的訊息佇列。
以下說明在典型對話交談中交換訊息：
在起始端：
程式開始交談。
程式會建立包含執行工作所需資料的訊息。
程式會將訊息傳送到目標端服務。
在目標端：
訊息會放在與目標端服務相關聯的佇列中。
程式會從佇列接收訊息，然後執行工作。
程式會藉由將訊息傳送到起始端服務來回應。
在起始端：
回應訊息會放在與起始端服務相關聯的佇列中。
程式會接收回應，然後進行處理。
在起始端結束交談前會重複這個循環，因為它沒有其他要求可以傳送到目標端。
Service Broker 支援針對每個交談設定從 10 (高) 到 1 (低) 的優先順序。 這樣可確保低優先順序不會封鎖高優先順序。 Service Broker 系統可以設定為提供不同層級的服務。 如需詳細資訊，請參閱交談優先順序。
Service Broker 會處理與撰寫傳訊應用程式相關的最困難工作。 這些困難的工作包括訊息協調、可靠的訊息傳遞、鎖定，以及啟動佇列讀取器。 這可讓資料庫開發人員專注於如何解決商務問題。
交易式非同步程式設計
在 Service Broker 基礎結構中，應用程式間的訊息傳遞是交易式和非同步的。 因為 Service Broker 傳訊為交易式，所以，如果交易復原，交易內的所有 Service Broker 作業都將復原。 其中包括傳送以及接收作業。 在非同步傳遞中，當應用程式繼續執行時，資料庫引擎會處理傳遞。 為了提升可擴縮性，Service Broker 提供機制，可在需要處理佇列的程式來完成某些有用的工作時，自動將其啟動。 如需詳細資訊，請參閱 Service Broker 啟用 (部分機器翻譯)。
非同步程式設計可以協助開發人員撰寫使用佇列的應用程式。 許多資料庫應用程式都包括資料表，這些資料表可當作資源允許時要完成的工作佇列。 佇列可以提供資料庫應用程式的兩個優點：
將應用程式的工作要求放入佇列後，應用程式就可以立即回應互動使用者。 應用程式不必等到所有與要求相關聯的工作完成後再回應。 提供資源時，就會處理佇列的要求。 這可讓資料庫保持對互動使用者的回應，並有效使用可用的資源。
與單一要求相關的工作有時候可以分割為多個工作單位，當做個別的交易處理。 在這個情況下，資料庫應用程式可以將要求放入佇列中，藉以啟動每個工作單位。 Service Broker 延伸了這個概念，讓應用程式可以在個別電腦的多個 Service Broker 執行個體上分散工作。
針對佇列中的序列和處理序項目正確地撰寫應用程式的程式碼通常很複雜。 開發人員可以使用資料庫引擎內建的 Service Broker 功能，來簡化成功實作資料庫佇列所需的程式碼。
對鬆散偶合之應用程式的支援
Service Broker 支援鬆散耦合應用程式。 鬆散偶合的應用程式由多個獨立傳送和接收訊息的程式組成。 這類的應用程式必須包含相同的已交換之訊息的定義，而且必須針對服務間的互動，定義相同的整體結構。 不過，應用程式不必同時執行，也不必在相同的 SQL Server 執行個體中執行或共用實作詳細資料。 應用程式不需要了解交談中其他參與者的實體位置或實作。
Service Broker 元件
Service Broker 有三種類型的元件：
交談元件。 交談群組、交談和訊息會形成 Service Broker 應用程式的執行階段結構。 應用程式會做為交談的一部份來交換訊息。 每個交談都是一個交談群組的一部分，而一個交談群組可以包含多個交談。 每個 Service Broker 交談都是一個對話。 對話就是兩個參與者實際交換訊息的交談。 如需交談元件的詳細資訊，請參閱交談架構 (部分機器翻譯)。
服務定義元件。 這些是設計階段元件，指定應用程式所使用之交談的基本結構。 它們定義應用程式的訊息類型、應用程式的交談流程，以及應用程式的資料庫儲存體。 如需服務定義元件的詳細資訊，請參閱服務架構。
網路和安全性元件。 這些元件會定義在 Database Engine 執行個體之間交換訊息所使用的基礎結構。 為了協助資料庫管理員管理不斷變更的環境，Service Broker 可讓管理員獨立於應用程式程式碼之外設定這些元件。 如需網路與安全性元件的詳細資訊，請參閱網路和遠端安全性 (部分機器翻譯)。
服務定義元件、網路元件與安全性元件都是資料庫與 SQL Server 執行個體之中繼資料的一部分。 交談群組、交談和訊息是資料庫所包含之資料的一部份。