背景
我最近为客户开发了一个 MVC 应用程序，他们希望将它与其他几个应用程序一起托管在同一台服务器上。
我更像是一名开发人员，而不是服务器管理员，但我的直觉是在 IIS 中建立一个具有自己的子域绑定的新站点。
但是，客户端希望在默认站点中创建一个指向应用程序的虚拟目录。因此，例如，您需要：
COMPANY.COM/APP1和 COMPANY.COM/APP2
而不是：
APP1.COMPANY.COM和APP2.COMPANY.COM
这做过可以工作；但是，它与标准 HTTP 标记中的相对 URL 相冲突，这个问题很快就得到解决。
问题
在同一台服务器上托管多个 Web 应用作为单独的网站还是作为默认网站内的虚拟目录更好？虚拟目录方法是否存在缺陷？
我没有评判虚拟目录方法，它对我来说只是新事物，我想确保它现在或将来不会造成问题。
答案1
我一直尝试坚持使用单独的应用程序站点。这样，您可以更好地控制一切，如果您运行的是 ASP.NET，则不会遇到容易遇到的 web.config 级联问题。此外，您可以更精细地控制应用程序池，并且实际上能够观察每个应用程序的性能。这都是偏好问题。
无论如何，最好的答案可能是在网站级别而不是应用程序级别应用绑定。因此，如果每个应用程序都需要自己的 URL 或 SSL 而不是非 SSL，您确实必须查看各个网站。
另外，正如您提到的，您几乎必须考虑到部署机制来编程。因为任何相对 URL 的使用都会破坏很多东西。
最后：他们为什么不想使用子域名？如果你问我，它提供了很好很干净的 RESTfulish 资源分离。
答案2
我认为这取决于...这些应用程序是否彼此非常相似，您是否可以轻松地在更高级别进行单个更改，然后将其级联到每个虚拟目录，而不会影响任何单个应用程序的功能？如果每个应用程序都有一个单独的站点，那么您将需要单独管理每个站点的设置（证书、IP、端口等），如果有很多站点，这可能会很麻烦，但它们是完全独立的站点，因此设置不会影响其他应用程序。实际工作由工作进程/应用程序池完成，因此在任一设置中，您都可以为多个应用程序共享同一个应用程序池，也可以为每个应用程序设置一个单独的应用程序池。
- 在不同网站上申请= 对应用程序及其连接方式进行更精细的控制，但每个站点的维护成本更高
- 同一网站上的应用程序= 如果它们都非常相似，则更容易管理，但如果应用程序有冲突的要求，您可能会遇到配置问题