マイクロサービスとデータ複製

私は新しいアプリケーションを構築しており、マイクロサービスアーキテクチャについて読んでいました。アーキテクチャ自体は、開発、展開、ライフサイクル管理の観点から非常に理にかなっています。しかし、出てきた問題の1つは、マスターデータの処理方法に関するものでした。

たとえば、2つのアプリがあります。たとえば、SalesアプリとTicketingアプリです。これらのアプリは両方とも独自のマイクロサービスとして構築されていると仮定します。ただし、これらのアプリの両方をデプロイする場合（セールスがMongoDBを使用し、チケットがMariaDBを使用すると言う場合）、別々にデプロイすると、アカウント、製品などの同じマスターデータインスタンスにアクセスする必要があります。これは、特定のマスターデータエンティティの所有者アプリ（例：アカウントの場合は販売アプリ）と関係者（例：発券アプリにはアカウントに関する情報が必要）があることを意味します。

これを実現する方法は複数あります。-マスターから関係者へのデータ複製-関係者からマスターへの同期読み取り（同期依存関係はマイクロサービスアーキテクチャパラダイムでは推奨されません）-独自の中央リポジトリ

また、アカウント内でも、販売と発券の両方に共通のコア部分（アカウント名、住所など）が存在する場合があります。ただし、アカウントの一部の側面は販売にのみ関連し、他の側面はチケットにのみ関連する場合があります。

上記のオプションのいずれかに関する考え/ベストプラクティス/意見はありますか？

私は、サービスバスを使用してマイクロサービスアーキテクチャの構築に成功したチームの一員でした。

当初、マイクロサービスとイベント駆動型アーキテクチャにより、基盤となる共有データの泥沼データベースを修正できると考えていました。

私たちが学んだことは、マイクロサービスとイベント駆動型アーキテクチャでは、基盤となる共有データの泥沼データベースを取り除く必要があるということです。

共有データはマイクロサービスでうまく機能するのは信じられないほど難しいと思います-私にとっては非常に難しいです。サービスが互いのデータを参照できないようにすることをお勧めします。クエリできない場合、誤って依存関係を導入することはできません。

あなたがいる場合行う共有データを、確かに一つだけのサービスでは、これまでの記録を所有することができます。レコードに書き込む唯一のサービスであり、同じデータの他のユーザーには読み取り専用アクセス権が必要です。

残念ながら、このわずかな量の管理された共有でも、サービス間に大きなカップリングが生じます。1つのサービスがその形状のデータを必要としない場合はどうなりますか？おそらく集約が必要です。「所有者/書き込み」サービスを取得して、別のサービスのために集計データを書き込みますか？私はお勧めしません。

所有者がデータを別の形で保持したい場合はどうなりますか？次に、すべてのリーダーサービスを更新する必要があります。それはメンテナンスの悪夢です。

最善の解決策は、データの大幅な重複と非正規化でした。マイクロサービスは、管理対象のデータの独自のコピーを保持していました。

多くの場合、メッセージは、それらを処理するのに十分なデータとともに公開されていました。

たとえば、郵便物発送サービスが何かを投稿する必要がある場合に備えて、顧客の住所の変更を追跡する必要があるかもしれないと想像するかもしれません。ただし、「発送準備完了アイテム」メッセージにメッセージデータの一部として宛先アドレスが含まれている場合、発送サービスは顧客に関連する住所の変更を追跡する必要がなくなります。発送されたアイテムに関連する特定の時点のアドレスのみ。

同期データを使用してソリューションを設計する方法を提案することはできません。当社のデータソリューションは、「結果整合性」の概念に基づいて構築されました。

したがって、顧客が住所を更新すると、住所サービスはUIからの初期コマンドを処理します。データが正しい場合、イベントを発行して、他のすべての関連サービスに「Customer Address Updated」を通知します。完全な住所がデータとして添付されます。これらのサービスは、関心のあるデータの部分で独自のデータストアを更新します。

サービスが重要なアクションを実行する必要があるときはいつでも、適切に機能し、独立して追跡されるか、または応答するメッセージの一部として機能するのに十分な情報のコピーが必要です。

共有データストレージは、マイクロサービスアーキテクチャに反します。重要なのは、アカウントがある場合、それらを処理するサービスが必要であり、これらのアカウントとやり取りする他の方法は、サービス全体である必要があるということです。共通のストレージを共有し、ストレージメカニズムの変更、検証、またはその他の制約を両方のサービスに実装する必要がある場合、マイクロサービスは独立していません。実際には、これは決して起こらず、すぐに両方のアプリケーションが重大な変更から保護されます。

そのため、アカウントなど、データにアクセスする唯一の方法としてサービスを使用してください。他のサービスに機能を実装するには、アカウントサービスの変更が必要になる場合がありますが、それで問題ありません。サービスに固有のロジックはそのサービス内に存在する必要があり、アカウントのマイクロサービスにはできるだけ具体的なものは含めないでください。

アカウント、製品など、同じマスターデータインスタンスにアクセスする必要があります。

同じではありません。各マイクロサービスは、アカウント、製品などに対して独自のマッピングを行う必要があります。各マイクロサービスには、エンティティを操作するための異なる方法があると想定しています。

ドメインドリブンデザインでは、これは一般的であり、（同じアプリ内の）各境界コンテキストが同じエンティティを異なる方法でマップできます。

さらに情報が必要な場合は、「Building Microservices：Designing Fine-Grained Systems」という本をお勧めします

マスターセットに基づくスケルトンレコードの概念を検討しましたか？

たとえば、1つのマイクロサービスがアカウントを処理し、もう1つのマイクロサービスが製品を処理します。3番目は、ドメイン固有の目的のために両方のレコードを保持する場合があります。