实施模块化体系结构的RFC

Question

寻找关于Web应用程序模块化的意见。大多数应用程序不管语言如何，都有一个后端数据库并支持与他们各自的Web应用程序服务器（Apache，IIS，Lighttp等）的绑定，但是我处理的很多开发人员在使用Memcached或任何其他方面遇到问题在Web应用程序的即时进程空间之外。

Web应用程序的模块化是一件好事，因为我相信或者有些东西我错过了，导致从高级开发人员到CTO的每个人都犹豫不决，无法将业务逻辑的特定部分移出网络前端和专门的后端服务？

例如，几年前，我在一个高流量网站的项目设计会议上被击落，当时我建议我们将流程密集型ACL逻辑从前端框架中剥离出来，并将其变为半可聚集服务应用程序在后端。对我来说，好处是代码的清晰分离以及通过使用REST/JSON作为PHP之间的桥梁在多个地方重用ACL逻辑的能力。

那些不同意我的想法的开发者认为它“太复杂”，但我只是不知道如何？我的观点是，正如可以为表示层添加标签汤一样，可以并经常是代码的逻辑汤，它们如此联网，以至于如果出现问题，可能几乎不可能执行“手术”修复。

因此缩短下来，有什么反对的&或亲的断裂大型应用程序分解成独立的，但合作进程（线程没有或子请求）。 MySQL，Memcache，类似的服务过程是伟大的...但为什么不是其他？如何走这条路“太复杂”？

Answer 1

嗯，有时“太复杂”的意思是“我不想在我的舒适区以外思考”。

基本概念听起来不错 - 你在这里谈论的是非常合理的面向服务的体系结构。

现在，就利弊而言，第一件反对的事情是，你确实必须让人们在他们的舒适区之外思考。更技术性的问题是，你需要保留实际上会话状态。假设您从auth服务中获取身份验证令牌;该令牌如何与正确的用户会话保持关联。

另一个问题是，它可能更难调试，因为它更动态地发生。

然而，在专业方面，如果您可以满足会话状态问题，则会得到高度可伸缩的体系结构;如果您需要更多服务，则可以放大服务器或只添加其他服务器。

Answer 2

我是从Web应用程序代码中分离核心服务器/业务逻辑功能的粉丝。这是由于几个不同的原因：

1. 您可以更好地控制业务逻辑。将无法将其与GUI代码混合并造成混乱。您希望将所有业务逻辑分开，以便稍后可以使用API​​调用代码功能，而不希望业务逻辑进入GUI代码。
2. 从一开始你就必须设计一个好的API，你必须使用自己来从客户端与服务器通信。客户端可以是Web界面，也可以是远程用户。
3. 稳定性。 GUI网页代码很容易写错，消耗太多内存，从而导致整个应用程序崩溃。
4. 地磅秤可以将这些独立的组件移动到不同的服务器。如果您使用的缓存系统已经允许集群扩展，只需添加更多缓存服务器即可。
5. 我发现，应用程序更新是由最常见的GUI代码，以便核心服务没有被取下来的大部分时间。
6. 安全。可以肯定的是，安全代码在服务器代码实现的，所以如果有人使用您的API，他们将无法绕过了它的方式进入GUI代码的安全代码。

我们的系统有一个Java应用程序实现的核心“引擎”服务。 Web应用程序也是用Java编写的，并且（当前）通过RMI进行通信。我们的网站/应用程序正在增长，我们还没有开始使用像memcached或JCS这样的缓存服务。