设计：将“应用程序服务器”与“Web 服务器”分开有意义吗？

Question

我想构建一个“应用程序”，供以下人员使用：

1. 使用浏览器访问网站以使用该网站的用户。
2. 使用 HTTPS/REST API 与其交互的集成商。
3. 在移动设备上使用本机应用程序运行它的用户。

暂时将负载平衡或数据库问题放在一边，我最初的想法是使用这些高级后端组件来构建它：

1. “应用程序服务器”支持第三个 API 集成商的外部 API（顶部列表中的第 2 位）和移动应用程序（顶部列表中的第 3 位）和单页 Web 应用程序使用的内部 API。让我们将此服务器称为“app.myapplication.net”
2. “网站服务器” - 支持我公司的公共网站并为 AngularJS Web 应用程序页面提供服务，这些页面利用“应用程序服务器”中的内部 API 来来回获取数据。我们称之为“www.myapplication.com”

我的动机是将前端与后端工作完全分离。

这是一种流行的架构方式吗？是否有意义？

Answer 1

这确实是最常用的方法。但是，对于较小的项目，您可能可以先将它们放在一起，然后再拆分。 从应用程序资源中分离静态内容有几个优点。在我从事过的项目中，优点是资源、发布管理，其次是浏览器限制。

1. Cookie 很昂贵；如果将静态内容和应用程序内容放在一起，那么每个小请求都将背负着携带 cookie 的负担。 Cookies 还意味着浏览器会考虑到对服务器的所有请求可能对不同的用户有不同的响应，因此可能会破坏资源的缓存。如果您从没有 cookie 的域中提供静态数据，则可以确保缓存正常工作。
2. 资源使用情况。您可能已经在提供来自其他服务的静态内容，angularjs，您提到的，您可能通过另一个域名引用。较旧的浏览器喜欢这种做法，因为它们将对单个 Web 服务器的并发请求数限制为 2。因此，将资源拆分到多个域中是很常见的，即“域分片”。这允许浏览器并行工作。
3. 发布管理。现在这取决于将要处理应用程序的团队，但我们通常希望应用程序和前端 javascript 分开，以便前端程序员和设计人员可以单独发布静态内容而无需触发发布的应用程序。
4. 性能。根据应用程序和服务器的不同，您可能还会发现，如果不必扫描 .htaccess 和类似文件，您可以获得更高的性能。
5. 内容交付网络主要为您提供静态内容的分发，以便您的客户可以在更近的位置以更低的延迟访问大量文件。您当然可以稍后迁移到 CDN，并且可能从第一天开始就不需要，但是如果您已经开始将您的应用程序放在两个不同的域上，那么当/如果您决定这样做时，您可能会发现这个练习更容易。