我正在尝试设计一个系统，允许多个公共端点汇聚到单个 Web 服务中。Web 服务必须能够确定哪个端点是请求的预期目的地。以下是一个可能符合要求的小示例配置：
在这个系统中，“反向代理”（因为没有更好的术语）在传入请求到达 Web 服务之前为其添加 HTTP 标头。否则，代理对于请求和响应是完全透明的。
我们是一家使用 IIS7/WCF 的 Windows 商店。
目标是 1) 仅维护一个 Web 服务，而不是每个域一个 Web 服务，2) 将域/网站管理与 Web 服务中的业务逻辑分离开来。也就是说，如果我们知道上下文将始终使用 HTTP 标头中的键指定，那么我们就不必担心域更改或 的具体内容Request.Headers["HOST"]。
我的问题是：这是一种合理的方法吗？如果是，是否有应用程序可以完成“反向代理”的工作？（Squid？IIS 本身？）
感谢您的帮助！
答案1
在我看来，你试图做的是让一个应用程序完成两件完全不同的事。在某个时候，代码库和功能会有重叠，但我对你的应用程序不够了解，无法帮助你解决这个问题。我有两个可能的解决方案：
如果您采用 MVC 方向，我会尝试将视图相关代码与控制器和模型分开。这样可以更清晰地分离业务逻辑。一种可能的方法是将视图放入 2 个单独的目录中，然后包含来自共享的第 3 个目录的代码。这样可以为您提供一个共享库，用于处理后端逻辑，同时清晰地分离表示逻辑。
我不会害怕 HTTP Host 标头。它是 HTTP/1.1 所必需的，所有现代浏览器都使用它。哎呀，虚拟主机完全依赖于它，你很难找到一个 IIS 或 Apache 管理员告诉你不要在生产中使用虚拟主机。当然，如果你在应用程序端进行标头检查，最大的缺点是你可能会遇到一些非常丑陋的 if/case 语句。反向代理设置所做的唯一一件事就是查找 Host 并在 Host 之外添加另一个标头。因此，你实际上只是通过反向代理为你的架构添加了更多标头和复杂性。
答案2
首先，反向代理在传递请求时应该保留 HTTP Host 字段。如果没有，则表明您的代理配置错误（而且很奇怪！）。
其次，传递额外的标头并据此识别流量是识别负载平衡器处理的流量的标准且可接受的方式。例如，负载平衡器通常就是这样配置的，以通知 Web 服务器流量是通过 SSL 传入的（因为 SSL 无法在该级别进行代理）。
最后，我认为你可能把问题复杂化了。实际上，域名相对于其背后的内容变化的频率是多少？！网络的真正运作方式并非如此……你的应用程序根据 HTTP Host 标头中的域名提供内容没有任何问题，这是非常常见的做法。
答案3
实现此目的的一种方法是使用一组小型云负载均衡器，每个都针对您的 Web 服务。Rackspace 提供 LBaas，其他公司可能也提供。
http://www.rackspace.com/cloud/cloud_hosting_products/loadbalancers/
全面披露：我确实在 Rackspace 工作，但不是从事销售工作。