クライアント エントリ ポイントがサブドメインであるマルチクライアント シナリオでは、クライアントを本質的にアプリ (キャッシュ、構成、ログ、カーネルなど) を含むディレクトリに分割し、「コア」にシンボリック リンクを戻すことができるかどうか疑問に思っています。 " 残りの symfony ディレクトリ (vendor、src、および web)。これにより、バンドルに関してアプリケーションを統一したままにすることができますが、クライアントごとに個別の構成が提供されます。次に、サブドメインをそれぞれのディレクトリに向けます。
表面的には、これは有望で、私が検討してきた他のアプローチよりも簡単に思えます。後でクライアントをバージョン 2 にアップグレードしたり、コンポーネントを追加したりする場合は、バンドルを切り替えたり、シンボリック リンクをまったく新しいソースに向けることさえできます。また、うまくスケーリングすることもできます。また、このアプローチを使用すると、サブドメインをチェックして、ユーザーがサブドメインを手動で切り替えた場合に認証にリダイレクトするのではなく、クライアント間で個別のセキュリティ コンテキストを維持できるかどうかも疑問に思っています。
欠点は、いくつかの構成ファイルが重複することと、より複雑な初期クライアント セットアップです (正直なところ、私の意見では悪いことではありません)。
Symfony2 は、そのような再配置を処理するのに十分柔軟ですか?
マルチクライアント アプリでキャッシュを分離する速度やセキュリティなどの利点はありますか?
各構成で個別のファイアウォールを使用すると、サブドメインごとに個別のセキュリティ コンテキストが発生しますか?
背景/追加情報:
マルチ クライアント/テナントになるようにアプリケーションを再開発しています。オリジナルが Doctrine の上にあったため、再設計で Symfony2 を使用しています。現在、より堅牢なフレームワーク機能が必要です。単一のアプリケーション (すべてのクライアントで同じ) を維持し、クライアントごとに個別のデータベースを用意したいと考えています。私の期待は、現実的には最大で 100 ~ 200 のクライアントです (それを超えると、お祝いしてから心配します)。スキーマはデータベース間で同じです。バックアップ/復元を容易にするため、および後で個別のアップグレード パスのために分離しています。
マルチテナシーに関する数多くの質問と回答を読むのに時間を費やしました。また、ルーティングとカーネル リスナーを使用してサブドメインを使用してクライアント ID を収集し、データベース接続を動的に選択することなどについても説明しました。最終的に、Orm-designer.com から、サイトを新しい VPS。彼らは投稿でディレクトリ構造を詳しく説明しており、自分の目的に合わせて概念をどのように適応させるかを考えさせられました.