マルチテナンシー-マイクロサービスアーキテクチャのテナントプロバイダー
現在、クライアントごとのサーバーアーキテクチャをマルチテナンシーアーキテクチャに移行中です。私たちが抱えている1つの設計上の問題を除いて、すべてが整っています。
サブドメインを使用して、それがどのテナントであるかを判別し、適切なDB（テナントごとのDB）にルーティングします。
次のフィールドを持つテナントクラスがあるとします。
- Id
- サブドメイン
- DB接続文字列
問題は、テナントのデータを保存する方法です。簡単な質問のように聞こえますが、問題は、高速で信頼性が高い必要がある各リクエストで発生するため、各サービスがそのテナントリストにアクセスする必要があることです。ほとんどのサービスは同じマシン上にないことに注意してください。以下のオプションについて検討しましたが、特にあなたの経験に基づいている場合は、あなたの意見を聞いていただければ幸いです。
- JSONファイル-すべてのテナントはJSONファイルに保存されます。利点は、非常にシンプルで高速であることです。しかし、このファイルはすべてのサービスからアクセスできるわけではないため、私たちには関係ありません。
- API-すべてのテナントを保持し、テナントリストを取得するためのREST/GRPC APIを公開する別のサービスを用意します。それに関する問題は、パフォーマンスの問題を引き起こすでしょう各着信要求で要求を行う必要があることです。これは重要な情報であるため、キャッシュが問題になる可能性があります。
- スレーブキャッシング-テナントのすべての情報を保持する集中型サービスがあります。各サービスには、テナントリストを取得するためのAPI（およびストレージ）もあります。メインサービスでテナントを作成または編集するたびに、依存するすべてのサービスが更新されます。ここでの問題は、すべてのサービスで同じAPIを作成して登録する必要があるため、オーバーヘッドが増えることです。
- 共有DB-すべてのテナントを管理するための1つの集中サービスですが、テナントのテーブル/ DBは他のすべてのサービスに公開されるため、直接クエリを実行できます。ここで私が見る問題はパフォーマンスです。そのDBは、すべてのリクエストがクエリを実行する必要があるため、プラットフォーム全体にとって重要な役割を果たします。
- マスターキャッシング-各サービスには独自のテナントリストがあります。新しいリクエストでは、テナントを探します。見つからない場合は、テナントのサービスで探してローカルリストに追加します。ここでの問題は、テナントの編集にあります。おそらくすべての依存サービスを更新する必要があるため、スレーブキャッシュアプローチを使用する方が理にかなっています。
他の方法がないのですか？
事前にありがとう、シャウル
私が正しく理解している場合は、tenant_id（*）をサービスのほとんど（すべて？）に伝達する必要があります。これにより、そのtenant_idがデータベースアクセス情報に変換されます（すべてのサービスが使用しているのと同じdbであるか、別のもの）。
このケースは認証に非常に似ているようです（私はあなたのサービスがtenant_idの理解を互いに信頼し合うという印象を受けましたが）。
解決策としては、ある種の分散型Key-Valueストレージでも役立つ場合があります。それらは非常に高速なので、おそらく回答をキャッシュする必要すらありません。 Key-Valueデータベースは高可用性クラスタに配置できるため、それらがあなたのアーキテクチャのボトルネックになることもないと思います。
したがって、システムの内部セキュリティがどのように配置されているかに応じて、スケーラブルな認証および承認ソリューションか、キーと値のストレージのいずれかを使用します。
なんらかの理由で、「テナントリストの取得」について言及し続けます。 Key-Valueストレージが特定のtenant_idのテナント情報を検索できる場合、リスト全体がリクエストごとに必要になることすらありません。
「しかし、テナントのテーブル/ DBは他のすべてのサービスに公開されるため、直接クエリを実行できます。」 -これは、すべてのサービスでテナントリストを使用できるようにするというソリューションには満足できないようです。また、リクエストがシステムに入力され、テナントの情報が決定されると、特定のテナントに関する情報の鍵となる、ある種の時間制限付きトークンがさらにリクエストの伝播で使用される可能性があります（暗号化された形式であっても）。このようにすると、サービスがドメインを列挙する機会さえありません（それが問題である場合）。
（*）私はそれをtenant_idと呼んでいますが、それはサブドメインまたはテナントの自然IDである可能性があります。これは、エントリ時に確立できます（テナントを認証していますよね？）