3

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

我们试图决定的是如何准确地使这个中间层可供不同的客户使用。我们将使用 WCF 来执行此操作，并且我们决定使用各种绑定来满足每个不同客户端的需求，包括用于桌面应用程序的 netTcpBinding、net.Tcp 和/或命名管道绑定在本地或网络内的机器上运行的互联网应用程序，以及用于外部 Web API 的某种 HTTP 绑定。

我们试图决定的是如何托管我们的服务。似乎我要去的大多数地方都说 IIS 是要走的路，但如果它在 Windows 服务下，似乎你会从它的 BLL/DAL 部分中获得更好的性能，而这里的@marc_s 似乎经常推荐自托管。那么，我们是在 IIS 下、在服务下还是在某种混合环境下托管它，其中可能在 IIS 中为 HTTP 端点托管瘦服务，并通过 net.tcp 或命名管道绑定使用主服务？如果需要，将其分离出来允许进行物理分离，并允许 IIS 出现故障的可能性，这仍然会为那些访问它发布的端点的客户端运行服务。

此外，可扩展性和可靠性如何？这样两种托管环境之间有很大区别吗？

我意识到有很多与此类似的问题，但我无法找到我一直在寻找的信息，因此指向更具体帮助的链接和答案一样有效。

4

1 回答 1

3

阅读此答案似乎表明自托管是 marc_s 的偏好，基于接受自己编写主机的开销：

IIS WCF 服务托管与 Windows 服务

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

尝试 IIS，如果它真的很差，请创建您自己的主机。在 IIS 中运行它并不十分昂贵——而且网络上有一些调优技巧。

更新：在 marc_s 发表评论后发布。我原则上同意，但自己进行托管可能会被证明是无用的开销。IIS 在某种程度上是开箱即用的，并且有它的局限性——你可能永远不会遇到的局限性。

我不确定此反馈的相关性，但我们使用 IIS 为我们的应用程序托管 .NET Remoting 对象。它目前正在经历相当可观的性能指标收集过程，以准备因新客户而扩大近 10 倍。对我们来说，IIS 并没有被认为是值得担心的事情。人们唯一的症结在于它是通过 HTTP（对我们来说是旧的 IIS 版本），因此与 TCP 相比，它可能更重一些消息。

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

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

于 2011-03-15T21:46:26.950 回答