RFC实现模块化架构

Question

寻找有关Web应用程序模块化的意见。大多数应用程序已经有了后端数据库，并且支持与各自的Web应用程序服务器（Apache，IIS，Lighttp等）的绑定，但是我处理过的很多开发人员都遇到了使用Memcached或任何东西的问题。在Web应用程序的直接进程空间之外。

Web应用程序的模块化是一件好事，我认为或者是否有一些我缺少的东西导致从开发人员到CTO的每个人都犹豫是否要将业务逻辑的特定部分移出Web前端结束并进入专门的后端服务？

例如，几年前，当我建议我们将流程密集型ACL逻辑从前端框架中删除并将其转换为半群集服务时，我在一个非常高流量的网站的项目设计会议中被击落应用在后端。对我来说，好处是通过使用REST / JSON作为PHP和＆amp;之间的桥梁，更清晰地分离代码和在多个地方重用ACL逻辑的能力。蟒。

那些不同意我的想法的开发人员认为它“太复杂”但我只是看不出来怎么样？我的论点是，正如表达层可以标记汤一样，可以并且通常是一个逻辑汤的代码，如果出现问题，它可能几乎不可能执行“外科手术”修复。 / p>

所以要缩短它，那是什么？＆amp;或者将大型应用程序分解为独立但合作的进程（不是线程或子请求）。 MySQL，Memcache，类似的服务过程都很棒......但为什么不是别的呢？如何沿着这条道路“过于复杂”？

Answer 1

嗯，有时候“太复杂”意味着“我不想在我的困境区之外思考。”

基本概念听起来不错 - 你在这里谈论的服务导向架构非常合理。

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

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

但是，在专业方面，如果您能够满足会话状态问题，那么您将获得高度可扩展的架构;如果您需要更多服务，可以放大服务器或只是添加另一台服务器。

Answer 2

我喜欢将核心服务器/业务逻辑功能与Web应用程序代码分开。这有几个不同的原因：

1. 您可以更好地控制业务逻辑。将无法与GUI代码混合使用并造成混乱。您希望将所有业务逻辑分开，以便以后可以创建API来调用代码功能，而不是希望没有业务逻辑进入GUI代码。
2. 从一开始你就必须设计一个好的API，你必须自己用它来与客户端的服务器进行通信。客户端可以是Web界面，也可以是远程用户。
3. 稳定性。 GUI Web代码很容易写错，占用太多内存，从而导致整个应用程序崩溃。
4. 要扩展，您可以将这些单独的组件移动到不同的服务器。如果您使用的缓存系统已经允许集群扩展，那么就像添加更多缓存服务器一样简单。
5. 我发现应用程序更新最常用于GUI代码，因此核心服务不必在大多数时间内删除。
6. 安全。您可以确定安全代码是在服务器代码中实现的，因此如果有人使用您的API，他们将无法绕过任何进入GUI代码的安全代码。

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