2

環境内のシステム間でデータとビジネス プロセスを調整するために、企業内でサービス バス アーキテクチャを採用することを検討しています。

私たちの状況は典型的です。請求、在庫などのために内部システムにメッセージを送信する顧客向け Web アプリケーションです。これらのシステムのほとんどまたはすべてに共通するビジネス エンティティがいくつかあります。これらの各システムは、独自のデータベースでこれらのエンティティの独自のバージョンを維持します。

サービス バスの概念に適用すると、顧客の Web ポータルから注文を表すメッセージをバスに発行できます。このメッセージは、関連する各システム (請求、在庫など) によって消費され、対応する顧客レコードが独自のデータベースに作成されます。ただし、これらの内部システムの 1 つが注文ステータスに関するメッセージを発行する必要がある場合、独自のデータベースから注文 ID を保持します。Web ポータルがそのメッセージを消費する必要がある場合、内部システムから送信された注文 ID を Web ポータル データベースに保存された注文 ID と関連付ける方法がわかりません。

同等のエンティティがシステム間でどのように相関しているかを本質的に認識しているシステムは他にないため、システムがメッセージに含まれる ID をそれに関連する ID に変換できるようにするために、何らかのタイプのマッピング メカニズムを導入する必要があるようです。たとえば、あるシステムから別のシステムに ID をマップするデータベース テーブルを作成できます。このテーブルを照会して、ターゲット システムの適切な ID を取得できます。私たちのビジネスは現在、エンティティ集約やその他の「360ビュー」タイプのリポジトリを利用して、共通のエンティティ情報の単一の信頼できるソースとして機能し、そこからユニバーサルIDをすべてのシステム間で受け渡し、使用することはできません.

このようなエンティティ マッピング アプローチをサービス バスの実装に使用することは有効なアプローチですか? もしそうなら、設計を導くための確立されたガイドラインはありますか? そうでない場合は、サービス バスを介した統合を促進するために、システム全体でエンティティをリンクするための代替アプローチについて聞くことに興味があります。

PS: それが役に立てば、私は現在、バスを構築するための MassTransit フレームワークを評価しているので、それに固有の情報があれば、それも大歓迎です。

4

2 に答える 2

1

詳細がなければ、このようなものに似たアプローチを検討します...

  1. ウェブサイトがSubmitNewOrderメッセージを公開
  2. MiddleManager サービスはそのSubmitNewOrderメッセージを受け取り、各システムのタスクに変換します。その変換を使用すると、ID 変換を行うことができます
  3. 各システムには、適切なメッセージ/コマンドを消費し、それに応じて動作するエンドポイントがあります

したがって、ここでのいくつかのことは、エンティティを周囲に送信する代わりに、コマンドを送信していることです。これで、エンティティのサブセットを送信できます (これは、エンティティからインターフェイスを抽出し、メッセージ タイプを作成する絶好の機会です)。これは、この問題に対する高いレベルからの完全に有効なアプローチのように思えます。

これをさらに深く掘り下げたい場合は、Enterprise Service Bus: Theory in Practiceを参考にしてください。MassTransit とは何の関係もありませんが、多くの理論が当てはまり、優れた基礎を築いています。

于 2013-01-24T12:33:00.617 に答える
0

私も今の会社で似たような仕事をしたことがあります。私は C# の経験があり、サービス バスの概念は初めてでした。私が取り組んできたプロジェクトはほとんど Java で行われていたため、Mule ESB をソリューションとして採用することになりました。強くお勧めしますが、そのままでは .NET コードと同じように動作しない可能性があることを認識しています。

質問: システム全体でエンティティをどのように管理していますか?

現在、2 種類のエンティティがあります。1 つの権限のあるシステムに存在し、他のシステムにコピーされるもの、およびシステム間で共有されるエンティティ。

エンティティが 1 つのシステムに由来する場合、そのエンティティのコピーを複数のシステムに作成するのが最善であることがわかりました。サービス バスは、データを抽出して変換し、適切なシステムに読み込みます。ソースと宛先には固定のエンティティ データ形式があり、サービス バスが変換を行います。これは私たちにとって非常にうまく機能しています。

共有エンティティの場合は、少しトリッキーです。部分的な変更 (1 つのシステムが 5 つのプロパティ/フィールドを変更し、別のシステムが別の 3 つのプロパティ/フィールドを管理する) を許可しますが、これまでのところ問題なく機能しています。データの一貫性が失われるリスクがあるため、共有エンティティを最小限に抑えようとしました。(たとえば、「このエンティティが奇妙に見えるのはなぜですか? そうそう、一部のシステムがステータス フィールドを変更しましたが、それができることを忘れていました。」)

キューの使用

ActiveMQ とトピックの概念を使用して、システムからシステムへデータを送信します。トピックはキューに似ていますが、多くのサブスクライバーがトピックをリッスンできます。たとえば、記事エンティティを生成する内部 CMS があります。ユーザーが記事を公開すると、ActiveMQ トピックに送信されます。

次に、サービス バスには、トピックを監視している多くのリスナーを含めることができます。各リスナーは、出てくるエンティティの独自のコピーを取得します。次に、各リスナーは独自の変換を行い、コピーを適切なシステムに送信することもできます。

理解/コーディング/テスト/保守が非常に簡単であることが証明されています。

マッピングデータベースを持つ

残念なことに、私は最近、値をスクリプトにハードコーディングすることでこれを行いました。実際、コードを生成するツールを作成しましたが、まだスクリプト ファイルに含まれています。その理由は、大量のメッセージをサービス バスに送信する大量のバッチ処理を行うためです。メッセージが通過しなければならないたびにデータベース検索を行うために代償を払いたくありません。

私のツールは、エンティティのマッピング/調整を管理するスクリプトを生成し、非常に高速です。変更が加えられた場合は、ツールを再実行するだけで、新しいスクリプトの準備が整います。私にとってのマッピング情報は非常にゆっくりと変化するので、問題ありません。

しかし、エンティティのマッピングを持つデータ ストア (XML、データベース、フラット ファイルなど) を作成できれば、それで問題ないと思います。

一般的なアドバイス

多くの Service Bus 作業を行う際のヒント:

  1. サービス バスは特効薬ではありません。私の経験から、多種多様な技術を持っている場合に最も効果的です。たとえば、MySQL、SQL Server、ActiveMQ、Mongo、CouchDb、Elastic Search などがあります。

  2. Mass Transit の仕組みはわかりませんが、Mule にはフローの概念があります。フローは、ポイント A からポイント B への 1 つの概念的なデータ フローです。多くのフローを使用できます。私はこれらを非常にシンプルにするために最善を尽くしています。これにより、テストがかなり簡単になります。これは統合作業であるため、デバッグが容易ではないため、複雑さを取り除くことを好みます。

  3. エンティティをソースで可能な限り宛先に近づけるようにしてください。つまり、.NET Web サービスからデータを取得して SQL に書き込む場合、完全な変換に向けて 90% の時点でオブジェクトがサービス バスに送られるようにする必要があります。これにより、サービス バスのロジックが単純になります。

于 2013-01-24T05:38:09.010 に答える