タグ付けされた質問 「microservices」

最も単純なマイクロサービス設計であっても、データの重複や共有データベースを回避するのが難しいと感じているため、何かが足りないと思っています。これが私が直面している問題の基本的な例です。誰かがWebアプリケーションを使用して在庫を管理していると仮定すると、2つのサービスが必要になります。1つはアイテムと在庫数を管理する在庫管理用、もう1つはユーザーデータを管理するユーザーサービス用です。データベースの在庫者の監査が必要な場合、在庫サービスのデータベースにユーザーIDを最後に在庫された値として追加できます。 アプリケーションを使用して、不足しているすべてのアイテムと、前回アイテムを在庫していた人のリストを確認して、再度在庫を補充するよう依頼することができます。上記のアーキテクチャを使用して、在庫サービスにリクエストを行い、数量が5未満のすべてのアイテムのアイテム詳細を取得します。これにより、ユーザーIDを含むリストが返されます。次に、インベントリサービスから取得したユーザーIDのリストのユーザー名と連絡先の詳細を取得するために、ユーザーサービスに対して別の要求が行われます。 これは非常に非効率的なようで、複数のデータベースクエリを作成するさまざまなサービスAPIに対して複数のリクエストを行うまで、これ以上多くのサービスを必要としません。別の方法は、インベントリデータにユーザーの詳細を複製することです。ユーザーが連絡先の詳細を変更した場合、他のすべてのサービスを通じて変更を複製する必要があります。しかし、これは、マイクロサービスの限定されたコンテキストの考えに適合しないようです。また、単一のデータベースを使用してこれを異なるサービス間で共有し、統合データベースのすべての問題を抱えることもできます。 これを実装する正しい/最良の方法は何ですか？

19 microservices 

前景 モノリシックプラットフォームから、よりサービス指向のアーキテクチャに移行しています。非常に基本的なDDDの原則を適用し、さまざまな境界のあるコンテキストにドメインを分割しています。各ドメインは配布され、Web API（REST）を介してサービスを公開します。 ビジネスの性質上、予約、サービス、顧客、製品などのサービスを提供しています。 また、主な役割が以下のことを行うIdentity Server（Thinktecture Identity Server 3ベース）をセットアップしました 認証の集中化（トークンを発行する資格情報を指定） 次のようなトークンにクレームを追加します：クライアントのスコープ（クライアントごとに要求を行うアプリケーションを意味する）、顧客識別子（顧客ごとにアプリケーションを使用する人を意味する） また、サービスへの外部アクセスを集中化するAPI Gatewayの役割も導入しました。API Gatewayは、次のような内部ドメインの深い知識を必要としない機能を提供します。 リバースプロキシ：着信要求を適切な内部サービスにルーティングします バージョン管理：API Gatewayのバージョンは、内部サービスの異なるバージョンにマップされます 認証：クライアント要求には、Identity Serverによって発行されたトークンが含まれ、API Gatewayはトークンを検証します（ユーザーが本人であることを確認してください） 調整：クライアントごとの要求数を制限する 認可 認可に関係するものは、これはAPI Gatewayではなく、内部サービス自体で管理されます。現在、主に2種類の承認を行っています。 クライアントスコープに基づく承認。例：クライアント（APIを使用する外部アプリケーション）には、予約サービスAPIエンドポイントにアクセスするためのスコープ「bookings」が必要です 顧客に基づいた承認。例：顧客（アプリケーションを使用する実在の人物）が予約の参加者である場合のみ、予約サービスからエンドポイントGET / bookingsにアクセスできます。 内部サービスで認証を処理できるようにするために、API Gatewayは、クライアント（要求を行うアプリケーション）と顧客としての情報の両方を含むトークン（内部サービスに要求をルーティングするとき）を転送するだけです人がクライアントアプリケーションにログインしている場合）。 問題の説明 これまでのところ、サービス間通信（一部のサービスは他のサービスと通信してデータを取得できます）を導入するまではこれで十分です。 質問 サービス間通信の認可にどのようにアプローチすればよいですか？ 考慮されるオプション さまざまなオプションについて説明するには、次のサンプルシナリオを使用します。 予約フローを構築するために、APIにアクセスするExternalAppと呼ばれる外部アプリケーションがあります（ExternalApp はクライアントとして見ることができます） ExternalAppはBookingsサービスにアクセスする必要があるため、ExternalAppにスコープ「bookings」を付与します 内部的に（これはExternalAppに対して完全に透過的なものです）、予約サービスはサービスサービスにアクセスして、フライト、保険、レンタカーなどの予約のデフォルトサービスを取得します この問題を内部で議論する際、いくつかのオプションが表示されましたが、どのオプションが最適かはわかりません。 BookingsがServicesと通信する場合、API Gatewayから受信した元のトークンを単純に転送する必要があります（クライアントがExternalAppであることを示します） 意味：付与されるべきではないExternalAppにスコープを付与する必要がある場合があります。例：ExternalAppにはスコープ「bookings」と「services」の両方が必要な場合がありますが、「bookings」スコープのみで十分です。 BookingsがServicesと通信する場合、クライアントが（ExternalAppの代わりに）Bookingsになったことを示すトークンを転送し、Bookingsが元のクライアントExternalAppになりすましていることを示すクレームを追加します また、元のクライアントがExternalAppであるという情報を含めることにより、サービスサービスは元の呼び出し元に応じて一部のサービスを除外するなどのロジックも実行できます（たとえば、内部アプリの場合はすべての戦いを返し、外部アプリの場合は一部のみ） サービスは互いに通信すべきではありません（そのため、この質問に直面するべきではありません） ご意見をお寄せいただきありがとうございます。

