WCF性能是怎樣的

這篇文章主要講解了“WCF性能是怎樣的”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“WCF性能是怎樣的”吧！

隨著時代的發(fā)展，Microsoft推出的WCF被我們越來越多的人使用，我們就WCF性能分析一下，設(shè)計、構(gòu)建、維護和版本控制分布式應(yīng)用時一個復(fù)雜的任務(wù)。安全性、可靠性、事務(wù)性和伸縮性的因素和任務(wù)變得更加復(fù)雜。因為問題的復(fù)雜性，所以WCF被設(shè)計來解決這些問題，WCF是相當復(fù)雜的技術(shù)。為了能看清WCF性能，我把主要的功能分為10個類別：獨立版本控制、異步只進消息、平臺統(tǒng)一、安全性、可靠性、事務(wù)支持、互操作性、性能、擴展性和配置性。

獨立版本控制

應(yīng)用系統(tǒng)版本控制已經(jīng)成為一個頭疼的問題。如我之前提到的，面向組件的設(shè)計不能在分布式應(yīng)用中很好地解決這些問題。任何技術(shù)如果在分布式世界里獲得認可，必須允許分布式應(yīng)用的不同部分能夠獨立的版本控制。遵照WS-*規(guī)范，關(guān)注WS-*關(guān)于消息定義的內(nèi)容，允許被調(diào)用的服務(wù)可以再不同速率開發(fā)。這些特性不像創(chuàng)建WCF應(yīng)用的底層原理那么重要，但是我認為這是使用WCF最重要的副產(chǎn)品。

異步單向消息

我們的許多應(yīng)用是使用請求-響應(yīng)模式調(diào)用功能的。典型的是，我們調(diào)用一個功能，然后等待結(jié)果返回，然后根據(jù)返回結(jié)果執(zhí)行。這種方式在Internet上尤為多見。每次我們請求一個頁面，我們必須等待網(wǎng)頁的響應(yīng)。局限我們的條件，大部分分布式應(yīng)用使用的都是請求-響應(yīng)方式。盡管開始看起來不自然，對于穿越 IO邊界的任務(wù)分布式應(yīng)用，異步只進消息方式是更加高效的方式。我認為這是使用WCF的又一個好處。異步只進消息方式允許使用高效的處理資源，更加方便地使用分布式應(yīng)用的高級的功能、可靠性和相應(yīng)能力。

平臺統(tǒng)一

過去微軟已經(jīng)發(fā)布的很多分布式技術(shù);有些成為WCF誕生的重要的導(dǎo)向技術(shù)。并且許多技術(shù)依然在使用。例如，在WCF發(fā)布以前，微軟支持5種主要的分布式技術(shù)： RPC, WSE, ASMX, Remoting, COM+, 和MSMQ。過去，***的分布式技術(shù)取決于應(yīng)用系統(tǒng)的需求。例如，假如分布式應(yīng)用都是基于.NET Framework，那么會選擇.NET Remoting，因為它是.NET Remoting應(yīng)用程序之間一種高效的通信方式。如果一個應(yīng)用需要擔(dān)保消息傳輸和持久化，那么MSMQ是***的選擇。兩個技術(shù)有不同的API、編程方式、操作要求和配置需求。結(jié)果，應(yīng)用程序代碼緊密地綁定到這些技術(shù)上，這些技術(shù)也綁定到特定的功能上。一些新的技術(shù)允許我們組合特性，比如事務(wù)性和隊列性的COM+。只要需求不改變或者不使用其它的不支持的方式，這種模式是可以工作的。

什么是你的應(yīng)用系統(tǒng)與其他的 .NET Framework應(yīng)用、非 .NET Framework應(yīng)用和支持事務(wù)的處理通信所需要的？在WCF之前，沒有好的選擇，本質(zhì)上講，這些需求使得開發(fā)者要么放棄一個需求要么編寫自己的通信技術(shù)。與舊的技術(shù)相比，WCF能夠集成舊的技術(shù)特性并且統(tǒng)一為一個編程模型，如表1-1所示。

表1-1 WCF特性對比

客觀地說，WCF性能沒有提供給我們無約束連接的特性，但是確實提供給了我們比以更多的連接特性。

感謝各位的閱讀，以上就是“WCF性能是怎樣的”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對WCF性能是怎樣的這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！