データベースの主キーを使用して、マイクロサービス全体のエンティティを識別する必要がありますか？

Dec 12 2020

サービスAとサービスBの2つのマイクロサービスがあるとします。

サービスAは完全な顧客データを所有しており、サービスBはこのデータの小さなサブセットを必要とします（たとえば、サービスAからバルクロードを介して取得します）。

どちらのサービスも、顧客を独自のデータベースに保存します。

次に、サービスBがサービスAと対話して、追加のデータ（GET / Customers / {id}など）を取得する必要がある場合、2つのサービス間で共有される一意の識別子が明らかに必要です。

IDはGUIDであるため、サービスBでレコードを作成するときに、サービスAのPKを使用するだけで済みます。したがって、両方のPKが一致します。

しかし、これは非常に壊れやすいように聞こえます。1つのオプションは、「外部ID」（または「ソースID」）をサービスBの個別のフィールドとして格納し、それを使用してサービスAと対話することです。おそらくこれは文字列であり、ある日はGUIDではない可能性があります。

これに関する「ベストプラクティス」はありますか？

更新

だから私はさらにいくつかの調査を行い、いくつかの関連する議論を見つけました：

REST API URLで主キーを公開する必要がありますか？

REST APIでデータベースIDをクライアントに公開するのは悪い習慣ですか？

主キーとしてのナメクジ

結論

サービスAとサービスBで両方の顧客の主キーを同じに保とうとするという私の考えは間違っていたと思います。それの訳は：

明らかにPKはサービス実装固有であるため、UUIDと自動インクリメントINTなどの完全な互換性がない可能性があります。
互換性を保証できる場合でも、2つのエンティティは両方とも「顧客」と呼ばれますが、事実上2つの（潜在的に非常に異なる）概念であり、サービスAとサービスBの両方が独自の「顧客」レコードを所有しています。ただし、これらのサービス間で一部の顧客データを同期することをお勧めします。

したがって、どちらのサービスも独自の一意のID（私の場合はPK GUID）を介して顧客データを公開でき、あるサービスが別のサービスから追加の顧客データを取得する必要がある場合は、他のサービス識別子/キーを保存してそれを使用する必要があると思います。つまり、基本的には「外部ID」または「ソースID」のアイデアに戻りますが、おそらく「サービスBID」としてより具体的になります。

回答

1 AnkitVijay Dec 13 2020 at 04:57

データソースとデザインに少し依存すると思います。ただし、共有を避けたいのは、外部サービスへのGUIDまたは自動インクリメント整数である主キーです。これらはサービスの内部詳細であり、他のサービスが依存する必要があるものではありません。

私はむしろ、他のサービスやおそらくビジネス全体によってより理解される外部IDを持っていると思います。ではなく、一意の顧客番号、注文番号、またはポリシー番号にすることができますid。それらを「ビジネスID」と見なすこともできます。また、外部IDもエンドユーザーに公開される可能性があることにも注意してください。したがって、これは、イベント駆動型設計を使用しているかどうか、またはサービスがAPIを介して通信するかどうかに関係なく、組織およびサービス全体でその「エンティティ」を識別するユビキタスな方法です。DBIDはインフラストラクチャまたはリポジトリにのみ公開します。それを超えて、それはビジネス/外部IDだけです。