3

Windows Azure と WF4 を使用しており、ワークフロー サービスは Web ロール (N 個のインスタンス) でホストされています。私の仕事は、適切なワークフロー インスタンスにメッセージを送信できる方法でアフィニティを実行する方法を見つけることです。このシナリオを説明するために、私のワークフロー (添付) は "StartWorkflow" 受信アクティビティで開始し、3 つの "Person" を作成し、それぞれに対して並行して、これら 3 人の確認を待ちます ("ConfirmCreation" Receive アクティビティ)。

次に、他の NLB 環境でアフィニティがどのように作成されているかを検索し始めました (主に、これが Windows Server AppFabric でどのように機能するかについての情報を探しました) が、正確な答えは見つかりませんでした。では、他の NLB 環境ではどのように行われているのでしょうか?

私の次のタスクは、Windows Azure でこのアフィニティを処理するシステムを実装する方法と、このソリューションが実行可能かどうか、または 1 つだけで作業する方がよいかどうかを確認するために (価格、時間、および作業量の点で) どれくらいの費用がかかるかを調べることです。 Azure AppFabric の WF4 ホストを待機している間、web-role インスタンス。私が見つけた唯一の方法は、ワークフロー インスタンスを永続化することでした。これを行う他の方法はありますか？

最後ではない 3 番目のタスクは、同時に受信した複数のメッセージを WF4 がどのように処理するかを調べることです。私のシナリオでは、これは、3 人が同時に確認され、確認メッセージも同時に受信された場合の処理​​方法を意味します。この問題に対する最も論理的な答えはキューを使用することであると思われるため、WF4 でキューに関する情報を探し始めたところ、MSQM について話している人を見つけました。しかし、ネイティブの WF4 メッセージ ハンドラー システムとは何でしょうか? このハンドラーは本当にキューですか、それとも別のシステムですか? この同時実行はどのように処理されますか?

4

2 に答える 2

2

アフィニティは必要ありません。実際、それが永続的なワークフローの要点です。ワークフローがこの確認を待っている間、ワークフローは保持され、いずれかのサーバーからアンロードされる必要があります。

Windows Azure の永続化に関する限り、SQL Azure で動作するように標準の SQL 永続化スクリプトをハックするかInstanceStore、Azure Storage 上に配置する独自の実装を作成する必要があります。Azure で実行しているワークフローに対して後者を実行しましたが、コードを共有できません。努力の 1 から 10 のスケールで、8 程度にランク付けします。

複数のメッセージに関する限り、メッセージは一度に 1 つずつ受信され、ワー​​クフロー インスタンスに配信されます。現在、これらのメッセージのすべてが同じサーバーに送信されるか、それぞれが差分に送信される可能性があります。サーバ。どのように発生しても、ワークフロー ランタイムはインスタンス ストアからワークフローを読み込もうとし、現在ロックされていることを確認し、ワークフローが次のメッセージを処理できるようになるまでブロック/再試行します。InstanceStoreしたがって、すべてを正しく構成し、実装が適切に機能している限り、同じワークフロー インスタンスへの同時アクセスについて心配する必要はありません。

他のいくつかの提案を次に示します。

  • SendReply アクティビティで PersistBeforeSend オプションを使用していることを確認してください
  • 次のワークフロー サービス オプションを構成します。
    • <workflowIdle timeToUnload="00:00:00" />
    • <sqlWorkflowInstanceStore ... instanceLockedExceptionAction="AggressiveRetry" />
于 2011-03-18T21:58:07.087 に答える
1

すぐに使用できるSQLインスタンスストアをSQLAzureで使用することは、現時点ではAzure 1.3 SDKで少し問題があります。各展開では、コードを0回変更した場合でも、新しいサービス展開が行われるため、ワークフローはすでに永続化されています。続行しません。これは解決されるバグですが、今のところPITAです。

Drewが言ったように、ワークフローインスタンスは必要に応じてサーバー間を移動するだけでよく、特定のマシンに固定する必要はありません。そして、それがスケーラビリティと信頼性を損なう可能性があるとしても、避けるべきことがあります。

WCFNetMsmqBindingを使用してMSMQを介してメッセージを送信することは問題なく機能します。内部的には、WFはブックマークと呼ばれるまったく異なるメカニズムを使用して、ワークフローを停止および再開できるようにします。各Receiveアクティビティ、およびDelayなどの他のアクティビティは、ブックマークを作成し、それが再開されるのを待ちます。再開できるのは既存のブックマークのみです。ブックマークを再開することも直接的なアクションではありませんが、ワークフロースケジューラによって、MSMQではなく内部キューに入れられ、SynchronizationContextを介して実行されます。スケジューラーを制御することはできませんが、WorkflowApplicationを使用するときにSynchronizationContextを置き換えることができるため、アクティビティーの実行方法と場所をある程度制御できます。

于 2011-03-19T07:28:47.517 に答える