共通ユーザテーブルを持つマイクロサービス

Question

各マイクロサービスが個別の独立したデータベースと共通ユーザテーブルを持つマイクロサービスベースのアーキテクチャを設計することは可能ですか？

Answer 1

マイクロサービス間でデータベースまたはテーブルを共有することは推奨されません。彼らははっきりとした明確な責任を持っていて、ネットワークを使ってのみコミュニケーションをとるべきです。プロトコルは、マイクロサービス内で使用される技術を隠す必要があります。たとえば、要求/応答にJSONを使用できます。

マイクロサービスは、他のマイクロサービスの技術に依存してはならないという理由から、マイクロサービスは他のテクノロジスタックを使用するが同じ目的を果たす他のマイクロサービスと簡単に置き換えられるべきです。あなたが別で1 microserviceからのデータが必要な場合は

あなたが作ることができます。

• 同期呼び出し：これは実装が簡単ですが、失敗に

• 非同期呼び出しをカスケード接続する余地がある。困難を実装しますより弾力のあるシステムに導く

Answer 2

ユーザーdetaに関連するすべてのロジックをカプセル化する追加のマイクロサービスを作成することを検討してくださいILS：

• にのみ、このサービスは
• 他のサービスがそのサービスに要求を行うと、ユーザーテーブルについて何も知らないはずのデータを修正/読み取るために、ユーザーテーブルへのアクセス権を持っているし、エンドポイントを提供する必要があります

---

私はRESTベースのマイクロサービスを経験しています（私の答えのこの部分は主に意見に基づいています）。ここではほとんどの場合、データの読み取り/変更が必要な場合に直接HTTPリクエストを使用してサービスします。私たちは、そのサービスは、データの変更についてのさまざまなコンポーネントに通知したいときや、私たちはキューベースのメッセージ通信（パブリッシュ・サブスクライブ・パターン）を使用します。

• サービスを、それがデータの所有者である、キューに変更イベントに関するメッセージを送信します。
• 他のサービスはそのキューに登録し、新しいメッセージが到着したときに処理を行います。
• ご覧のとおり、通信は非同期になります。

単純なメッセージブロードキャストよりもメッセージキューのメリットの1つは、自動的に再試行（および障害発生時に再試行）するメカニズムをサポートすることです。

Answer 3

マイクロサービス - サービスと同様に、できるだけ自律的でなければなりません。データベーステーブルを共有することは、サービスが可用性に結びついていることを意味し、より重要なのは、相互の内部構造を妨げることです。

これは、単一のサービスを複数の実行可能ファイルに分割して、開発スピード、テクノロジの適合性、または他の理由に関連する利点を得ることが理にかなっていることがあります。私はこれらをaspectsと呼んでいます（同じサービスの異なる点のように）。

サービスの境界を理解する（そして尊重する）のは依然として非常に重要です。そうでなければ分散した混乱を招くことがありますが、境界を特定すると、サービスを作るいくつかのコンポーネント（側面）を構築することもできます。例えば、私は今日、私たちは着信データの処理（リアルタイムでのストリーミング）とそのデータ（グラフベースのクエリ）を消費するための全く異なる要件を持つサービスを持っています。最初のアスペクトはScalaで実装され、高度に分散されており、後者はnode.js（express-graphqlのようなフレンドリーなライブラリを使用するため）で実装されています。両方のアスペクトが同じDBを使用しますが、DBはシステム内の他のサービス