18 api  microservices  soa  authorization 

私のチームは、モノリシックASP.NETアプリケーションから.NET CoreおよびKubernetesに移行しています。コードの変更は予想通りに進行しているように見えますが、私のチームが多くの不一致に遭遇しているのはデータベースの周辺です。 現在、ビジネス全体のすべてのデータを格納するかなり大きなSQL Serverデータベースがあります。私は、コードを分割するのと同様の方法でデータベースを分割することを提案しています-1つの（論理）データベースのカタログデータ、別のデータベースの在庫データ、別の注文など-そして各マイクロサービスはそのデータベースのゲートキーパーになるでしょう。 ここでの意味は、マイクロサービスの境界を越える外部キーを削除する必要があり、境界を越えて到達するprocsおよびビューは禁止されることです。すべてのデータモデルは同じ物理データベースに存在する場合と存在しない場合がありますが、存在する場合でも、相互に直接対話することはできません。注文は引き続きIDでカタログアイテムを参照しますが、データベースレベルでデータの整合性が厳密に強制されることはなく、そのデータはSQLではなくコードで結合する必要があります。 これらの損失は、マイクロサービスへの移行と、それに伴うスケーラビリティのメリットを得るための必要なトレードオフと考えています。縫い目を賢く選択し、それらの周りに展開する限り、問題ありません。他のチームメンバーは、すべてが同じモノリシックデータベースにとどまる必要があるため、すべてがACIDであり、参照整合性をどこにでも保持できることを固く主張しています。 これは私の質問に私をもたらします。まず、外部キーの制約と参加に対する私の姿勢はもっともらしいですか？もしそうなら、誰かが私が同僚に提供できる信頼できる読み物を知っていますか？彼らの立場はほとんど宗教的であり、彼らはマーティン・ファウラー自身が彼らが間違っていると告げる以外に何かに左右されることはないようです。

18 architecture  database  refactoring  microservices 

私はマイクロサービスアーキテクチャが比較的新しいです。適度なサイズのWebアプリケーションがあり、現在進めているモノリシックシステムではなく、マイクロサービスに分割することの長所と短所を比較検討しています。 私が理解している限りでは、マイクロサービスAと、Bそれぞれが他方のデータのサブセットに依存しているものを検討してください。A何かが変更されたというメッセージが投稿された場​​合、Bそのメッセージを消費し、Aの情報のローカルコピーを複製し、それを使用してB必要な処理を実行できます。 ただし、もしBダウンしたり失敗したりしてしばらくすると、再び元に戻ります。そのダウンタイム中に、Aさらに2つのメッセージを公開しました。の情報のBローカルコピーを更新する方法はどのようにしてわかりますAか？ 場合確かに、B唯一の消費者であるAのキューは、それはそれがオンラインに戻ったら、それを読み始めることができますが、どのような場合には、そのキューとそれらのメッセージの他の消費者が消費されているがありますか？ より具体的な例として、マイクロサービスがダウンしているUsers間にBillingサービスの電子メールアドレスが更新された場合、Billingマイクロサービスが再び復旧した場合、電子メールが更新されたことをどのようにして知ることができますか？ マイクロサービスが復旧すると、「ちょっと復旧しました。現在の情報をすべて教えてください」というブロードキャストを行います。 一般に、データ同期の業界のベストプラクティスは何でしょうか？

