27

私は現在、Spring、GWT、Hibernate、Jackrabbit、Hibernate Search / Lucene（とりわけ）を使用するシングルテナントのJavaベースのWebアプリを本格的なSaaSスタイルのアプリに変換することを検討しています。

SaaSアプリにするために単一のテナントアプリに加える重要な変更として、次の7つの「もの」を強調する記事に出くわしました。

  1. アプリケーションはマルチテナンシーをサポートする必要があります。
  2. アプリケーションには、ある程度のセルフサービスサインアップが必要です。
  3. サブスクリプション/請求メカニズムが整っている必要があります。
  4. アプリケーションは効率的に拡張できる必要があります。
  5. アプリケーションとテナントを監視、構成、および管理するための機能が整っている必要があります。
  6. 一意のユーザーの識別と認証をサポートするメカニズムが必要です。
  7. テナントごとにある程度のカスタマイズをサポートするメカニズムが必要です。

私の質問は、私がリストしたものと同様のテクノロジーを使用して、SaaS /マルチテナントアプリに上記の7つのことのいずれかを実装した人はいますか？私は、現在検討している道を進む前に、そうするための最良の方法についてできるだけ多くの意見を得ることに熱心です。

まず、モデルレベルで複数のテナントを処理する方法を十分に理解していると確信しています。すべてのテーブルにテナントIDを追加してから、Hibernateフィルター（およびHibernate Searchのフルテキストフィルター）を使用して、ログオンしているユーザーのすべてのクエリのテナントIDに基づいてフィルター処理することを考えています。

ただし、特にテナント数が非常に多くなった場合は、パフォーマンスについても懸念があります。

このようなソリューションを実装する方法についての提案は大歓迎です（そして、この質問が少し自由すぎる場合はお詫びします）。

4

5 に答える 5

14

4 種類のテナント分離 (テナントごとに個別のデータベース、テナントごとに個別のスキーマ、テナントごとに個別のテーブル、テナント ID を持つすべてのテナントの共有テーブル) をすべてサポートするようにアプリケーションを設計することをお勧めします。これにより、成長に合わせてデータベースを水平に分割する柔軟性が得られ、それぞれが小さなテナントのグループを持つ複数のデータベースを持ち、一部の大規模なテナント用に別のデータベースを持つこともできます。大規模なテナントの中には、アプリケーションをクラウドから実行できる一方で、データ (データベース) をオンプレミスに配置する必要があると主張する場合もあります。

以下は、アプリケーションを設計する際に考慮すべき機能以外の機能およびインフラストラクチャ レベルの機能の詳細なチェック リストです (一部はすぐには必要ないかもしれませんが、必要な場合にそのようなニーズにどのように対処するかというビジネス状況を考えてみてください)。競争がそれを提供し始めます）

  1. a) UI テーマとロゴ、b) フォームとグリッド、c) データ モデル拡張とカスタム フィールド、d) 通知テンプレート、e) ピックアップ リストとマスター データのテナント レベルのカスタマイズ
  2. 役割と権限のテナント レベルの作成と管理、フィールド レベルのアクセス権限、データ スコープ ポリシー
  3. モジュールと機能のテナント レベルのアクセス制御設定。サブスクリプション パッケージに応じて、特定のモジュールと機能を有効または無効にできます。
  4. タスク/イベント/トランザクションの計測と監視、および購入したクォータを超えた場合のアクセス制御の制限。ビジネスモデルが変更された場合に、将来的に新しいエンティティを測定する機能。
  5. ビジネス ルールとワークフローをコード ベースから外部化し、それらをメタ データとして表現して、テナント グループ / テナントごとにカスタマイズできるようにします。
  6. テナントと特定のテナントによって追加されたカスタム フィールドを認識するカスタム レポートを作成するためのクエリ ビルダー。
  7. テナントのカプセル化とフレームワーク レベルの接続文字列管理により、開発者はクエリの作成中にテナント ID について心配する必要がなくなります。

これらはすべて、あらゆるドメインやアプリケーションに使用できる汎用マルチテナント フレームワークを構築した経験に基づいています。残念ながら、当社のフレームワークは .NET ベースであるため使用できません。

ただし、マルチテナント SaaS 製品 (新規または移行済み) のエンジニアリング ニーズは、使用するテクノロジ スタックに関係なく同じです。

于 2011-04-19T10:26:51.967 に答える
4

