Azureサービスファブリックへの移行 - アーキテクチャ上の考慮

Question

私たちは2010年からAzureを利用しており、アプリケーションのパフォーマンスと信頼性に大きなメリットをもたらしました。 Azureはエンタープライズレベルのサービスをたくさん提供しています。私は新しい "Azure Service Fabric"が素晴らしいと思います。

ドキュメントを読んで理解できないことは、「古い」クラウドサービスを新しいサービスファブリックに移行する方法です。なぜ私たちは移行したいのですか？水平スケーリングとより高い信頼性。

現在、私たちは単一インスタンスのクラウドサービスを提供しており、多くのサブサービスをスピンアップしています。これらのサブサービスは、マイクロサービスの大きな候補です。唯一の問題は、これらのサブサービスの一部が「ランナー」であることです。つまり、ユーザーデータベースを循環させ、特定のユーザーに対して操作（サービス）を実行する必要があるかどうかを決定します。 複数のインスタンスがこのサービスを実行する可能性があることを考慮して、このようなサービスをどのように移行しますか？ （：それはクラッシュした場合、それは自動的に再起動します例）心に留めておくべき

おかげ

Answer 1

まず最初は、サービスがそれを実行し続ける開始され、そして彼のライフサイクルと稼働時間がサービスファブリックによって制御された後ということです。 2つ目のことは、（異なるノード上で）同時に実行されている複数のサービスインスタンスで終わるので、クラスタの異なるノードでまったく同じことを行うことになります。

あなたの最初のリフレクションは、RunAsync（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-advanced-usage）を実行し続けているランナー "サブサービス"ごとに、1つのステートレスなサービス種類/インスタンスを持つことができます。個人的には、私はこのアプローチを取っていません。なぜなら、これは、全く同じことを独立して行うので、無用な同時実行を防ぐためにサービス間で何らかの同期を必要とする可能性があるからです。

オーケストレーターとして機能する「メイン」サービスによって要求されたランナーサービスをしばらく実行する必要がある場合は、「メイン」サービスがタスクを送信するキューベースのアプローチを使用することができます最大1つのサービスインスタンスがそのタスクを完了することを確実にして、同じキュー上で同時に聴いているランナーによって処理されるメッセージ（メッセージ）

キューの場合は、サービスバスまたは信頼できる同時キュー（https://docs.microsoft.com/enus/dotnet/api/microsoft.servicefabric.data.collections.preview.ireliableconcurrentqueue-1）と考えてください。