17 database  microservices 

API Gatewayパターンに従ってREST APIを介して機能を公開するマイクロサービスがたくさんあります。これらのマイクロサービスはSpring Bootアプリケーションなので、Spring AMQPを使用して、これらのマイクロサービス間でRPCスタイルの同期通信を実現しています。これまでのところ物事は順調に進んでいます。ただし、イベント駆動型のマイクロサービスアーキテクチャについて詳しく読んで、Spring Cloud Streamなどのプロジェクトを見ると、RPC同期アプローチで間違った方法で物事をしている可能性があると確信するようになります（特に、これをスケーリングする必要があるため）クライアントアプリケーションからの1秒あたり数百または数千のリクエストに応答するため）。 イベント駆動型アーキテクチャの背後にあるポイントを理解しています。私がよく理解していないのは、すべての要求に対する応答を期待するモデル（REST）の後ろに座っているときに、そのようなパターンを実際に使用する方法です。たとえば、APIゲートウェイをマイクロサービスとして使用し、ユーザーを保存および管理する別のマイクロサービスがあるGET /users/1場合、純粋にイベント駆動型のようにモデル化するにはどうすればよいですか？

16 spring  asynchronous-programming  microservices  event 

API Gatewayについて読むと、毎回出てくるものの1つは、API Gatewayが複数のエンドポイントからの結果を集約する場所であるということです。それは本当にいいですね。ただし、AWS API Gateway、Kongo、Netflix Zuulなどの多くの一般的なAPI Gatewayソリューションは、このような機能をサポートしていません。ハックするか、カスタムフィルターを自分で実装する必要があります。 集約は悪い習慣と見なされていますか？複数のエンドポイントから結果を返す方法

15 rest  api  microservices 

TL; DR-サービス間でPOJOライブラリを共有しても大丈夫ですか？ 一般的に、可能な場合は、サービス間の共有を厳密に制限します。データを共有しているサービスが、クライアントが使用するクライアントライブラリを提供するかどうかについては、いくつかの議論がありました。client-libは通常、サービスのクライアントが使用するオプションであり、client-libを使用するか、代替言語を使用してライブラリなどの一般的な側面を使用するかを問わず、APIを消費できます。 私の場合、データのオブジェクトを作成するサービスを検討しています。このオブジェクトがPETであると仮定しましょう。これはデータベースエンティティではなく、厳密に基になるデータを暗黙的に表すPOJOです。このPOJOは、APIが定義したものです。想定：ペット-年齢、体重、名前、所有者、住所、種など サービス1 -PetKeeper：何らかの理由でペットを生成し、すべてのデータを保持し、このサービスを参照してペットを取得するか、ペットに変更を加え、名前の変更または住所の変更を行う必要がありますこのサービスへのAPI呼び出し。 サービス2 -PetAccessor：このサービスはペットを収集し、検証チェックを行います サービス3,4-より多くの中間サービス呼び出し サービス5-ユーザーインターフェイス これらは非常にarbitrary意的ですが、ポイントは簡単です。UIまたはユーザー向けのサービスは、何らかの方法でこの「PET」オブジェクトを提示したいと考えています。APIを介してサービスを呼び出す必要があります。サービスは、サービスを呼び出し、サービスを呼び出すなど、必要な情報を収集してリレーバックを開始するサービスに到達するまで呼び出します。最後に、UIサービスには表示するPETオブジェクトがあります。 これは非常に一般的ですが、絶対的な考え方で、すべてのサービスでPETオブジェクトを複製しました。DRY（繰り返さないでください）の原則は、サービス内のコードにのみ適用され、サービス全体には適用されませんが、ポイントはまだあります。フィールドを追加したらどうなりますか...それぞれのPOJOの5つのサービスを変更する必要があります。 -または-APIからのpojoの一部を含むPet-Objects-Libraryを提供できます。各サービスはライブラリにインポート/依存できます。サービス自体への依存関係はありませんが、一般的なライブラリのみに依存しています。各サービスが同じタイプのオブジェクトを持ち、更新が簡単になるように、私はこのアイデアが好きです。しかし、私はGod-Objectsを心配しています。 賛否両論-最適な設計は何ですか？同じPOJOクラスの繰り返しを最小限に抑えながら分離されたままにするために、サービス間でデータを渡すために何をしましたか？