あなたがリストしたすべてのテクノロジは、シングル テナント アプリケーションとマルチテナント アプリケーションの両方で非常に一般的で合理的です。SaaS の 7 つの「もの」をサポートすることは、どのテクノロジーをどのように使用するかというよりも、テクノロジーをどのように使用するかにかかっていると言えます。動作するシングルテナント アプリケーションが既にあるようです。したがって、何かがすでにうまく機能していない場合を除き、そこにあるテクノロジーの選択から逸脱する理由はあまりないでしょう。ただし、それ以外の場合、質問はかなり自由回答であるため、より具体的にすることは困難です。

ただし、テナント ID によるデータベース (およびおそらくその他のもの) の分割について、いくつかのフィードバックがあります。最終的に多くのテナントを持つ可能性があることがわかっている場合 (特に小規模の場合は数千以上)、提案するものがおそらく最適です。ただし、テナントの数が少ない場合 (特にテナントが大きい場合) は、テナントごとにデータベースを検討して、それぞれに独自のテーブル スペースを持たせることをお勧めします。つまり、テナントごとに 1 つの同じスキーマの複数のインスタンスが内部にある単一のデータベース インストールを意味します。

これが利点となる理由はいくつかあります。一つは、おっしゃる通りのパフォーマンスです。すべての単一テーブルにテナント ID を追加すると、ディスク アクセス、クエリ時間のオーバーヘッドが発生し、コードが複雑になります。データベース内のすべてのインデックスには、テナント ID も含める必要があります。注意しないと、テナント間でデータが混在するという追加のリスクが発生します (ただし、Hibernate フィルターはそれを軽減するのに役立ちます)。テナントごとのデータベースを使用すると、アクセスを正しいものだけに制限できます。現在のアプリケーションの移植もおそらくはるかに簡単になります。基本的には、URL に基づいてテナントを決定し、適切なデータベースを指すように、どこかで要求をインターセプトする必要があるだけです。バックアップもテナントごとに簡単に実行できます。これは、テナントにバックアップのダウンロードを許可する場合に特に役立ちます。

一方で、そうしない理由もあります。多くのデータベース スキーマを処理する必要があり、それらを個別に更新する必要があります (これは、スキーマの変更のためにすべてのテナントをダウンさせたくない場合に実際に利点となります。それらを段階的にロールアウトできます)。これにより、プラットフォームを一度にすべてアップグレードされる真のマルチテナント SaaS 展開として扱うことから逸脱する可能性がある特殊なケースが可能になり、その結果、運用環境で複数のバージョンが管理されます。最後に、ほぼすべてのデータベース ベンダーが、1 回のインストールでサポートするスキーマ インスタンスの数に限界点があると聞きました (おそらく、数十万に達するものもあります)。

もちろん、ユースケースによって異なります。あなたはシングルテナントについて言及したので、現在テナントが多すぎるとは思われませんが、多くのテナントに成長していると述べています。数百または数百万を意味するかどうかはわかりませんが、いずれにしても、これがあなたの考慮事項に役立つことを願っています. 頑張ってください！

于 2011-03-30T03:57:44.030 に答える
0

(1) の場合: Hibernate は、バージョン 4 からすぐに使用できるマルチテナント構成をサポートします。執筆時点では、DB-per-tenant と schema-per-tenant がサポートされており、ディスクリミネーターを使用してすべてのテナントを同じ DB に保持することはまだありません。サポートされています。この機能をアプリケーションでうまく使用しました (クライアントごとの DB アプローチ)。

(3) の場合: いくつかの調査を行った後、Braintree で課金を実装することにしました。多くの人が推奨するもう 1 つのソリューションは、Authorize.net、Stripe、PayPal です。

(4) の場合: Hibernate/Spring および JBoss Cache を使用したクラスター構成を使用して、第 2 レベルのキャッシングを行いました。最近では、これが「一般的」になり、Jelastic などの PaaS サービスを使用すると、事前に設定してすぐに使用することもできます。

于 2012-04-16T17:26:54.430 に答える
0

簡単な答えはありません。私は自分の解決策を説明できます。それは他の人にとってのインスピレーションとして役立つかもしれません。

  • データベースあたりのテナント (postgre)
  • テナント間で共有される 1 つの追加データベース
  • 春 + MyBatis
  • Spring Security 認証

詳細はこちら: http://blog.trixi.cz/2012/01/multitenancy-using-spring-and-postgresql/

于 2012-01-29T17:55:40.213 に答える