MicroServicesのデータベースアクセスの管理
現在、Monolithをマイクロサービスに分割する作業ストリームがあり、データへのアクセスと永続化の方法については議論があります。
ほとんどのアプリがどのように設定されているかをよく理解するために、UIに厳密に構築されたアプリ、それが通信するWeb API、次にそのAPIがデータベースへのアクセスを管理するために通信する別のWeb APIがあります。
データベースへのアクセスを管理するために使用するWeb APIがあることは間違いなく魅力的ですが、各アプリに固有のエンドポイントを構築する必要があり、ほとんどの場合、UIアプリが単にプロキシ。
また、実際の設計パターンはありません。WebAPIをプロキシとして使用するだけですか、それともデータレイヤーAPIに複数のエンドポイントを設定し、それらすべてを使用して独自のDTOを作成しますか？
これはC＃プロジェクトであり、通常はEntity Frameworkを使用しているので、私にとっては、データベースファーストアプローチを使用してWeb APIでエンティティを生成する方が理にかなっているようです。この方法では、複数のプロジェクトでの移行を管理していません。
私たちのデータベースを複数のデータベースに分離するのは、ゲームでは遅すぎるようです。
一般に、モノリスをマイクロサービスアーキテクチャに移行するプロセスでは、モノリスからパーツを慎重に抽出して、スタンドアロンアプリケーションとして機能できるようにします。たとえば、ホテルの予約システムについて考えてみましょう。部屋を割り当てるレンタルサブシステム、顧客に関するデータを永続化するプロファイルサブシステム、請求サブシステムなどがあります。1。これが私たちの出発点です。
モノリスはおそらく1か月または数年にわたって有機的に進化し、すべてのサブシステムは希望どおりに分離されていません。マイクロサービスの観点からは、これは悪いことです。私たちの最初のステップは、これらのサブシステムの1つ（通常、最もリスクの少ないもの）を取り、それを再構築することですmonolithの内部完全に分離されるようにします。この例では、これはおそらくプロファイルサブシステムである可能性があります。
顧客データへのデータアクセスは、コードの至る所に分散しています。最初のタスクは、このサブシステムを分離することです。コードを別のライブラリに移動して、他のサブシステムが顧客に関するデータを要求するためのインターフェースを公開します。これは非常に重要です。他のサブシステムがデータベースに顧客データについて直接尋ねることはできません。彼らはhaveサービスにこの情報を要求します。
このステップが完了すると2、サブシステムは独自のサービスに移動して自分で生活する準備ができています。モノリスの残りの部分では、ライブラリを使用して顧客データにアクセスする代わりに、新しいスタンドアロンプロファイルサービスを呼び出します。３。最初のマイクロサービスがあります4。
私たちは2つの非常に重要なことを達成しました：
- マイクロサービスにはhigh cohesionがあります。顧客データに関連するすべてのものは、独自のマイクロサービスに分離されています。顧客データの永続化方法、および顧客のビジネスルールの適用方法に対するすべての変更は、単一のサービスにスコープされます。
- 新しいマイクロサービスと残りのコードの間には低結合があります。顧客データの永続化方法を変更しても、レンタルサブシステムはまったく影響を受けません。これは良いことです。これは気にする必要がなく、レンタルのみを気にします。
ユースケースに戻ると、私はあなたがあなたの道を逆に進んでいるように思えます。モノリスの前に「マイクロサービス」を構築して呼び出しをプロキシすることにより、2つの重要な問題が発生しました。
- システムのまとまりを軽減しました。新しい機能では、APIを変更するためにプロキシサービスを変更する必要があり、次にこの新しいAPIをサポートするためにモノリスを変更する必要があります。
- すべての機能で両方を変更する必要があるため、2つのサービス間の結合を増やしました。
マイクロサービスアーキテクチャのメリットは得られませんが、システム全体の複雑さが増します。あなたのモノリスはまだ大きいだけであり、テストスイート全体を実行し、すべてのバグ修正または機能のQAを行うには依然としてコストがかかり、希望するほど速く進めることはできません。
1.ドメイン主導の設計では、これらのサブシステムは確かに境界付きコンテキストになります。
2.サブシステムを別のサービスにすぐに抽出することはできますが、パブリックインターフェイスがいくつかの機能によって安定するまで待つことをお勧めします。新しいマイクロサービスに抽出されたら、境界を正しく配置していないために間違いを修正するのにコストがかかる可能性があります。
3.これは、実際にすべてのサービスに同じDBMSのインスタンスを使用している場合でも、サービスAのデータベース結合しないでくださいがサービスBのデータベースにあることを意味します。たとえば、 customerテーブルとrentalテーブルがあり、rentalに外部キーcustomer.idがある場合、この外部キーを削除してこの参照整合性を失います DBMSによって強制されます。別の方法で一貫性を確保する必要があります。マイクロサービスアーキテクチャで支払う代償です。
4.明らかに、私はこの回答からインフラストラクチャの複雑さの多くを省略しました。マイクロサービスを実行することは簡単なことではありません。実際にユースケースに適していることを確認してください！