モノリスをSOAに分割し、参照整合性を分割する
モノリシックRDBMSを備えた大規模なモノリシックアプリケーションを、多くのデータベースを備えたサービス指向アーキテクチャに分割する場合、データの整合性の破壊にどのように対処しますか？
大規模なモノリシックアプリケーションがあります。私のチームは、この一枚岩をドメイン固有のサービスに分割し、サービス指向アーキテクチャーをより多く採用することが有益であることに同意しています。モノリスには、巨大なRDBMSデータベースがあります。チームは、ドメイン固有のテーブルを独自のデータベースに分割することが適切かどうかに関して分かれています。一部の人々は、参照整合性の破壊とそれがもたらすリスクについて懸念しています。ただし、他の人はこのリスクで大丈夫です。
誰かがこの問題の経験があり、いくつかのアドバイスを共有できますか？私の目標の1つは、垂直方向（単一の巨大なDBサーバーを強化する）ではなく、水平方向に拡張する（DBサーバーを追加する）機能を容易にすることです。将来のある時点で、特定のサービスがRDBMSよりもドキュメントSQLデータベース（別名NoSQLデータストア）に適している可能性があることを想像できます。 （したがって、同じデータベースの別のスキーマにテーブルを格納するようなアプローチはおそらく適切ではありません。）
参照整合性は懸念事項であり、ドメイン間に暗黙的な依存関係があることを示唆しています。マイクロサービスのクールエイドをよく飲んだ人が誤解していると私が思うことの1つは、モノリスを分解すると、これらの種類の依存関係とそれに関連する問題が魔法のように消えないということです。人々が懸念していることは良いことであり、あなたがこの道に専念しているなら、あなたはそれらの懸念に確実に対処したいと思うでしょう。
ビジネスの観点から2つ以上のドメイン間に本当に密結合がある場合、それらを本当に個別のDBに分離する必要があるかどうかを検討する必要があります。トラブルに値するものではないかもしれません。
2つのエンティティ間の整合性を維持する必要がある場合は、いくつかの方法が役立ちます。
- 常に代理キーを使用してください。意味のないキーを変更する理由はないはずです。キーが決して変更されない場合は、RIの問題が大量に発生するのを回避できます。
- キーを削除せず、代わりに「ソフト」削除を使用してください。行を追加するだけで、それらを更新しないことも役立ちます。少なくとも、それらがリンクされたときに何が何を意味していたかがわかります。
データベースを他のサービスと共有することについては慎重に考えます。データベースを変更するたびに、その変更がそのデータベースを使用する他のサービスに影響を与えないことを確認する方法について説明します。リリースが可能かどうかを確認するためにすべてのサービスに対してテストが実行される、モノリシックリリースの実行に戻ります。データベースの変更によりチーム間の通信が必要になり、開発が遅くなり、スケジューリングなどの問題が発生するため、サービスが別のチームによって所有されている場合、これはさらに悪化します。
SOAおよびマイクロサービスの利点の1つは、リリース間で比較的安定したAPIレベルに境界があることです。これにより、システム全体をテストする必要なく、マイクロサービスを個別にリリースできます。サービスごとにデータベースを分けることで、このタイプの開発を進めることができます。
参照整合性に関しては、ドメインによって異なります。参照整合性があなたのビジネスにとってミッションクリティカルである場合、モノリシックを分割するために、より細かい場所を見つけることを提案するかもしれません。たとえば、コアドメインエンティティのすべてのドメインロジックと関係を表す1つのサービスがあるとします。その後、メールサービスや認証サービスなどのサポートサービスを利用する場合があります。ドメインサービスは「マイクロ」ではない場合がありますが、参照整合性が重要な場合は、サービス設計を細かくしてリスクを冒さないでください。
参照整合性を緩和して、最終的に一貫性のある/アプリケーションが維持されるようにすると、まったく新しい世界が開かれます。特定のドメインの概念/エンティティの記録システムであるサービスを用意し、システムの他の部分での高速クエリのためにデータを非正規化できます。このデータの共有は伝播に時間がかかりますが、ほとんどのドメインでは問題ありません。この最終的に一貫性のあるデータに対して検証を表示または実行してもよいかどうかを判断する必要があります。
検証および実行するために複数のサービスに移動して実行する必要があるビジネスルールがある場合、ドメインよりもSOAに適した選択肢ではない可能性があります。代わりに、ビジネスがワークフローを表し、各サービスがより大きなビジネスフローのいくつかのステップを実行する場合、これははるかに優れたユースケースになります。モノリスを分割するのに最適な場所は、制限されたコンテキストにあることがわかりました。これらのサービスは依然としてかなり大きなものになることがありますが、それがドメインのモデル化方法です。モノリスでいくつかの結合を必要とするクエリを処理したりデータ操作を実行したりするために多数のネットワーク要求を生成するため、細かくしすぎると苦痛を伴います。また、別のサービスにレコードが存在することを検証するための呼び出しを行って、呼び出しが完了した直後にレコードを削除することができるため、参照整合性はなくなります。
編集：
レコード間の結果の一貫性を維持する1つの方法は、孤立したレコードを探すか、レコード同士をリンクするプロセスを持つことです。ユーザーがUIでこれらの孤立したレコードをクリーンアップしてアクションを実行できる場所を提供できます。クエリ時に問題を検出し、ユーザーに知らせて問題の修正を許可することができます。
サービスが最終的に整合性のあるデータを共有するためのメカニズムとして、rabbitmqやKafkaなどのツールを使用できます。
例として、サービスにユーザーサービスからのユーザーのフルネームの最終的に整合性のあるストアがあり、フルネームを表示するためにユーザーサービスに定期的にクエリする必要がないようにする場合があります。最終的に整合性のあるストアを構築するために、ユーザーサービスからkafkaを介して送信されるイベントをリッスンする場合があります。データの重複を犠牲にして、フルネームルックアップが私のサービスで高速になりました。
ここでの整合性は、ユーザーのフルネームが頻繁に変更されることはないため、強力です。キュー/カフカが遅れている可能性があるため、大幅に変更される他のデータセットは整合性が低くなる可能性があります。
レコードを所有する各サービスは、そのレコードの整合性に責任があります。他のレコードとの関係はより柔軟でなければなりません。別のサービスからのレコードのコンシューマーサービスとして、レコードの現在の状態に対する最終決定権を持つため、所有サービス内のレコードに発生する変更をリッスンして適応する必要があります。
まず、モノリスを分割する方法は明らかに複数あります。対応するエンティティにミッションクリティカルな制約があり、最終的に異なるサービスになる場合は、 誤ったサービス境界を識別 になります。
サービスに持たせたい特定の特性があります。どうやらあなたのサービスは低い結合を持つべきです。モノリスを分散モノリスにしたくない。一部のサービスにバグがあるため、システム全体がダウンしたくない場合。サービスの結束力を高めたい場合：ソースコードに密接に関連する変更を加える必要がある場合は、すべてのコードを1か所に配置する必要があります。これら2つはおそらく最も重要な特性です。 残りすべて はそれらから結論付けることができます。それらは、高度なサービスの自律性、イベントを介した通信、オーケストレーションの代わりに分散データとサービスの振り付けです。
まあ、それはいいことだと思いますが、 具体的な手順は何ですか ？ついに私が来たのは以下です。私のシステムに備わっているビジネス機能を定義します。基本的には、より高いレベルの責任です。ただし、組織構造とビジネス機能を混同しないでください。理想的には、それらは一致しますが、これは多くの場合そうではありません。だからあなたのより高いレベルのビジネス能力を書き留めてください。それらの約5-7があります。 10以下だと思います。次に、それらのそれぞれをより深く掘り下げます。それらはどのような疎結合の責任で構成されていますか？そのときはプログラミングについて考えないでください。問題の空間を分解するだけです。最終的に得られるビジネス機能はドメインを反映するため、本質的に疎結合になります。制約に違反することはありません。その分解に役立つメタファーがあります。私は、私の現在のドメインが100年前のように見えた（または見えたように見える）ことを思い起こさせます。本当にミッションクリティカルな制約とは何ですか？ドメインの誤解の結果、どのような制約がありますか？私はあなたのドメインはあなたが思っているよりも最終的には一貫性があるように思えます。
この機能分解が完了したら、この結果をソリューションスペースにマッピングできます。問題空間の機能に対応するソリューション空間エンティティを「ビジネスサービス」と呼びます。これは、ビジネス機能が存在する論理的な境界です。ビジネスルール、ビジネスプロセス、それらに関与し、特定の決定を行う人々、これらの人々が使用するアプリケーション、および人々に作用するビジネスデータがあります。
その後、最終的に自動化するものを決定します。したがって、技術的なSOAサービスは、ビジネスサービスと1対1の関係になります。
ここに例があります 私が書いたものの。
したがって、このアプローチに従うと、データの整合性が失われるなどの問題はありません。
お役に立てば幸いです。