15 java  dto  microservices 

私は最近マイクロサービスについて多くのことを読んでいますが、これまでに得た結論のいくつかを以下に示します（私が間違っている場合は修正してください）。 マイクロサービスアーキテクチャは、ドメイン駆動型の設計に適しています。通常、1つのMSは1つの境界付きコンテキストを表します。 マイクロサービスAがマイクロサービスBにある機能を必要とする場合、私のモデルはおそらく間違っており、AとB は実際には1つのマイクロサービス/ BCである必要があります。 マイクロサービス（直接HTTPリクエスト）間の同期通信は不良であり、マイクロサービスの目的に反し、コンポーネント間の結合を導入します。 サービス間の非同期通信が望ましい。サービスはイベントをメッセージキューに発行する必要があります。これにより、他のサービスがイベントの一部をサブスクライブおよび処理したり、コンテキストを使用してデータの一部を複製したりできます。これにより、サービスは他のサービスがダウンしていても要求を処理できますが、同期通信の場合はそうではありません。 マイクロサービスAがイベントを発行し、マイクロサービスBがそのイベントをサブスクライブし、結果として新しいイベントを生成する場合、マイクロサービスAが新しく作成されたイベントを処理するものであってはなりません。この場合、3番目のマイクロサービスを導入するか、ABマイクロサービスにAとBを組み合わせます。 マイクロサービスは実際には誤解を招く用語です。私たちは小さな文脈に努めるべきですが、そうである必要はありません。用語は「マイクロサービス」ではなく、「ジョブサービスを行うのに十分な大きさ」である必要があります。 マイクロサービスにより、システム全体を壊すことを恐れることなく、より簡単に新しい機能を導入できます。新しいサービスを導入するか、既存のサービスをリファクタリングすることで実現できます。 各マイクロサービスには、独自のデータストレージが必要です。このアーキテクチャでは、データの複製/複製が望ましい動作です。 このアーキテクチャについての私の理解を確認する以外に、質問の他の部分は主にサービスの発見に関連しています。サービスが非同期で通信しており、Amazon SQSのような中央イベントキューを使用している場合、そのようなアーキテクチャではサービスディスカバリーがその場所にないということですか？ サービスは、システム内の他のサービスに関する知識を持っていてはなりません。彼らは、自分のコンテキストと、発行または購読するイベントのみを認識していますか？

15 architecture  domain-driven-design  soa  microservices 

会社のシステムをマイクロサービスベースのシステムにリファクタリングする予定です。このマイクロサービスは、社内の社内アプリケーションと、必要に応じてサードパーティパートナーによって使用されます。予約用、製品用など ロールとスコープをどのように処理するかは不明です。管理者、エージェント、エンドユーザーなどの3つの基本的なユーザーロールを作成し、必要に応じてコンシューマーアプリがスコープを微調整できるようにするという考え方です。 管理者は、デフォルトで（会社の）すべてのリソースを作成、更新、読み取り、削除できます。 エージェントは、会社のデータを作成、更新、および読み取ることができます。 エンドユーザーはデータを作成、更新、削除、および読み取ることができますが、エージェントまたは管理者と同じエンドポイントにアクセスすることはできません。また、エージェントや管理者と同じレベルではなく、データを作成または変更することもできます。たとえば、エンドユーザーはアカウント情報を更新または読み取ることができます。これは、エージェントができるようになりますが、管理者ノートを表示または更新することはできません。 デフォルトでは、エージェントは会社の各リソースを作成、読み取り、更新でき、それはトークン/セッションに要求できる最大スコープですが、クライアント（APIコンシューマー）アプリケーションの開発者は、エージェントの1人が特定のリソースのみを読み取り、作成します。 内部セキュリティでこれを処理し、データベースにデータを書き込むようにするか、クライアントにスコープを小さくしてトークンを要求することで内部的に処理させ、どのエージェントがデータベースにどのスコープを持つかを書き込むようにすることをお勧めします？この方法では、トークンスコープのみを追跡する必要があります。 この欠点は、チームが内部アプリケーションで微調整されたアクセスメカニズムを作成する必要があることです。 この考え方では、マイクロサービスとその承認システムはクライアントのニーズに煩わされるべきではありません。なぜなら、それらは消費者であり、システムの一部ではないからです。 この委任は良いアプローチですか？

15 security  authentication  microservices  authorization 

