用 SLA 保證第二代 Web 服務(wù)應用程序SOA 延遲和吞吐量  |
 | 級別: 初級 Judith M. Myerson, 系統設計師兼工程師 2004 年 9 月 01 日 第二代 Web 服務(wù)應用程序需要服務(wù)級別協(xié)議 (service level agreements，SLA) 來(lái)保證企業(yè)所購買(mǎi)服務(wù)的可靠性、實(shí)用性以及質(zhì)量問(wèn)題。由于有些應用程序要與非 Web 服務(wù)進(jìn)行交互，客戶(hù)將要求更加精確衡量的 SLA。Judith M. Myerson 說(shuō)明了如何為那些應用程序制定 SLA。她討論了故障警報、延遲和吞吐量，并舉例說(shuō)明了在測試應用程序的時(shí)候應該問(wèn)哪些問(wèn)題以及如何回答這些問(wèn)題。 正如在“用 SLA 保證 Web 服務(wù)”（請參閱 參考資料）中所描述的那樣，下圖顯示了 SLA 保證的 Web 服務(wù)體系結構。它非常簡(jiǎn)單。 圖 1.SLA 保證的 Web 服務(wù)第一代體系結構  該體系結構和 Web 服務(wù)一起工作得很好，在這個(gè)體系結構中，服務(wù)客戶(hù)（請求方）查找服務(wù)，而服務(wù)提供者發(fā)布另一個(gè)服務(wù)，然后服務(wù)被綁定到提供者。每個(gè)服務(wù)角色和另一個(gè)服務(wù)角色之間只有一個(gè)連接箭頭。 這個(gè)體系結構已經(jīng)不適合如今日益復雜的 Web 服務(wù)應用程序。它已經(jīng)過(guò)時(shí)了，特別是在面向服務(wù)的體系結構中 (Service-Oriented Architecture，SOA)，有以下 4 個(gè)原因：
