私が働いている会社は、現在のモノリシック API からマイクロサービスへの移行を調査しています。私たちの現在の API は、Spring に大きく依存しており、ほとんどの永続性のために SQL サーバーを使用しています。私たちのマイクロサービスの調査は、spring-cloud、spring-cloud-stream、kafka、および polyglot の永続性 (マイクロサービスごとに分離されたデータベース) に傾いています。
マイクロサービス アーキテクチャで通常、kafka を介したメッセージングがどのように行われるかについて質問があります。一連のマイクロサービスとクライアント アプリケーションの間に調整層を設ける予定です。これにより、さまざまなマイクロサービス間でアクティビティが調整され、マイクロサービス API への変更からクライアントが分離されます。spring-cloud-stream と kafka の使用について読んだことのほとんどは、リソースの変更操作 (挿入、更新、削除) のためにコーディネーション レイヤー (ソース) でストリームを使用する必要があることを示しています。メッセージ。
これで問題が発生したのは挿入です。データベースによって割り当てられた識別子 (ID 列/自動インクリメント列/シーケンス/代理キー) を多用し、通常はポスト リクエストの一部として割り当てられ、呼び出し元に返されます。調整レイヤーは、さまざまなマイクロサービスを使用して複数のものを保存している可能性があり、次の操作に進む前に、1 つの挿入から割り当てられた識別子が必要になることがよくあります。コーディネーション レイヤーとマイクロサービス間のメッセージングを挿入に使用すると、コーディネーション レイヤーが挿入操作からの応答を取得できなくなり、必要な割り当てられた識別子を取得できなくなります。さらに、ストリーム上の他のコンシューマー (つまり、データをデータ ウェアハウスにパブリッシュするコンシューマー) は、割り当てられた識別子をメッセージに含める必要があります。
人々はこの問題にどのように対処していますか? データベース割り当て識別子はマイクロサービスのアンチパターンですか? 非同期挿入を呼び出す前に調整レイヤーが同期呼び出しを行って識別子を取得できるように、データベースが割り当てた識別子を返す個別のマイクロサービス エンドポイントを公開する必要がありますか? UUID を使用することはできますが、DBA はそれらを主キーとして使用することを嫌い、注文番号やその他のユーザー向けの生成 ID として使用することはできませんでした。