SQL Server 2005基於消息的應用程序介紹

基於消息的應用程序並不是一個新概念，但一直以來，從頭編寫這樣的應用程序都相當困難。我將在一系列三篇文章中討論一個建立異步消息應用程序的新平台，本文為第一篇，我將在其中說明基於消息的應用程序這一概念，以及一個建立包含在SQL Server 2005中的這些應用程序的新型基礎程序。

基於消息的應用程序介紹

處理消息的應用程序是大體上會成功的應用程序。實際上，大多數大型應用程序都應用了某種類型的消息處理。這種處理可能相當簡單，例如，把一個文件放在網絡共享中，以便另一個應用程序能夠處理這個文件；之後，你就可以檢查網絡共享，看文件是否得到處理。

雖然這不是一個非常復雜的消息應用程序，但其背後的概念是一樣的：提交一條消息，應用程序執行其工作。然後，再檢查看是否收到確認消息已得到處理的信息。這種處理方法擁有許多獨特的優點：

• 延期處理：有時候，要想在給定的時間處理某個任務的所有工作是不切實際的。許多時候，當你的應用程序能夠處理的任務達到一個瓶頸點時，最好把剩下的任務交給另一個應用程序進行處理。
  
  在線購買機票就屬於這種情況。當你到一個網站購買機票時，你輸入諸如出發城市、到達城市、旅行日期和隨行乘客人數之類的信息。在你輸入信用卡信息後，你將收到一封確認電子郵件。在後台，某種類型的消息已被提交給另一個執行請求的服務進行處理。如果不能滿足訂票請求，你收到的電子郵件就會說明這一點。
  這種處理的好處在於它減輕了後台數據庫系統堵塞的壓力。而且，如果要求顧客長時間等待網站的確認，大多數顧客都會感到非常不滿。另外，如果所有處理任務都在一個單功能事務中完成，就可能發生嚴重的死鎖情況，從而負面影響在網站上購買機票的顧客的購買體驗。
  
• 分布式處理：一般來說，最好盡可能迅速地處理一項任務。但是，有時候很難確定有多少待處理的任務、完成這些任務需要耗用多少資源。下面我們看一個這種處理的實例。
  
  超市中有許多結賬通道。通道的數量一般根據超市的資源來配備。有時，例如星期六下午，結賬通道變得十分擁擠，顧客必須排隊等候。只要超市的資源沒有耗盡，超市就能分配更多收銀員給顧客結賬。這樣既可加快結賬速度，又不至於影響超市的總體運作。
  同樣的道理，消息應用程序也以相似的方式運作。如果你的應用程序充滿了待處理的請求，通常應該增加另外一條處理隊列來緩解系統的總體處理壓力。

微軟消息隊列

現在你可能已經體會到基於消息的應用程序帶來的價值，你也許想知道為什麼你沒有經常聽說這種應用程序。主要的原因在於，開發這種應用程序是一個非常困難的任務。如果你計劃編寫自己的基於消息的應用程序，你要用大部分時間來開發處理消息的基礎架構。

好消息是，你不再需要開發自己的消息基礎架構。（MSMQ）提供一個開發這類應用程序的框架。它使得應用程序可以在不同種類的網絡間進行通信，並且需要保證消息傳送（guaranteed message delivery）、路由和可配置安全。MSMQ應用程序一般在以Visual Basic、C#或C++編寫的應用程序中開發，不過也可以用其它程序語言編寫。這些應用程序在處理通常需要幾步完成的任務時表現優異。這時，一個任務的每個步驟需要邏輯到達任務的下一個步驟，如一個業務工作流應用程序。

數據庫——不再只是用於存儲數據

過去20年來，我們對關系數據庫系統的依賴程度顯著增加。最初，存儲數據並對數據進行某種處理，是建立商業關系數據庫系統的主要目的。隨著關系數據庫系統的發展，其功能和復雜性的變化，它的主要用途已由單一數據存儲轉變為更加主流的商業智能目的、更加復雜的ETL處理、數據報告、數據通知；在SQL Server 2005中，它甚至已具備編寫在數據庫引擎中執行的.NET CLR語言代碼的能力。因此，完全可以肯定地說，數據庫引擎已不再僅用於數據存儲。

Service Broker

微軟認為，允許你在數據庫內建立基於消息的應用程序，這樣才有意義。Service Broker是SQL Server 2005中新添加的基礎程序，主要用於在數據庫引擎內建立基於消息的應用程序。這些應用程序在數據庫引擎內使用新的TSQL結構而開發。

Service Broker應用程序以松散連接的應用程序而開發，它具有高度可擴展性，並提供其它消息平台所不具備的功能，如消息組協調和鎖定。這些應用程序充分支持事務，並能夠跨越數據庫實例和服務器。

後續討論

在這個系列的下一篇文章中，我將介紹Service Broker應用程序組件，並探討它們之間如何交互以構成一個Service Broker應用程序模型。

Tim Chapman是肯塔基州路易維爾市一家銀行的SQL Server數據庫管理員，他有超過7年的IT行業經驗。他還通過了微軟SQL Server 2000和SQL Server 2005的認證。