.NET企業級應用架構設計系列之開場白
.NET企業級應用架構設計系列之技術選型
這裏要說到的是關於三層架構中的應用服務器。對於電子商務網站來說，成熟的架構基本上都是採用分層式的。分層的結構一方面適合人腦的思維方式，另一方面在解決擴展性方面非常有效。目前市面上的各大解決方案提供商在電子商務和一般WEB應用領域都有相應的分層解決方案，軟件架構設計在這一方面幾乎不存在多少爭議。
出於對可擴展性以及可維護性的考慮，對業務邏輯的解耦得到的便是應用服務器。這樣的情況在軟件系統中非常常見，在任何情況下都能通過額外一層間接來獲得靈活性，但可能會引入潛在的性能問題。在Windows Server 2008問世之前的.NET平臺沒有應用服務器的專門產品，架設應用服務器可以有多種可選的方案。常用的.NET應用服務器方案有：
A) 使用IIS駐留ASP.NET Web Service
B) 使用.NET Remoting提供遠程對象
C) 使用Enterprise Services (COM+)提供跨進程對象調用
這三種方式中，採用TCP/Binary通道的.NET Remoting是三個方案中性能最好的，而採用ASP.NET Web Service則能提供更多的跨平臺特性。在性能對比上，ASP.NET Web Service大約是TCP/Binary .NET Remoting的60%左右（和傳遞的數據有關），這中間的差異來自於網絡傳輸上，ASP.NET Web Service會花費較多時間在大對象的數據串行化（Serialization）上。二進制格式的Remoting實現也提供了對象級（包括單件——singleton特性）的支持，在性能要求占主導地位的方案中較多采用。
面對這個情況，最好的解決方法是在實現的時候提供一個更加靈活的架構來隨時調整策略而讓調整的代價保持在最小。也就是說，把系統的核心邏輯實現爲一個對象羣，然後通過facet方式以最小的努力適配到不同的調用接口上。當然，最初是以SOA的方式發佈WEB服務給客戶端調用，以儘量實現可移植的環境。如果發現這種模式成爲了系統中的性能瓶頸，則改爲TCP/Binary .NET Remoting的方式發佈對象。
總的來說，應用服務器的架構是一個演化模型，可以隨着需求和實際負載的變化實行平滑過渡。當應用服務器的橫向擴展也無法應付更大的負載的時候，實際的性能瓶頸已經轉移到了系統的其它地方，比如磁盤訪問或接入帶寬等。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=2233063
