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 回答