用于将应用程序拆分为前端/后端的意见/标题（不是用户/管理员，而是ui /逻辑）

Question

我正在构建一个新的Web应用程序并使用该体系结构，并且想要分析UI和业务逻辑并在不同的服务器上运行它们。

这意味着如果有人请求页面，前端本身将从后端服务器请求数据，然后实际上不执行任何计算/逻辑，而只是使用数据填充模板，然后对其进行响应。

• 后端：Java + JAX-WS
• 前端：Kohana 3.1（PHP）
• 数据交换格式：JSON

优点：

• 明确分离逻辑和UI
• 选择最适合任何一方的语言/框架的能力
• 添加逻辑/ UI服务器的可能性取决于出现性能问题时哪个是瓶颈
• 可以在没有任何额外工作的情况下公开API（伪内部请求将转到与第三方应用程序的请求相同的API）
• 能够改变（如果需要）任何一方的框架/语言，而无需编辑其他
• 根据逻辑/ UI应用程序的需要指定不同服务器硬件的能力
• 更好的安全性（如果API私有）（??）

缺点：

• 延迟（??）
• 更多服务器

那你觉得怎么样？这是一个好主意吗？到目前为止我还没有找到太多信息，但我的猜测是很多大网站都是这样做的，对吧？性能如何受到影响（我想在EC2上运行它）？还有哪些优点/缺点？有关语言/框架选择的任何想法吗？

Answer 1

通常采用类似的架构模式，但通常UI部分通常会移动到客户端。所以你有一个后端响应JSON，一个快速的http服务器，具有完整的缓存（也可以使用html5应用程序缓存）和一个丰富的javascript客户端，它从后端请求JSON并构建UI。

有关此模式的更多信息：http://www.metaskills.net/2008/05/24/the-ajax-head-design-pattern/

这种方法的主要缺点是，一开始通常会做更多工作 - 如果您不需要外部API，那么使用更简单的架构将更容易编程。

Answer 2

您也可能希望使用保持服务器无状态的想法，让客户端处理任何状态。 这简化了整个负载平衡和故障转移的内容，使您可以考虑更加面向资源的架构。

如果您已经设置了JSON，您可能想要探索NOT POJOS映射到您的数据并使用MongoDB或CouchDB等文档存储直接访问JSON数据的想法。