0

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

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

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

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

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

4

2 回答 2

1

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

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

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

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

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

于 2009-02-16T06:54:50.670 回答
1

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

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

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

于 2009-02-16T07:08:44.397 回答