マイクロサービスアーキテクチャに関する多くの記事を読みましたが、AMQPまたはRESTをいつ使用すべきか疑問に思いました。 サービス間の疎結合は良いことであり、その場合AMQPが良い選択であるように思えます。しかし、AMQPを使用する場合、これはRESTエンドポイントが不要になることを意味します（ただし、HATEOASコンセプトが失われることを意味します）。 しかし、RESTは本当に私のサービスを構築するのに良い方法ですか？原因エンドポイントを使用しません...この場合、一方が他方より優れていますか？ いつどちらを使用すればよいですか？

15 rest  api  web-services  microservices 

マイクロサービスを使用するための一般的な議論の1つは、スケーラビリティの向上です。しかし、私はこの議論が本当に有効かどうか疑問に思います。 10個のマイクロサービスで構成されるアプリケーションがあり、そのうちの9個がそれぞれ2つのインスタンス（冗長性のため）を持ち、そのうちの1つが負荷を処理する4つのインスタンス（スケーラビリティー）を持つとします。この場合、マイクロサービスの賛成論は、このmiroserviceを他のサービスとは無関係にスケーリングできるということです。 ただし、10個のマイクロサービスすべてが単一のモノリスのモジュールであり、このモノリスのいくつかのインスタンス（たとえば上記の合計のような22個）がデプロイされたとしましょう。システムは、1つの重要な部分の負荷を処理できる必要があります。そうするのに十分なインスタンスがあるためです。インスタンスに不要なプログラムロジックが含まれている場合、唯一の欠点は、バイナリと必要なRAMの量がわずかに大きくなることです。しかし、この場合も、ほとんどの場合、差はあまり大きくないはずです-少なくともスタックの残りの部分と比較してはなりません（Spring Bootを考えてください）。スケーリングされたモノリスの利点は、分散システムの（ほとんど）誤りを伴わないシンプルなシステムになります。 何か不足していますか？

15 microservices 

マイクロサービスのアクセス権を制限しながら、マイクロサービスアーキテクチャでユーザーを承認する最適な方法を決定しようとしています。このアーキテクチャでは、中央認証サービスを使用して、JWTトークンの発行を処理します。 次の要件があります。 ユーザーは特定の役割を実行するように制限する必要があります。たとえば、ユーザーは自分が所有するコンテンツのみを作成、変更、または読み取りできる必要があります。 マイクロサービスは、必要な権限のみに制限する必要があります。たとえば、別のサービスからデータを読み取るだけでよいマイクロサービスは、そのサービスへのデータの書き込みを明示的に禁止する必要があります。 例として、ユーザーが画像ストアサービスに写真をアップロードできるシステムがあるとします。写真に位置を自動的にタグ付けするタグ付けサービスがあります。ユーザーは自分の写真のみをCRUDできます。タグ付けサービスは、イメージストアサービスから任意のイメージを読み取ることができますが、変更/削除はできません。 JWTトークンを使用して上記を達成する良い方法は何ですか？私たちが議論したいくつかのソリューションは次のとおりです。 画像ストアサービスは2つのAPIを公開します。1つは外部で利用可能（ユーザーCRUDアクセスを提供）、もう1つは内部で利用可能（内部読み取り専用アクセスを提供）です。柔軟性がないようです-別の内部サービスがすべての画像（たとえば、明示的な画像を自動的に削除するもの）への読み取り/書き込みアクセスを必要とする場合はどうなりますか？ ユーザーのJWTに2つの許可を設定します。1つはCRUD_OwnImagesで、もう1つはREAD_ForAnalysisです。タグ付けサービスは、ユーザーがREAD_ForAnalysis権限を持っているかどうかを確認し、もしそうであれば、適切な要求を行います。ユーザー自身の画像でのCRUD操作のためにユーザーがCRUD_OwnImagesを持っているかどうかを確認する別のマイクロサービスがあります。これにより、各マイクロサービスに責任が課され、ユーザーは必要なアクションに制限されます。画像ストアには、このアプローチで各マイクロサービスを制限する方法がないため、潜在的に不安定でエラーが発生しやすくなります。 READ_ForAnalysisを許可として、タグ付けマイクロサービスに独自のユーザーを与えます。次に、タグ付けサービスが画像ストアから画像を要求すると、それらへのアクセスが許可されますが、それらの変更は禁止されます。ユーザーのユーザーはCRUD_OwnImages権限のみを持っているため、フロントエンドから自分の画像のみを取得してアクセスすることができます。別のサービスがすべてのデータに対してCRUDを必要とする場合、CRUD_AllDataまたは同様のサービスを提供できます。各サービスが独自のデータを担当するようになったため（このロジックは複数のサービスに複製されるのではなく）このアプローチが好きですが、サービスにユーザー権限とマイクロサービス権限の両方が必要な場合はどうでしょうか？2つのJWTトークン（ユーザーとマイクロサービスの両方）を安全に送信できますか？許可を安全に組み合わせて送信する方法はありますか？例えば ユーザー情報がさらに下流に必要な場合（2または3マイクロサービス離れている）、問題は悪化します。私たちは、必要なアクションに自分自身を制限するのは個々のマイクロサービス次第であり、それを明確にしないと仮定するだけですか？

