0

我正在开发一个正在标准 LAMP 堆栈上开发的庞大系统。长话短说，我们犯了太多错误，我们目前的发展方向变得不可持续。我们总结的问题：

  • 正在使用自定义和非常基本的 PHP MVC 框架，它不强制执行任何结构。
  • 不使用 ORM，允许开发人员提出自己的系统。
  • 前端由 Smarty 渲染，除此之外所有的动态交互都是用 jQuery 完成的。
  • 我们在 PHP 失败/非常慢的部分系统中进行了一些繁重的处理。
  • 没有使用单元测试
  • REST 仅用于外部系统的某些 API
  • PHP 框架不支持依赖注入

我不会提及导致系统变得一团糟的其他问题，我认为这些是主要问题。

我想通过引入类似于 Twitter 使用的东西来将系统的开发转向不同的方向 - 系统拆分为与 REST 连接的模块（如果我的假设是正确的）。这些是我想介绍的：

  • 播放框架（Java/Scala）
  • 通过 REST 将 Play 与现有的 LAMP 堆栈连接起来
  • 将 Apache 切换到 Nginx
  • （最有可能）使用 Angular.js 作为前端。
  • 从长远来看，将整个现有 LAMP 转换为 Play

我面临的主要问题是：

  • 记住 REST 是无状态的，我将如何维护/传递状态？我们当前的 LAMP 显然为此使用了 PHP 会话。

也欢迎对这种特殊情况提出任何其他意见。

4

1 回答 1

1

你想分享什么状态？当前登录的用户？还要别的吗？你想和什么分享？在不同的 Play 节点之间？在 Play 和您的 LAMP 堆栈之间？

如果状态量很小，并且不敏感（即当前用户可以看到该状态），那么您可以使用 Play 的会话。播放会话是完全无状态的，它们将状态存储在 cookie 中，并对 cookie 进行签名以防止篡改。更多信息在这里：

http://www.playframework.com/documentation/2.2.x/ScalaSessionFlash

如果您对每个 Play 模块使用相同的应用程序密码（应用程序密码是用来签名/验证会话 cookie 的），那么它们都将能够使用该机制共享状态。您甚至可以与现有的 LAMP 堆栈共享该状态，您只需要在 PHP 中实现 Play cookie 签名算法。

如果状态较大，例如您正在使用它来缓存内容，或者如果您想存储可能敏感的状态，那么像 memcached 这样的东西可能对您很有效。

于 2013-10-01T05:29:28.240 回答