【问题标题】:Web service sub-domain hosting vs. virtual directoriesWeb 服务子域托管与虚拟目录
【发布时间】:2018-07-24 18:45:47
【问题描述】:

我已经搜索了几个小时,但找不到以下问题的确切答案。

与让虚拟目录指向 Web 服务本身相比,在子域上托管 Web 服务是否有优势。

例如:webserivces.domain.com/logindomain.com/webservices/login

IIS 依赖于应用程序池,并假设 Web 服务与单个应用程序池相关联,那么托管隔离网站(例如子域)与将虚拟目录应用到使用这些网站的每个网站之间有什么区别相同的网络服务。

domain.com/
-- WebServices/ <- Where the web services actually reside
---- login
-- WebSite1/
---- Login.aspx
-- WebSite2/    
---- Login.aspx
WebSuite.domain.com
-- WebServices/ <- VIRTUAL DIRECTORY
-- WebSite3/
---- Login.aspx <- Calls "login" web service through virtual directory

【问题讨论】:

    标签: web-services iis virtual-directory


    【解决方案1】:

    我个人总是选择子域,因为它比使用 vdirs 更灵活/可扩展,但任何一种方式都可以正常工作(特别是在小规模时)。我对子域的推理是:

    1. 当您最初推出 2 个 dns 名称时,您可以免费将两者都指向同一个服务器(如果有任何改进的吞吐量,因为浏览器会限制每个主机名的请求)。

    2. 在未来的某个时候,您可能希望将前端和后端拆分为 2 个服务器。使用子域这很简单,启动您的新服务器,然后进行一次 DNS 更改。这两个域可以通过负载平衡器进一步升级,允许多个 web/api 服务器等 - 所有这些都非常无缝。那些使用 vdir 的升级更棘手,需要更多的工作(但仍然完全可行)。

    3. 应用程序池强制执行进程隔离 - 因此(理论上)应用程序池不应相互产生不利影响(性能/安全性)。

    4. 前端和后端具有非常不同的工作负载和最佳配置,如果它们没有特定要求位于同一个应用程序池中,则最佳做法是保持分离。

    5. (主观)在网站级别操作更容易进行脚本/自动化/部署。

    因此,基本上,如果您谈论的是增长潜力有限的低流量网站,那真的没关系。如果您有任何可能需要扩大规模,请省去一些痛苦,从一开始就走子域路线。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-01-09
      • 1970-01-01
      • 2010-09-25
      • 1970-01-01
      • 2012-10-09
      • 2020-08-14
      • 1970-01-01
      相关资源
      最近更新 更多