マイクロサービスとデータ複製
新しいアプリケーションを構築していて、マイクロサービスアーキテクチャについて読んでいました。アーキテクチャー自体は、開発、デプロイメント、およびライフサイクル管理の観点から多くの意味があります。しかし、浮かび上がってきたのは、マスターデータの扱い方です。
たとえば、私には2つのアプリがあります。たとえば、販売アプリと発券アプリです。これらのアプリの両方が独自のマイクロサービスとして構築されていると仮定します。ただし、これらのアプリは両方とも、デプロイされると（セールスがMongoDBを使用し、チケッティングがMariaDBを使用すると仮定して）、同じマスターデータインスタンスにアクセスする必要があります。アカウント、製品。これは、特定のマスターデータエンティティの所有者アプリ（たとえば、アカウントの場合、営業アプリの場合があります）と関係者（たとえば、チケットアプリはアカウントに関する情報を持っている必要がある）があることを意味します。
これを実現する方法は複数あります。-マスターから関係者へのデータ複製-関係者からマスターへの同期読み取り（同期の依存関係はマイクロサービスアーキテクチャパラダイムでは推奨されません）-独自の集中リポジトリ
また、アカウント内でも、セールスとチケットの両方に共通するコアパーツ（アカウント名、住所など）が存在する場合があります。ただし、アカウントの一部の側面は販売にのみ関連し、他の側面は発券にのみ関連する場合があります。
上記のオプションについて、考え/ベストプラクティス/意見はありますか？
私はサービスバスを使用してマイクロサービスアーキテクチャを正常に構築したチームの一員でした。
最初は、マイクロサービスとイベント駆動型アーキテクチャがenableを使用して、基になる共有データの泥のデータベースを修正すると考えていました。
私たちが学んだのは、マイクロサービスとイベント駆動型アーキテクチャ必須基になる共有データの泥のデータベースを取り除くためです。
共有データをマイクロサービスでうまく処理するのは信じられないほど難しいと私は信じています-私にとってそれは法外に難しいです。サービスにseeお互いのデータを許可しないことをお勧めします。クエリできない場合は、誤って依存関係を導入することはできません。
doデータを共有する場合、確かに1つのサービスだけがレコードを所有できます。これは、レコードに書き込む唯一のサービスであり、同じデータの他のユーザーには読み取り専用アクセス権が必要です。
残念ながら、このように管理された少量の共有でさえ、サービス間で重要な結合が生じます。 1つのサービスがその形のデータを必要としない場合はどうなりますか？おそらく、それは集約を必要としています。 「所有者/書き込み」サービスに、別のサービスのために集計データを書き込むようにしていますか？私は勧めません。
所有者がデータを別の形で保持したい場合はどうなりますか？次に、すべてのリーダーサービスを更新する必要があります。それはメンテナンスの悪夢です。
私たちが行った最善の解決策は、データの大幅な重複と非正規化でした。マイクロサービスは、自分が気にかけたデータの独自のコピーを維持していました。
メッセージはしばしば、それらを処理するのに十分な付随データとともに公開されました。
たとえば、郵送サービスが何かを投稿する必要がある場合に備えて、顧客の住所への変更を追跡する必要があると想像するかもしれません。ただし、「発送準備完了」メッセージにメッセージデータの一部として宛先アドレスが含まれている場合、発送サービスは顧客に関連する変化する住所を追跡する必要がなくなります。発送されたアイテムに関連する特定の時点のアドレス。
同期されたデータでソリューションを構築する方法を提案することはできません。当社のデータソリューションは、「結果整合性」の考え方に基づいて構築されました。
したがって、顧客が住所を更新すると、アドレスサービスはUIからの最初のコマンドを処理します。データが正しい場合、イベントを発行して、他のすべての関連サービスに「Customer Address Updated」と通知し、完全な住所をデータとして添付します。これらのサービスは、関心のあるデータの部分で独自のデータストアを更新します。
アイデアは、サービスが重要なアクションを実行する必要があるときはいつでも、正しく動作するのに十分な最新の情報のコピーを持っている必要があるということです。
共有データストレージは、マイクロサービスアーキテクチャに反します。重要なのは、アカウントがある場合、それらを処理するためのサービスがあり、サービスを介してこれらのアカウントと対話する他の方法がないはずです。マイクロサービスが共通のストレージを共有していて、ストレージメカニズムの変更、検証、またはその他の制約を両方のサービスに実装する必要がある場合、マイクロサービスは独立していません。実際には、これは発生せず、すぐに両方のアプリケーションが重大な変更から保護されるようになります。
したがって、データにアクセスする唯一の方法としてサービスを使用してください。アカウント。他のサービスに機能を実装するには、アカウントサービスの変更が必要になる場合がありますが、これは問題ありません。サービスに固有のロジックはそのサービス内にある必要があり、できるだけ具体的なものはアカウントマイクロサービスに入らないことを覚えておいてください。
マスターセットに基づくスケルトンレコードのコンセプトを検討しましたか？
たとえば、1つのマイクロサービスがアカウントを処理し、もう1つのマイクロサービスが製品を処理します。 3番目は、ドメイン固有の目的で両方のレコードを保持する場合があります。
同じマスターデータインスタンスにアクセスできる必要があります。アカウント、製品
同じではありません。各マイクロサービスは、アカウント、製品などに対して独自のマッピングを行う必要があります。各マイクロサービスは、エンティティを操作する方法が異なると想定しています。
ドメイン駆動設計ではこれが一般的であり、（同じアプリ内の）境界のある各コンテキストが同じエンティティを異なる方法でマップできます。
詳細については、本 Building Microservices：Designing Fine-Grained Systems をお勧めします。