实现模块化架构的 RFC

Question

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

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

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

不同意我的想法的开发人员认为它“太复杂”，但我就是不明白怎么做？我的论点是，就像表示层可以有标签汤一样，也可以而且经常有代码的逻辑汤，它们如此紧密地结合在一起，以至于如果出现问题，执行“手术”修复可能几乎是不可能的。

因此，为了缩短它，将大型应用程序分解为独立但协作的进程（不是线程或子请求）的缺点和优点是什么。 MySQL、Memcache、类似的服务流程都很棒……但为什么不呢？怎么走这条路“太复杂了”？

Answer 1

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

基本概念听起来不错 --- 您在这里谈论的是相当合理的面向服务的架构。

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

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

不过，在专业方面，如果您能满足会话状态问题，您将获得高度可扩展的架构；如果您需要更多服务，您可以扩大服务器或简单地添加另一台服务器。

Answer 2

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

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

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