是否为每个IIS应用程序部署单个或多个WCF服务？ 我正处于一个关于IIS托管的内部争论的中间。对于给定的企业应用程序，我们有N个WCF服务

一种选择是将每个WCF服务托管在其自己的IIS应用程序中。这意味着每个服务都有自己的web.config和[可能]自己的应用程序池

另一个选项是在一个IIS应用程序中使用软管连接所有WCF服务。这意味着所有这些服务都有一个web.config和一个应用程序池

单个选项为每个服务提供了不同配置（IIS和web.config）的灵活性。单个应用程序池将支持对重置进程进行更精细的控制

共享选项更简单，而且是可能的，因为每个服务的IIS和应用程序配置（web.config）应该相同

---

我在这两个选项之间寻找建议\最佳实践。

在与您描述的相同类型的企业环境中工作，我们发现最佳实践如下：

将类似的功能分组到“应用程序”中，然后将这些应用程序托管在一个WCF服务下。这为我们提供了例如CustomerService、AccountsService等服务

每个服务都有自己的应用程序。域将其与其他服务进行流程分离和安全分离。也就是说，每个服务都在ActiveDiretory（AD）帐户的上下文中运行，这样做可以确保下游资源（如SQL server数据库）的安全

例如，CustomerService在域\ CustomerService用户下运行。然后，我们可以保护例如与客户函数相关的存储过程，以便它们只能由CustomerServiceUser用户执行。然后，我们可以使用集成安全性连接到SQL server。这允许在Active Directory级别管理企业权限

我们对IIS配置和web.config文件都使用脚本进行部署。这样做的好处是，IIS配置也可以保存在源代码管理中，web.config文件的转换文件也可以保存在源代码管理中。然后，我们有完整的版本历史记录或配置，如果我们决定复制和负载平衡服务，还可以使用它快速推出其他机器

---

这是我们发现的最佳实践，尽管您组织的要求可能不同。

为多个WCF服务共享同一web.config文件的优势在于，您可以定义ServiceBehavior、EndpointBehavior、自定义绑定，您的WCF服务在单个位置使用，而不是在多个文件中复制和粘贴它们。这并不意味着您应该使用一个IIS应用程序来承载几十个WCF服务。也许一个好的解决方案是按功能对服务进行分组，并创建两个定义良好的IIS应用程序。谢谢Thomas。更清楚地说，在这个场景中，我谈论的是单个企业应用程序的5个服务。这是一个权衡停机时间与配置容易程度的决策。这不是一个“最佳实践”类型的问题。这两个方向都有各自的优点，但都不是一个坏的做法。尽管如此，作为一般规则，我将所有与相同业务需求相关的服务分组到相同的应用程序和池中。一起订购服务、一起跟踪服务、一起提供产品服务等。这样，只有相关的服务才能一起部署或解决其他问题。@SeanM我自己一直在内部争论这个问题。我的触发器是我认为最好的选择。似乎每个服务最好有一个应用程序池，因为如果一个服务锁定了一个应用程序池或其他什么，其他服务就不会受到影响。然而，我不确定这句话有多真实。