假设有一个名为 x.com 的餐厅网站，我们也为 x.com 设计了一个网络信息亭。您将如何在 IIS 上构建站点内容，以及最佳实践是什么。 例如 ： 您是否将 webkiosk 作为名为 kiosk 的子文件夹放入 x.com 中并在 x.com/kiosk 访问它，或者您是否创建一个指向 kiosk 子文件夹的名为 kiosk.x.com 的子域？或其他被认为是这种情况下的最佳实践的东西。提前致谢
【问题讨论】：
标签： asp.net iis architecture software-design
您可能需要提供更多信息以获得更具体的答案，但希望这会有所帮助。顺便说一句，我以前在 IIS 上进行开发，所以我的 IIS 知识已经过时了。
简答/TLDR：使用子域，因为从长远来看它更灵活。
主要考虑因素是：系统更改、安全性以及谁拥有系统访问权限。
系统变更
假设网站和自助服务终端在功能上有所不同，例如您很可能想要更改其中一个而不更改另一个（功能更改、错误修复等）。它们的联系越紧密，就越难在不影响另一个的情况下更改一个（想想应用程序池重新启动等）。
您熟悉Single Responsibility Principle (SRP) 吗？ 这是一个面向对象的设计原则，但它非常适用于不仅仅是 OO。
另一个需要考虑的变化是，当您需要拆分信息亭和网站的托管时会发生什么？假设您决定需要在完全不同的硬件上运行信息亭，或者在完全不同的堆栈中重新编写它？如果您使用子域，您可以在任何地方设置新堆栈，并在准备好时简单地重新指向子域。并且网站没有受到影响。
安全
使用子域意味着可以在网络级别以不同方式处理流量，这意味着您可以更有效地使用 Web 应用程序防火墙 (WAF) 之类的东西。您可以针对一个系统（例如信息亭）制定更针对情况需求的 WAF 策略，而不会影响另一个系统。
谁拥有系统访问权限
谁在维护网站和信息亭 - 是同一家公司吗？如果是这样，那么访问同一个服务器似乎很好 - 但如果是不同的公司（甚至只是不同的团队），则具有一定程度的分离通常是明智的。拥有子域使管理变得更容易，因为您有更多的方法来控制它们并保持访问独立。
总结
一般而言，您可以做的事情越分离和隔离越好。因为它往往会给你更多的选择来应对变化。总会有不利的一面——比如短期内更复杂，或者更不方便。好的架构就是为适应可能的长期变化打下基础。
【讨论】：