這裡要說到的是關于三層架構中的應用伺服器。對于電子商務網站來說，成熟的架構基本上都是采用分層式的。分層的結構一方面适合人腦的思維方式，另一方面在解決擴充性方面非常有效。目前市面上的各大解決方案提供商在電子商務和一般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的方式釋出對象。
總的來說，應用伺服器的架構是一個演化模型，可以随着需求和實際負載的變化實行平滑過渡。當應用伺服器的橫向擴充也無法應付更大的負載的時候，實際的性能瓶頸已經轉移到了系統的其它地方，比如磁盤通路或接入帶寬等。
版權
作者：靈動生活 郝憲玮
如果你認為此文章有用，請點選底端的【推薦】讓其他人也了解此文章，
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。