0

私は、標準の LAMP スタックで開発中の巨大なシステムに取り組んでいます。簡単に言えば、あまりにも多くの過ちが犯され、現在の開発ベクトルは持続不可能になりつつあります。要約すると、次の問題があります。

  • カスタムで非常に基本的な PHP MVC フレームワークが使用されており、構造が強制されていません。
  • ORM は使用されないため、開発者はそれぞれ独自のシステムを考え出すことができます。
  • フロント エンドは Smarty によってレンダリングされますが、動的なやり取りはすべて jQuery で行われます。
  • PHP が失敗している、または非常に遅いシステムの一部で、重い処理が行われています。
  • 単体テストは使用されません
  • REST は、外部システムへの一部の API にのみ使用されます
  • PHP フレームワークは依存性注入をサポートしていません

システムが完全に混乱する原因となる他の問題については言及しませんが、これらが主な問題であると考えています。

Twitter が使用しているものに似たものを導入することで、システムの開発を別の方向に向けたいと思います。システムは REST に接続されたモジュールに分割されます (私の仮定が正しければ)。これらは私が紹介したいものです：

  • Play フレームワーク (Java/Scala)
  • Play を REST 経由で既存の LAMP スタックに接続する
  • Apache を Nginx に切り替える
  • (ほとんどの場合) フロント エンドには Angular.js を使用します。
  • 長期的には、既存の LAMP 全体を Play に変換します

私が直面している主な問題は次のとおりです。アドバイスをいただければ幸いです。

  • RESTはステートレスであることを念頭に置いて、どのように状態を維持/渡すのですか? 現在の LAMP は明らかに PHP セッションを使用してこれを行います。

この特定の状況に関するその他のコメントも歓迎します。

4

1 に答える 1

1

どの状態を共有したいですか? 現在ログインしているユーザーは? 他に何か？そして、それを何と共有したいですか？異なる Play ノード間? Play と LAMP スタックの間ですか?

状態の量が少なく、機密性が高くない場合 (つまり、現在のユーザーがその状態を確認しても問題ない場合)、Play のセッションを使用できます。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 に答える