要改進(jìn)第一代體系結構的不足，您必需將 SOA 中的提供者和客戶(hù)間的流程合并為一個(gè)機制，該機制從代理和通信端觸發(fā)提供者警報和客戶(hù)警報。在這個(gè)過(guò)程中，您創(chuàng )建了第二代體系結構，使用雙箭頭連接一個(gè)服務(wù)角色和另一個(gè)服務(wù)角色。 圖 2.第二代體系結構  我們隨意地將提供者警報和客戶(hù)警報分為三類(lèi)：確認、驗證和故障。每種類(lèi)型的內容對每個(gè)事件來(lái)說(shuō)都不一樣。 例如，當應用程序客戶(hù)成功地發(fā)現一個(gè) Web 服務(wù)應用程序時(shí)，代理發(fā)送警報來(lái)確認或驗證發(fā)現成功。如果客戶(hù)沒(méi)有發(fā)現服務(wù)，則代理發(fā)送另一種類(lèi)型的警報，提示發(fā)現嘗試失敗。 一接收到成功發(fā)現的警報，客戶(hù)就將其與提供者綁定。如果提供者認為服務(wù)需要另外的 Web 服務(wù)來(lái)完成初始 Web 服務(wù)應用程序的任務(wù)，它將與客戶(hù)進(jìn)行通信，討論接下來(lái)要做什么。 應用程序提供者給代理發(fā)送發(fā)布服務(wù)的請求。如果代理成功地發(fā)布了資源庫中的服務(wù)，它將給提供者發(fā)送警報來(lái)確認發(fā)布成功。否則，它將發(fā)送嘗試發(fā)布失敗的警報信息。
Web 服務(wù)應用程序是建立在獨立于平臺的協(xié)議——SOAP、WSDL、UDDI 以及 HTTP 之上的。這些協(xié)議滿(mǎn)足了 SOA 的需求，比 Web 服務(wù)存在的時(shí)間要長(cháng)。SOA 要求服務(wù)是可以被發(fā)現的，并且有可供調用的接口來(lái)實(shí)現業(yè)務(wù)流程。 在 Web 服務(wù)以前，SOA 中不存在 Web 服務(wù)應用程序?，F在，Web 服務(wù)應用程序是 SOA 中的主要部分。它們補充了由非 Web 服務(wù)應用程序或組件組成的企業(yè)應用程序集成 (EAI) 應用程序。Web 服務(wù)應用程序與非 Web 服務(wù)應用程序競爭，爭奪他們響應發(fā)現查詢(xún)、發(fā)布請求以及綁定請求所必需的資源。 SOA 主要是利用 Web 服務(wù)標準來(lái)支持跨企業(yè)的互操作性問(wèn)題，前提是 SOAP、WSDL 和其它的互操作性問(wèn)題已經(jīng)在 SLA 保證的 Web 服務(wù)應用程序投入到生產(chǎn)環(huán)境之前得到解決。這包括將 SLA 作為 UDDI 或其它的公開(kāi)注冊中心里的公用服務(wù)的 SLA Web 服務(wù)。這些 Web 服務(wù)必需要涉及到由于爭奪資源對響應時(shí)間的性能影響而帶來(lái)的權利和補償（技術(shù)上的和金錢(qián)上的）。 與 Web 服務(wù)應用程序的體系結構的邏輯類(lèi)似，SOA 服務(wù)客戶(hù)為服務(wù)查詢(xún)目錄服務(wù)。如果客戶(hù)找到了服務(wù)，目錄服務(wù)通過(guò)代理讓服務(wù)提供者調用該服務(wù)。反過(guò)來(lái)，如果客戶(hù)沒(méi)有找到服務(wù)，它可能會(huì )從目錄服務(wù)收到一個(gè)警報，提示搜索失敗。同樣的，如果提供者不能在目錄中發(fā)布服務(wù)，它也可能會(huì )收到一個(gè)警報，提示嘗試失敗。
由于所有的 SLA 都包含提供者從各種故障事件中恢復所必須經(jīng)歷的階段，因此，通信和警報信息必須包括每個(gè)服務(wù)角色為響應各種故障事件需要花費多少時(shí)間（致命錯誤除外），以及從警告故障中自動(dòng)恢復又需要多少時(shí)間等這些方面的信息。 提供者必須要能控制住故障事件。當服務(wù)保障在某一級別出現問(wèn)題（例如，在正常運行時(shí)間里實(shí)用性低于 99.9%），提供者需要確定將要避免的故障類(lèi)型和權利以及補償，補償是必需的。如果故障事件超出提供者的控制范圍，開(kāi)發(fā)人員以及提供者應該將它作為 SLA 中的例外情況，例如，硬件故障、遠程通信故障、軟件錯誤和缺陷，甚至監視和測量系統故障。 由于解釋一些故障可能比較繁瑣，協(xié)助提供者為每個(gè)消息或易發(fā)生的潛在故障指派代碼是一個(gè)好辦法，無(wú)論是按數字順序排列（最好采用十六進(jìn)制）還是按字母順序排列，或者是兩者都用。當分配權重以估算響應時(shí)間時(shí)，您應該將代碼隨意分成三種不同的類(lèi)別：警告、嚴重警告和致命錯誤。如果業(yè)務(wù)操作經(jīng)常中斷，由于對于重復性問(wèn)題的解決方案不如人意，客戶(hù)可能需要有行使權利的特權，執行 SLA 退出子句。
一個(gè)最好的估算響應時(shí)間的辦法是提問(wèn)并回答。編譯完問(wèn)題后，您可以在延遲、吞吐量和故障轉移的基礎上對其進(jìn)行優(yōu)化。 延遲是數據包從一個(gè)地點(diǎn)到另一個(gè)地點(diǎn)然后返回這一個(gè)來(lái)回所花費的時(shí)間。例如包括：
吞吐量是代理在給定的時(shí)間內能處理的請求的數量。故障轉移測試衡量 Web 服務(wù)應用程序的故障轉移解決方案是如何正常運行的。開(kāi)發(fā)人員必需權衡考慮延遲和吞吐量。另一個(gè)需要考慮的衡量元素是應用程序如何為死鎖、掛起以及超時(shí)提供糾正措施。 下面是當您試圖通過(guò)修改 Web 服務(wù)應用程序或開(kāi)發(fā)新的應用程序來(lái)提高他們的性能時(shí)，可能會(huì )提出的一些問(wèn)題：
要回答這些問(wèn)題，估算響應時(shí)間的標準應該精確一些。否則，各方就 SLA 是在衡量不同網(wǎng)絡(luò )場(chǎng)景中的哪個(gè)服務(wù)或性能，以及用的是 SOA 中的哪個(gè)服務(wù)級別將不能達成一致意見(jiàn)。 有些情況下，客戶(hù)可能認為一個(gè)雙方同意的服務(wù)級別將估算三個(gè)網(wǎng)絡(luò )，在給定的時(shí)間內，每個(gè)網(wǎng)絡(luò )都分布著(zhù)不同的 Web 服務(wù)應用程序和非 Web 服務(wù)應用程序，如下所示：
另一些情況下，客戶(hù)可能認為一個(gè)雙方同意的服務(wù)級別將用相同的分布來(lái)衡量相同的網(wǎng)絡(luò )，但是要從響應時(shí)間估算中排除所有三個(gè)網(wǎng)絡(luò )中運行的非 Web 服務(wù)應用程序，如下所示：
為完成一連串的任務(wù)，一些 Web 服務(wù)應用程序對非 Web 服務(wù)應用程序的調用增加了問(wèn)題的復雜性，但是，客戶(hù)可能認為這些非 Web 應用程序不在估算范圍之內。如圖 3 所示，并不是所有的 Web 服務(wù)應用程序都要依賴(lài)于非 Web 服務(wù)應用程序。
Web 服務(wù)測試工具——比如那些由 PushtoTest 提供的——（參閱下面的 參考資料部分以獲得相關(guān)鏈接）并不是充當 SLA 監視器的唯一機制。您可以設置異常條件來(lái)監視和檢查 Web 服務(wù)的延遲、吞吐量以及高速緩存機制。這些條件必須作為經(jīng)同意的 SLA 的一部分而被列出。
到目前為止，我已經(jīng)解釋了 SLA 保證的第二代 Web 服務(wù)應用程序的更高級技術(shù)參數。如果您打算為您的付費客戶(hù)提供與非 Web 服務(wù)交互的 Web 服務(wù)應用程序，他們可能想要一個(gè) SLA 來(lái)確保獲得他們期望的投資回報。 我還給出了問(wèn)題實(shí)例，您可以以其中的一些問(wèn)題為基礎來(lái)滿(mǎn)足客戶(hù)對衡量延遲和吞吐量的期望。充分做好準備回答這些問(wèn)題能對提高客戶(hù)對 SOA 中的雙方同意的服務(wù)級別的滿(mǎn)意程度起到一定的幫助作用。 另外，客戶(hù)和提供者必須就協(xié)議條款重新談判（包括權利、補償和例外情況）以確定滿(mǎn)足客戶(hù)的服務(wù)級別，作為對 EAI 應用程序的補充。對于開(kāi)發(fā)人員來(lái)說(shuō)，在集成 Web 服務(wù)應用程序與非 Web 服務(wù)并執行他們的過(guò)程中記住這一點(diǎn)很重要。開(kāi)發(fā)人員必須同時(shí)考慮客戶(hù)對在 SOA 中集成結果的運行情況的業(yè)務(wù)期望和技術(shù)期望。
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
聯(lián)系客服
