多くのファイルを継続的に処理する既存のシステムがあります。大まかに言えば、1 日に約 300 万個のファイルがあり、そのサイズは数キロバイトから 50 MB を超えるものまでさまざまです。これらのファイルは、パスに応じて、受信時から消費が完了するまで、いくつかの異なる処理段階を経ます。これらのファイルの内容と形式により、小さなチャンクに分割することはできません。
現在、これらのファイルが移動するワークフローは厳格であり、入力と出力が固定されたコードによって決定されます (多くの場合、1 人のサブスクライバーが新しいファイル セットのパブリッシャーになります)。しかし、この柔軟性の欠如が問題を引き起こし始めているため、新しい要件を処理できるようにするためのある種の pub/sub ソリューションを検討しています。
ほとんどの従来の pub/sub ソリューションでは、実際のペイロード内にデータが含まれていますが、ファイル サイズが大きくなる可能性があるため、多くのメッセージング プラットフォームの制限を超えています。さらに、複数のプラットフォームが使用されています。ファイルはパスに応じて Linux 層と Windows 層の両方を通過します。
次の目標を念頭に置いて、設計および/または実装に関する推奨事項はありますか?
1. pub と sub の両方のマルチプラットフォーム (Linux と Windows)
2. 永続的なストレージ/ストア アンド フォワードのサポート
3. 大きなイベント ペイロードを処理でき、すべてのサブスクライバーにサービスが提供されると適切にクリーンアップできます
4. ルーティング/ワークフローは構成によって実行されます
5. サブスクライバーは、条件の変更に基づいてフィルター処理された一連の公開イベントをサブスクライブできます (例: 特定のタイプのファイルのみを提供する)。
私は多くのサービス バスと MQ の実装を掘り下げてきましたが、どのツールが最も意味があるかを適切に評価するのに十分な設計アプローチを確立することはできませんでした。ご意見ありがとうございます。