我正在寻找有关在 10 台机器的应用程序服务器群集上为面向服务客户端 (WinApp) 软件在 IIS 上部署和维护许多 (50) Web 服务和 Web 服务应用程序的建议/最佳实践/+ve/-ve 或其他想法。
目前我们有一个包含许多 Web 服务项目的解决方案。软件是单独开发的，然后在准备发布时进行集成。这涉及集成经理（不熟悉代码），将项目添加到主解决方案并确保一切正常，例如引用等没有损坏。这意味着我们最终在 IIS 中拥有一个为许多 Web 服务提供服务的站点。
最近的一个替代想法是拥有多个站点 - 可能将相关的 Web 服务分组到同一个站点，但将其他 Web 服务保存在不同的站点中，虽然这会增加维护成本（因为站点更多）但这意味着软件的各个部分可以由编写代码的开发人员单独更新和测试。
可能相关：我们对代码使用源代码控制，拥有许多用户（每天大约 100 万次点击），并且可以容忍工作时间内 0 停机时间。
当前，要更新单个 Web 服务，必须将应用程序服务器从集群中取出，进行更新，然后重新添加到集群中。
有没有更有效/更灵活但仍可维护的方法来解决这个问题？
答案1
我可以分享一些我们的想法现在在新的 Stack Overflow 数据中心进行的操作可能会给你一些启发。首先要构建一个临时服务器作为测试。临时服务器是所有生产服务器的副本。添加新站点后，在测试后，我将使用简单的 powershell 脚本同步 applicationhost.config。对于已部署的站点的进一步更新，我们使用 .NET 巡航控制，它允许跨 Web 服务器自动构建。我尝试了 IIS 共享配置，但发现它有点问题。
为了自动将服务器从集群中移除，您可以向负载均衡器添加运行状况检查，以便自动将服务器从集群中移除。
我喜欢你按照开发人员或开发团队对 IIS 站点进行分组的想法。我们也做了类似的事情，这允许开发人员拥有自己的代码。作为管理员，你仍然可以拥有服务器，但不会妨碍开发人员。
我还听到了一场关于持续部署（频繁推送到生产）的有趣演讲，你可以读一下这里。你也许能从中得到一些想法。
最终，您必须设计出最适合您的公司和文化的产品。