私は、マイクロサービス システムの有用なアーキテクチャとして EventSource を使用する CQRS に関するドキュメント、ブログ投稿、および例をたくさん読みました。
一般的な例は、銀行振込アプリです。
4 つのマイクロサービスがあることは明らかですが、「コマンド側」のマイクロサービスには独自のデータベースがないため、わかりません。
この画像では、すべてのマイクロサービスが同じ eventStore データベースを使用していますが、これはマイクロサービス パターンに反しているのでしょうか?
そして、EventStore db はどのようにすべきでしょうか? シングルテーブル？サービスごとに 1 つのテーブル ?
ほとんどの決定はトレードオフに関するものであり、これも例外ではありません。マイクロサービスの通常の定義では、@ thiago-custodio が言及している理由から、各サービスには独自のデータベースがあります。サービスを完全に分離してカプセル化します。ただし、これにより、管理するデータベースが N 個になるため、ビジネスの運用面により多くの負担がかかります。また、解決すべき新しい「すべてのものはどのように相互に通信するのか」という問題もあります。これはあなたにとって問題になる場合とそうでない場合があります。
データベースを共有することで、サービスの分離とカプセル化の利点の一部を得ることができますが、たとえば、サービスごとに個別のスキーマを持つことができます。データベース レベルである程度の分離が得られますが、運用の複雑さが軽減されます。繰り返しますが、トレードオフです。
単一のイベント ストア/メッセージ キューの使用は、多数のサービス間の通信を可能にする方法として許容できるトレードオフであると考えています。
4 つのマイクロサービスがあることは明らかです。
必ずしも図を文脈から外して見るだけではありません。イベント ストアにイベントを書き込む 2 つのコントローラーと、クエリを返すコントローラーがあります。これは、マイクロサービスではなく CQRS を説明するための図のように見えます。CQRS は最上位のアーキテクチャではありません。マイクロサービス内に適用します。
しかし、「コマンド側」のマイクロサービスには独自のデータベースがないため、わかりません。
イベント ストアはデータベースです。クエリ側には、クエリ用に最適化される別のデータベースがあります。
コメントを明確にするために、より大きなスペースが必要だと判断した
4 つのマイクロサービスがあることは明らかです。
それはまったく明らかではないと思います。
この特定の画像は https://github.com/cer/event-sourcing-examplesからのものです
概要の中で、Richardson は次のように書いています。
One of the neat things about the modular architecture is
that there are two ways to deploy these four services:
monolithic-service - all services are packaged as a single Spring Boot executable JAR
Microservices - three separate Spring Boot executable JARs
accounts-command-side-service - command-side accounts
transactions-command-side-service - command-side money transfers
accounts-query-side-service - Account View Updater and Account View Reader
Scala By the Bay でプレゼンテーションを行った彼は、1 つのマイクロサービスがイベント ストアにパブリッシュし、2 つ目のマイクロサービスがそれらのイベントをサブスクライブしてビュー ストアを更新するパターンを指摘しました。
したがって、これを 1 つ、2 つ、3 つ、または 4 つのマイクロサービスとして数えることについて、公正な議論を行うことができると思います。
カウントする際に考慮すべきことの 1 つは、イベント内に含まれる状態情報を理解してビュー (アカウント ビュービュー ストアからデータをコピーするだけなので、読者はこの共有された理解を必要としません)。
Udi Dahanは、サービスの境界について興味深いことを述べています。特に、サービスが公に共有するデータの量を制限することで、サービス間の疎結合を維持する必要があります。
彼のガイドラインをこのダイアグラムに当てはめると、アカウント ビューと 2 つの集計は同じ境界の一部でなければならないことがわかります。これらはすべて、このサービスのプライベートなデータにアクセスできるからです。
もちろん、イベント スキーマに対する下位互換性のある変更を慎重に保持する場合は、これら 4 つのサービス コンポーネントを個別に設計することもできます。
4 つのマイクロサービスがあることは明らかですが、「コマンド側」のマイクロサービスには独自のデータベースがないため、わかりません。
これら 2 つのマイクロサービスは、たまたま同じ物理ストアである別個の論理イベント ストアを持つと見なすことができます。これらの論理ストアの 1 つを移行する必要があると判断した場合、頭痛の種になる可能性がありますが、集約イベント ストリームは互いに分離されているため、アカウントと転送の間の結合についてあまり心配する必要はありません。
そして、EventStore db はどのようにすべきでしょうか? シングルテーブル？サービスごとに 1 つのテーブル ?
イベント ストアの典型的なリレーショナル スキーマは、イベント自体を BLOB として扱い、他のテーブルと結合できるように、一部のメタ データ (たとえば、eventId) を公開します。したがって、ジェネリック ストアはおそらく、イベントを保持する 1 つのテーブルと、イベント ストリームを保持する別のテーブルのように見えます。イベント ソーシングを使用する場合のイベントの格納におけるリレーショナル スキーマの説明へのリンクがいくつかあります。
スキーマを複数の物理テーブルに分割/分割したい場合は、それも可能です。
使用できる非リレーショナル ストアもあります。Event Store (オープン ソース)の詳細を調べると、ストアの実装方法について多くを学ぶことができます。
または、単にブラック ボックスとして扱うこともできます。
私の意見では、またマイクロサービス アーキテクチャについてこれまで読んだことによると、各サービスが独自の永続化メカニズムを持つという考え方は、必要に応じてコンシューマに影響を与えることなく完全に書き換えられる独立したサービスを作成することです。(クライアントの要求/応答契約を維持する限り)。
これが分散型データ管理です。 同じデータベースを使用してマイクロサービスを作成しても、それは達成できません。
さらに読むには：