《WCF技術內幕》翻譯13：第1部分_第2章_面向服務:為什麼SO有意義和本章小結

技術小胖子發表於2017-11-14
為什麼SO有意義
　　開發者和架構師經常問我,“為什麼我們需要面向服務？”我的回答很簡單：可伸縮性、維護性、互操作性和靈活性。過去，分散式元件技術像COM緊緊地把所有的元件繫結到一起。最低限度上，這些分散式技術必須分享公共型別系統，並且常常是一個執行時。有了這些依賴，升級和軟體升級變得複雜、費時和費力的。面向服務的應用系統，恰恰相反，不需要相同型別的依賴，因此顯示出更加適合企業精算需求的行為。
版本升級
　　應用系統的需求會隨著時間的變化而變化。這個問題從計算機出現的時候就一隻存在，而且並沒有任何跡象表明這個行為會在將來減慢。開發者、架構師和專案經理已經付出了巨大的努力到軟體開發過程的中去，希望能夠調節和控制應用系統變化的數量和步驟。在整個應用系統的宣告週期裡，開發過程裡的一些設想將會證明是徒勞的。某些情況下，最後整合應用系統的改變將會導致一系列級聯的其它應用系統部分的改變。自治的、邊界清晰的、基於契約的面向服務的應用提供了幾層封裝來緩衝這些系統部分版本升級帶來的影響。在面向服務的應用系統裡，訊息傳送者和接收者之間的唯一協定就是契約。兩者都可以根據自己的期望自由改變自己的實現，只要保持契約不變。這些同樣適用於元件架構，面向服務契約的普遍自然屬性把傳送者和接收者從實現中解耦，因此使得版本升級週期變短。面向服務並沒有去掉了一個好的版本化升級過程的需求。
負載均衡
　　每個應用都有一些瓶頸，優勢這些瓶頸可能阻止一個應用為了增加吞吐量需求而進行的擴充套件。


圖2-4：一個傳統的面向元件的應用
　　在這個場景裡，資料檢索或許成為效能瓶頸。如果真是這個情況，一種擴充套件元件驅動的Web網站的方式如圖2-5所示。


圖2-5：伸縮一個元件應用
　　本質上，我們可以在另外的伺服器上重新建立整個Web應用，使用負載均衡器去重定向請求到不是很忙的Web伺服器上。這個型別的伸縮性在過去證明是很有效的，但是卻效率低下和成本過高，並且產生配置問題，尤其是版本升級的時候。
擴充套件訂單處理系統的一個面向服務的方法在圖2-5裡，例子在圖2-6裡。


圖2-6：使用服務
　　面向服務的應用可以更容易地收縮應用系統需要變化的部分。這減少了總的成本和簡化了配置管理。
平臺隨時改變
　　平臺變化，隨著時間的過去，有時候會很快。這個確實在任何廠商的平臺裡存在，像補丁和服務包，並且平臺的新版本經常釋出。對於分散式元件，會經常有一個平臺元件執行時的依賴。比如，一個系統架構師如何知道一個DCOM元件能夠在Microsoft Windows Server 2000、Windows Professional 2000、 Windows XP或者 Windows Server 2003上行為一致？因為一個DCOM元件依賴於每個系統的元件執行時，許多測試場景看起來無中生有。當你開始思考測試每個可能的配置、服務包和熱補丁的時候，你也許會緊張的直流鼻血。
當應用變為面向服務的時候許多這些問題消失了。這個很大程度上因為使用了平臺獨立的XML語法來表示訊息契約。這個契約把傳送者和接受者解耦。傳送者就是遵守契約產生和傳送訊息，而接受者就是接受和處理訊息。不需要序列化平臺規範到訊息裡，所以終結點可以不受他們關注的平臺版本更新的影響。進一步說，測試更簡單，因為終結點必須測試的只是一個清晰的服務邊界。
基於內容的路由
　　過去，面向服務的訊息在面臨路由場景的時候一直非常困難。為了演示，圍繞我們的訂單處理例子我們可以建立一些商業規則：
  • 訂單可以訂購新商品和維修現有商品。
  • 新商品的訂單會傳送給製造管理系統
  • 維修訂單會傳送到維修管理系統
  • 兩個訂單，在傳送給最終目標系統以前必須傳送到財務系統和排程系統。
　　面向服務的訊息應用系統非常好地適應了這些型別的需求。本質上，路由的資訊可以放置到訊息頭裡，被終結點用來判斷訊息路徑。
端到端的安全 
　　許多分散式系統在傳輸級別通過點對點方式保證通訊安全。傳輸是安全的，但是被傳輸的資料在傳輸結束以後也許就不安全了。日誌檔案和其它稽核機制經常包含傳輸時保護的資訊，結果，他們經常成為許多安全攻擊的目標。可以使用標準的XML安全機制通過面向服務的訊息來提供端到端的安全。即使訊息被持久化到日誌檔案或者被破解攻擊，如果訊息使用標準的XML安全機制加密，訊息裡的資料是可以保證機密的。
互操作性
　　當一個初始傳送者傳送訊息給一個最終接受者時，初始傳送者不需要依賴最終接受者執行的平臺。如你看到的二進位制訊息編碼，沒有恆定不變的情況。一些訊息格式能夠引入平臺依賴，但是這個是選擇的問題。在純正意義上，面向服務的應用系統式平臺獨立的。平臺獨立是XML語法表述訊息契約的普遍本性。真的可能（不是理論上）是傳送一個訊息給一個終結點而不知道它所執行的平臺。這與生意人和管理人員產生了共鳴，因為它不需要用一個單一平臺的一個同質應用的集合來取代現有的應用系統。
本章小結 
　　本章闡述了面向服務的動機，和麵向服務系統的一些基本概念。面向服務需要專注於應用傳送、接受和處理的訊息上。面向服務的系統能夠取代以前傳輸的功能，並且把他們放到一個訊息結構裡（地址，安全資訊，相關資訊等等）。專注於訊息使其能夠獨立於平臺、硬體和執行時環境。我的觀點，面向服務應用的版本彈性是IT組織最大的勝利，因為系統級別的升級是最貴的維護部分之一。下一章，我們會看一些構建高階訊息應用系統的不同的方式，並介紹一些必備概念。



 本文轉自 frankxulei 51CTO部落格，原文連結：http://blog.51cto.com/frankxulei/318613，如需轉載請自行聯絡原作者





相關文章