サービスファブリックの内部通信の一時的な障害を処理するための再試行ポリシーが必要ですか？

Question

信頼できるサービスと俳優、IoTHubとWeb Apisを持つAzureサービスファブリックを使用しており、現在、サービスの（リモート）通信中のエラーに対処するための "一時的障害処理"（TFH）を統合しています。

Azure StorageとSQLの場合、既に実装されているため、組み込みの再試行ポリシーを使用して正常に動作します。

しかし、サービスファブリックの内部通信はどうですか？リモーティングメカニズムを介して通信するサービスもあります。

ここに私の質問は以下のとおりです。

• は、我々はサービスのファブリックで信頼性の高いサービスと信頼性の高いアクター間の通信のための過渡障害を処理する必要がありますか？
• もしそうなら、どうすればこのことができますか？一時的な障害処理アプリケーションブロックは、内部通信の再試行ポリシーを実装する唯一の方法ですか？
• サービスファブリックは一時的な障害をどのように処理しますか？

私はすでに集まっ追加情報：

This article about communication between servicesは、サービス間の通信のための典型的な障害処理の再試行パターンを説明しています。しかし、ICommunicationClientFactoryとICommunicationClientではなく、Service Remotingを使用しています。私は、Service Remotingでこの典型的な障害処理をどのように使用するかを理解できませんでした。

Answer 1

遅くとも、回答者はまだ答えを探しているかもしれません...とにかく、サービスファブリックにはデフォルトの一時的なフォールト処理（および一時的でないフォールト処理もあります）があります。 OperationRetrySettingsを使用してこれらをカスタマイズできます。 TransportSettingsを使用して他のプロパティをカスタマイズすることもできます。ここでは、これらの設定をカスタマイズする方法の例です：

FabricTransportSettings transportSettings = new FabricTransportSettings 
{ 
OperationTimeout = TimeSpan.FromSeconds(30) 
}; 

var retrySettings = new OperationRetrySettings(TimeSpan.FromSeconds(15), TimeSpan.FromSeconds(1), 5); 

var clientFactory = new Microsoft.ServiceFabric.Services.Remoting.FabricTransport.Client.FabricTransportServiceRemotingClientFactory(transportSettings); 

var serviceProxyFactory = new Microsoft.ServiceFabric.Services.Remoting.Client.ServiceProxyFactory((c) => clientFactory, retrySettings); 

var client = serviceProxyFactory.CreateServiceProxy<IXyzService>(new Uri("fabric:/Xyz/Service")); 

return client; 

HTH一般に//ピーター