マイクロサービス：限定されたコンテキスト間のモデル共有

Question

私は現在、平均スタックで開発されたマイクロサービスベースのアプリケーションを構築しており、境界のあるコンテキスト間でモデルを共有する必要があるいくつかの状況に遭遇しています。

例として、私は登録プロセスとログイン（jwt生成）、ログアウトなどを処理するUserサービスを持っています。プロフィール写真やその他の画像のアップロードを処理するFileサービスもありますアップロードする。さらに、メンバー間の関連付けを追跡するFriendsサービスもあります。

現在、ユーザーサービスで使用されているユーザーテーブルのユーザーのGUIDと、最初の、中間の、最後のフィールドをFileテーブルとFriendテーブルに追加しています。こうすることで、クエリが実行されるたびに情報を取得するために休憩をとることなく、他のサービス（フレンドとファイル）でこれらのフィールドが必要なときにいつでもこれらのフィールドを照会できます。ここで

は警告です：

欠点は、私は、私は、ユーザーがユーザーテーブルから自分の情報を更新するたびにファイルや友人のテーブルを通知し、RabbitMQのでセネカを選択しなければならないことのようです。

1）サービスがあまりにも多くなってしまうのではないかと心配すべきですか？

2）更新が1時間以上かかると、パフォーマンス上の問題が発生する可能性がありますか？

3）境界を切り離そうとして、私はこれを取り除く別の方法を見ていません。この問題を解決するにはどのような方法が推奨されていますか？

Answer 1

これはトレードオフです。私は個人的に、従属サービスにユーザー識別子の横にユーザーの詳細を格納しません。しかし、どちらも、この情報を得るためにユーザーサービスに問い合わせることはありません。おそらく必要なのは、システム全体の読取りモデルのようなもので、特定のニーズに合わせて最適化された方法でこのデータを保存できます（報告、ウェブページ上で一緒に表示するなど）。

読み取りモデルは、イベント駆動アーキテクチャ空間で一般的なパターンです。 microservicesについて

https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-richardson https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-2-richardson

多くの一般的な質問どのようにドメインモデルの分解、そして周りの大部分があるように見える：（2部）の質問のこれらの種類の話は本当に良い記事があります問合せなどの要件が分解に抵抗する状況を克服します。この記事では、オプションを明確に説明しています。間違いなく読む時間が必要です。あなたの特定のケースで

、それはファイルや友人のサービスのみをユーザーのプライマリキーを格納する必要があることを意味します。ただし、すべてのサービスで状態の変更を公開し、その状態を読み取りモデルに集約する必要があります。

Answer 2

あなたは、私が代わりにRabbitMQのを使用してのapacheのカフカまたはNATSを使用することを示唆しているイベントを生産と消費のための一例10万TPSのためのメッセージの高いボリュームと高いTPSを心配している場合（NATSはRubbyバージョンを持っているので、バージョンを行きますまた、毎秒大量のメッセージをサポートするために、

また、データベースの設計については、ドメイン駆動設計（DDD）に応じて各マイクロサービスベースのビジネス機能と有界コンテキストを設計する必要があります。SOAとは異なり、各マイクロサービスには独自のデータベースが必要であることが示唆されているため、マイクロサービスごとに多くの構造、フィールド、表、機能を繰り返す必要があるため、正規化について心配するべきではありません。他を持ち上げて独立に働かせての可用性とのスケーラビリティを持つこと。 microservicesを実装する際に推奨されていません - - あなたのmicroservicesの間でイベントを交換するために

また、あなたは技術やトランザクションログテーリングが2PC（2相コミット）を回避するイベントソーシング+ CQRSを使用することができますCAP定理に従って、最終的な一貫性を持つように状態を操作します。