大量の入力データが必要な場合に、ルールエンジンをマイクロサービスアーキテクチャに適合させるにはどうすればよいですか？
現在の状況
マイクロサービスアーキテクチャでオンラインショッピングWebアプリケーションを実装（および現在維持）しています。
要件の1つは、顧客のエクスペリエンスと最終的な注文をカスタマイズするために、顧客がカートに追加するものにルールを適用できる必要があることです。当然のことながら、ビジネスルールエンジンを導入する必要があり、このために特定の「マイクロサービス」を実装しました（まだ呼び出すことができる場合）。
1年の間に、このルールエンジンはますます複雑になり、より多くのデータ（カートのコンテンツだけでなく、ユーザー情報、役割、既存のサービス、請求情報など）を必要としていますそれらのルールを計算します。
現時点では、shopping-cartマイクロサービスが他のマイクロサービスからこのすべてのデータを収集しています。このデータの一部はshopping-cartによって使用されますが、ほとんどの場合、主にルールエンジンへのフィードに使用されます。
新しい要件
同様の要件でルールエンジンを再利用するために、他のアプリケーション/マイクロサービスが必要になりました。したがって、現在の状況では、同じ種類のデータを送信し、同じマイクロサービスを呼び出し、ルールエンジンを呼び出すことができるように（ほぼ）同じリソースを構築する必要があります。
そのまま続けると、いくつかの問題に直面します。
- （ルールエンジンを呼び出す）全員が、データを取得する必要がない場合でも、データのフェッチを再実装する必要があります。
- ルールエンジンへの要求は複雑です。
- この方向に進むと、多くのリクエストのためにこのデータをネットワーク全体に転送する必要があります（μsAがμsBを呼び出してルールエンジンを呼び出していると考えてください。ただし、Aはすでにルールエンジンが必要とするデータの一部を持っています）。
shopping-cartは、すべてのデータのフェッチにより巨大になりました。- たぶんたくさん忘れて…
これらのトラブルを回避するために私たちは何ができますか？
理想的には、ルールエンジンをさらに複雑にすることは避けます。また、ボトルネックにならないことを確認する必要があります。たとえば、一部のデータのフェッチがかなり遅い（10秒以上）ので、shopping-cartにプリフェッチを実装して、データが存在する可能性を高めましたルールエンジンを呼び出す前に、許容できるユーザーエクスペリエンスを維持します。
いくつかのアイデア
- ルールエンジンに必要なデータをフェッチさせます。これはさらに複雑になり、単一責任の原則に違反します（さらに...）;
- データを取得するルールエンジンの前にプロキシμsを実装します。
- ルールエンジンが必要なすべてのデータを一度にフェッチするために呼び出す「データフェッチャー」μsを実装します（複合照会）。
ちょっと一歩戻って、この新しい長さになる可能性のある答えを書く前に、開始場所を評価してみましょう。あなたが持っている：
- 大きなモノリス（ルールエンジン）
- 大量に送信されるモジュール化されていない大量のデータ
- ルールエンジンとの間でデータを取得するのは難しい
- ルールエンジンは削除できません
わかりました、これはマイクロサービスにそれほど適していません。差し迫った問題は、マイクロサービスとは何かを誤解しているように見えることです。
（ルールエンジンを呼び出す）全員が、データを取得する必要がない場合でも、データのフェッチを再実装する必要があります。
マイクロサービスが使用する何らかのAPIまたは通信方法を定義し、それを共通にする必要があります。これは、それらすべてがインポートできるライブラリである可能性があります。メッセージプロトコルを定義している可能性があります。既存のツールを使用している可能性があります（ マイクロサービスメッセージバスを探します が適切な開始場所です）。
サービス間通信の問題は、それ自体「解決済み」の問題ではありませんが、この時点では「独自の問題」ではありません。多くの既存のツールと戦略は、あなたの人生を簡単にすることができます。
何をするかに関係なく、singleシステムを選択し、これを使用するように通信APIを適応させてください。サービスが相互作用するためのいくつかの定義された方法がなければ、マイクロサービスとモノリシックサービスのすべての欠点があり、どちらの利点もありません。
あなたの問題のほとんどはこれから生じます。
ルールエンジンへの要求は複雑です。
複雑さを軽減します。
それらをそれほど複雑にしない方法を見つけてください。真剣に。一般的なデータモデル。単一のルールエンジンを小さなものに分割します。ルールエンジンの動作を改善します。 「すべてをクエリに詰め込み、それらを複雑にしておく」というアプローチをとらないでください。何をしているのか、その理由を真剣に検討してください。
データに何らかのプロトコルを定義します。私の推測は、（上記のように）定義されたAPIプランがなく、RESTが必要に応じて随時アドホックを呼び出します。これは何かが更新されるたびにすべてのマイクロサービスを維持する必要があるため、ますます複雑になります。
さらに良いことに、あなたはオンラインショッピングツールを実装する最初の最初の会社ではありません。他の会社を調査してください。
それで...
この後、少なくともいくつかの最大の問題のトリアージを行いました。
次の問題は、ルールエンジンに関するこの質問です。これが合理的にステートレスであり、スケーリングできることを願っています。もしそうなら、あなたは次善の策として、栄光の炎で死ぬことも、狂った回避策を構築することもできません。
ルールエンジンをステートレスにする必要があります。データのみを処理するようにします。ボトルネックになっている場合は、プロキシ/ロードバランサーの背後で複数実行できるようにしてください。理想的ではありませんが、それでも機能します。
マイクロサービスのいずれかを実際にルールエンジンに組み込む必要があるかどうかを検討してください。 「マイクロサービスアーキテクチャ」を実現するためだけにシステムのオーバーヘッドを大幅に増加させる場合は、これを計画するためにより多くの時間を費やす必要があります。
または、ルールエンジンを分割することはできますか？ルールエンジン固有のサービスの一部を作成するだけで利益を得ることができます。
また、それがボトルネックにならないようにする必要もあります。たとえば、一部のデータのフェッチがかなり遅い（10秒以上）
上記の問題を解決した後にこの問題が発生したと仮定すると、これが発生している理由を真剣に調査する必要があります。悪夢が広がっていますが、なぜ（10秒？shoppingのショッピングポータルデータを送信するためですか？皮肉なことですが、これは少しばかげているように思われます）を理解する代わりに、パッチを適用しているようですそもそも症状の原因となっている問題を見るのではなく、症状です。
「データ取得」というフレーズを何度も使用しています。このデータはデータベースにありますか？そうでない場合は、これを検討してください。「手動で」データをフェッチするのに長い時間を費やしている場合は、実際のデータベースを使用することをお勧めします。
フェッチするデータのデータベース（これが何であるかに応じて、何度も言及したこともあります）、いくつかのルールエンジン、およびクライアントを備えた設計を使用できる場合があります。
最後の注意点は、APIとサービスの適切なバージョン管理を確実に使用することです。マイナーリリースは、下位互換性を壊すべきではありません。すべてのサービスを同時にリリースして機能させるには、マイクロサービスアーキテクチャがなく、分散モノリシックアーキテクチャがあります。
そして最終的に、マイクロサービスは万能のソリューションではありません。聖なるすべてのために、それは新しいヒップなものなので、それをしてはいけません。
ルールエンジンとその入力と出力について提示された情報量が多いので、あなたの提案は違います。 2は正しい軌道にあります。
ルールエンジンの現在の利用者は、必要な情報を収集するプロセスをより特別な目的のコンポーネントに外部委託することができます。
例：現在、ルールエンジンを使用して、ショッピングカートのコンテンツに適用する必要がある割引を計算しています。以前の購入、地理、現在のオファーがそれに影響を与えます。
新しい要件は、これと同じ情報の多くを使用して、今後のスペシャルや以前の購入に基づいて以前の顧客にオファーを電子メールで送信することです。以前の購入、現在および今後のオファーがそれに影響します。
これには2つの個別のサービスがあります。彼らはそれぞれ、その重荷の一部をルールエンジンサービスに依存していました。それぞれが、ルールエンジンへの要求に必要なデータを収集します。
ルールエンジンはルールを適用するだけであり、コンシューマは、ルールエンジンが特定のコンテキストに必要とする正確なデータについて心配する必要はありません。これらの新しい中間サービスは、コンテキストを組み立ててリクエストをルールエンジンに渡すだけです。変更されていない応答を返します。
私の単純な考えでは、顧客がデータの購入とキャッシュを開始するとすぐに、データ取得サービスに一連の非同期呼び出しを行うことで、必要なすべてのデータをプリフェッチすると役立つと思います。したがって、ルールサービスを呼び出す必要がある場合、データはすでにそこにあります。また、セッション中も他のサービスで引き続き利用できます。
決定に必要なデータの集計は、ルールエンジンの外部で行う必要があります。これは、可能な限りステートレスサービスとして設計するのが最適だからです。データのフェッチには、必ず非同期処理と状態保持が含まれます。フェッチが意思決定サービスの前にあるプロキシ、呼び出し元、またはビジネスプロセスのいずれによって行われるかは、あまり問題ではありません。
実装の実際的な問題として、IBM Operational Decision Managerは 文書化を開始し、Dockerコンテナー内での製品の使用を既にサポートしています であることを述べます。他の製品もこのサポートを提供し、主流になると確信しています。