13 security  microservices  jwt 

今日、Webアプリを展開するオーケストレーションシステムである長期実行サービスの「ヘルスチェックを記述する」タスクがありました。 私はそのようなヘルスチェックの範囲が何であるかを決定しようとしていますが、ヘルスチェックの範囲に関連するこれらの質問を思いつきました： オーケストレーションシステムがタスクの実行を報告している場合、サービスが正常であると考えるのに十分ですか？ または、各サービスを手動でpingする必要がありますか？ または、さらに進んで、Webページを表示するなど、Webアプリケーションが本来行うべきことを確実に実行しようとする必要がありますか？ ヘルスチェックでは、いくつかの依存サービスも実行されていることも確認する必要がありますか？データベースまたはオーケストレーションシステム自体のように。または、それは別のヘルスチェックの責任ですか？ そして最後に、依存サービスの1つが停止し、その後Webアプリが失敗した場合、WebアプリはWebアプリの障害ではないため、健康状態が悪い、または健康状態を報告する必要がありますか？ これらは5つの個別の質問であることがわかっていますが、これらはすべて、Webアプリを展開する長期実行サービスのヘルスチェックの範囲に関連しているため、1つの質問にグループ化しておく方が理にかなっていると思いました。 健康なものの定義や、このようなものの標準的な健康チェックがどのように見えるべきかがわからないため、これを実装するのは困難です。 この特定のサービスのヘルスチェックには何を含める必要がありますか？

13 testing  web-services  user-experience  microservices 

現在、2つのマイクロサービスがあります。私たちはそれらAを呼び出しますB。 マイクロサービス下のデータベースにAは次の表があります。 A |-- users マイクロサービス下のデータベースにBは次の表があります。 B |-- trackers 要件にはそれが明記されusersてtrackersおり、多対多の関係があります。 マイクロサービスアーキテクチャ内でこれを適切に処理する方法がわかりません。 これは、次の3つの方法のいずれかで動作することがわかりました。 user_trackersテーブルには、microserviceに追加されますA。これは、「外部キー」への参加を含むテーブルに似た働きusersとtrackers。 ownersテーブルには、microserviceに追加されますB。このテーブルは、ポリモーフィック結合テーブルと同様に機能します。これにより、どのサービスでもトラッカーとの関連付けを作成できます。これは次のようになります。 B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id レコードキープusersし、trackers各microserviceでは。ある種のpubsubシステムと同期してください。 もともとオプション2を使用するつもりだったのは、トランザクションの境界が保存されていることが気に入ったからです。トラッカーを作成して、それをアトミックに関連付けることができます。ただし、microserviceの範囲外のようBです。BマイクロサービスAが関連付けを作成することをマイクロサービスが気にする必要があるのはなぜですか？ ここにはおそらく気付いていない良いパターンがあるように感じます。私がレイアウトしたオプションのいずれかが意味をなしますか？より意味のある別のオプションはありますか？

13 microservices 

現在、モノリシックアプリケーションをマイクロサービスアーキテクチャに移行しています。いくつかの規制要件により、異なる国のクライアントのデータを個別の（国固有の）データベースに保管する必要があります。すなわち、米国の顧客のための米国db、英国の顧客のための英国db ... 私たちが検討している次の設計は次のとおりです。 オプション1：必要に応じてN回までスケーリングできる、休止状態のマルチテナントサポートを備えたマルチテナントアプリケーション（kubernetesポッドを考えてください）。このアプリケーションの単一インスタンスは、すべてのデータベースに接続できます。 オプション2：国のデータベースごとに1つのマイクロサービスインスタンスを展開します。APIゲートウェイの前にトラフィックをルーティングする このタイプのシステムを設計する場合、どのような選択肢がありますか？

13 microservices