中间层的WCF托管

Question

我们正在为我们的应用套件开发一个新的中间层。我们希望用C#重写我们的业务逻辑和数据访问层，因为它们目前在VB6中，并通过COM+发布。

我们试图决定的是如何让这个中间层对不同的客户端可用。我们将使用WCF来实现这一点，我们决定使用各种绑定来满足每个不同客户端的需求，包括用于桌面应用程序的netTcpBinding，用于在本地或网络内的机器上运行的互联网应用程序的net.Tcp和/或命名管道绑定，以及用于外部web API的某种风格的HTTP绑定。

我们试图决定的是如何托管我们的服务。似乎大多数地方我都会说IIS是个不错的选择，但如果它是在Windows服务下，你似乎可以从它的BLL/DAL部分获得更好的性能，而@marc_s在这里似乎更推荐使用自托管。那么，我们是将其托管在IIS下，还是托管在服务下，还是在某种混合环境下，其中可能有一个瘦服务托管在IIS中用于HTTP端点，并通过net.tcp或命名管道绑定使用主服务？分离它允许在需要时进行物理隔离，并允许IIS宕机的可能性，这将使服务仍然为访问其发布的终结点的客户端运行。

另外，可伸缩性和可靠性呢？在这种情况下，两个托管环境之间有很大的区别吗？

我意识到有很多类似的问题，但我还没有找到我一直在寻找的信息，所以链接到更具体的帮助和答案一样好。

Answer 1

阅读这个答案似乎表明，基于接受自己编码主机的开销，自托管是marc_s的首选：

IIS WCF service hosting vs Windows Service

IIS为你免费提供了很多东西。我想说，事先考虑这一点并不是一个坏主意，但没有什么比测量性能指标来获得关于什么是最适合您的解决方案的冷酷、确凿的事实更好了。

尝试IIS，如果它真的那么差，那么创建您自己的主机。让它在IIS中运行并不是很昂贵--在web上有一些调优技巧。

更新：在marc_s发表评论后发布了这篇文章。我原则上同意，但自己托管可能会被证明是没有好处的开销。IIS在某种程度上是开箱即用的，并且有它的局限性--您可能永远不会遇到的局限性。

我不确定此反馈的相关性，但我们使用IIS为我们的应用程序托管.NET远程处理对象。它目前正在经历相当大的性能指标收集过程，为新客户端带来的近10倍的扩展做准备。对我们来说，IIS并不是什么值得担心的事情。人们唯一的症结是它是通过HTTP (对我们来说是较早的IIS版本)，所以可能比TCP更重一点的消息。

更新：这篇文章涉及到自托管，并讨论了一些需要考虑的问题：

http://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic3