Windows ワークフローに少し慣れていないので、簡単に進めてください :)
高可用性を備えたワークフロー ホスト環境を設計したいと考えています。少なくとも 2 つの WF ランタイム ホストが別々のハードウェア上にあり、どちらも同じ永続性または追跡 SQL データベースを指しています。
外部イベントに基づいて新しいワークフロー インスタンスを非同期的に作成できるパターンを探しています (つまり、別のアプリケーションによって DB で一部のデータが更新されます)。イベントごとにワークフロー インスタンスを 1 つだけ作成する必要があり、そのインスタンスがどのホスト上で作成されるかは問題ではありません。イベントからワークフロー インスタンスが実際に作成されるまでの期間についても、ある程度の柔軟性があります。
私が検討している 1 つの解決策は、WF ホストに WCF インターフェイスを配置し、それらをある種のロード バランサーの背後に配置することです。その後、「イベント」を発生させて WCF 呼び出しを行うシステムの部分に依存します。
両方\すべての WF ホストがダウンしているか、または使用できない場合、イベントが「失われる」可能性があるため、これにはあまり満足していません。また、思い通りに負荷を管理することもできません。短期間に多くのイベントが発生する可能性がある状況を想定していますが、後でそれらのイベントを処理することはまったく問題ありません。
したがって、何らかの形でイベントを永続化し、イベントの作成をイベント処理から切り離す必要があると思います。
これらのイベントを MSMQ または SQL Server の単純なイベント テーブルに配置し、WF ホストにキューを定期的にポーリングさせることは実行可能な解決策ですか? 世論調査は汚い言葉のようですが...
ここで NServiceBus と耐久性のあるメッセージングは役に立ちますか?
どんな洞察も大歓迎です。
補遺
データベースは、共有ファイバー チャネル ストレージでクラスター化されます。ネットワークも冗長化されます。WF ランタイム インスタンスがフェイルオーバーできるようにするには、共通の持続性サービス (この場合は SQL バックエンド) をポイントする必要があります。総可用性ではなく、高可用性です:)
また、WF ランタイムの各インスタンスはまったく同じビットを実行している必要があるため、アップグレードではすべてのインスタンスを同時に停止する必要があります。必要に応じて、システム全体をダウンさせることなく、それを実行できるというアイデアが気に入っています。