問題タブ [azure-service-fabric]

SF Reliable Services を見つけながら、次の基本的なステートメントが正しいことを確認したいと思います。

1. Reliable Services のデフォルト通信スタック (DefaultStack) および Reliable Actors 通信スタック (ServiceProxy/ActorProxy を使用) は、SF クラスター内の通信にのみ使用できます。外部からのお客様は、WebAPI/WCF スタックを使用する必要があります。

2. ServicePartitionResolver、CommunicationClientFactory、ServicePartitionClient は、DefaultStack 内に既に実装されているものです。DefaultStack だけを使用している場合は、心配する必要はありません。

3. 一部のステートフル サービスには複数のパーティションがあり、たとえばアイテムを投稿して処理したい場合があります。顧客を投稿することによって正確にどのパーティションを使用する必要があるかを決定することは、SF の責任ではありません。パーティション キーまたは名前を解決するアルゴリズムを手動で実装し、それを ServiceProxy コンストラクター (DefaultStack 用) で使用する必要があります。

MS の ServiceFabric を使用してマイクロサービスを実行しようとしています。

シナリオ: Service1 で version1 を実行していて、v2 にアップグレードする準備ができています。

他の 3 つのサービスは、Service1 のインターフェイスに依存しています。Service1 の v2 をリリースできるようにしたいのですが、v2 に対して 3 つのサービスをアップグレードしてテストするまで、v1 を実行し続けます。

私が見つけたすべての例で、v2 は v1 をすぐに置き換えます。これは構成できますか? 特定のサービスの特定のバージョンに依存していることをサービス検出メカニズムに伝える方法はありますか?

Service Fabric の Reliable Services パイプラインを実装しようとしたとき、次の 3 つのアプローチから選択する必要がありました。

そして、Cが良い方法のようです。詳細はこちら。

この場合、ワーカー サービス間にある種のメッセージ ポンプを実装する必要があります。

たとえば、2 種類のワーカー サービスがあります。最初のものは IO バウンドで、スケーラビリティは必要ありません。2 つ目は CPU バウンドであり、スケーラビリティが必要なため、パーティショニングを使用します。具体的なアイテムの処理に正確にどのパーティションが使用されるかは気にしないので、メッセージ ポンプはロード バランサーとして機能し、入力キューに最小限のアイテムでアイテムを CPU バウンド サービスにエンキューする必要があります。とりあえず、この目的のためにステートフル サービスを作成しました。

この形式では、これは TPL Dataflow パイプラインに非常に似ています。

私の質問は、Service Fabric を正しく使用していますか? ここにオーバーエンジニアリングはありますか？

Reliable Actors は、この種のパイプラインにより適していますか? (またはパイプラインの一部)

ローカル クラスターをセットアップしようとすると、powershellスクリプトで次のエラーが発生します。

インストールを続行するか、このエラーの原因を修正する方法はありますか?

乾杯、

マイク

SDK を完全に削除して最初からやり直しましたが、まだ同じ問題が発生しています。すべてが「Connect-ServiceFabricCluster」に要約され、まったく機能しません (提供されたすべての提案に従いました)。

ネームサービスに関する警告は、何かを指しているに違いありませんか?

各試みは、次のように表示されます。

警告: ネーム サービスへの接続に失敗しました。フェールオーバー マネージャー サービスに接続しようとしています... 2>警告: フェールオーバー マネージャー サービスに接続できませんでした。FMM に接続しようとしています... 2>Connect-ServiceFabricCluster : 通信エラーにより操作が失敗しました。2>D:\Source\Play\ServiceFabricApplication\ServiceFabricApplication\Scripts\Deploy-FabricApplication.ps1:158 char:16 2>+ ... [void](Connect-ServiceFabricCluster @ClusterConnectionParameters ... 2>+ ~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~ 2> + CategoryInfo : InvalidOperation: (:) [Connect-ServiceFabricCluster]、FabricTransientException 2> + FullyQualifiedErrorId : CreateClusterConnectionErrorId、Microsoft.ServiceFabric.Powershell.ConnectCluster

トレイからのリセットの試行: トレイ排紙

私はサービス ファブリックに不慣れで、このトピックを扱っている MSDN の記事を読むことから始めました。ここでHello World サンプルを実装することから始めました。

元の RunAsync 実装を次のように変更しました。

また、DataObject 型を導入し、その型の UpdateDate プロパティを公開しました。

アプリを実行すると (Visual Studio 2015 では F5 キー)、dataObjectインスタンス (キーが 1) がディクショナリに見つからないため、作成して UpdateDate を設定し、ディクショナリに追加してトランザクションをコミットします。次のループでは、dataObject (キーが 1) を見つけて UpdateDate を設定し、ディクショナリ内のオブジェクトを更新して、トランザクションをコミットします。完全。

これが私の質問です。サービス プロジェクトを停止して再起動すると (Visual Studio 2015 では F5 キー)、RunAsync の最初の反復で、dataObject (キーが 1) が見つかると予想されますが、そうではありません。すべての状態がそのレプリカにフラッシュされることを期待します。

ステートフル サービスが内部状態をプライマリ レプリカにフラッシュするために何かする必要がありますか?

私が読んだところによると、これはすべてサービス ファブリックによって処理され、(トランザクションで) commit を呼び出すだけで十分であるかのように聞こえます。(Service Fabric Explorer->Application View で) プライマリ レプリカを見つけると、トランザクションをコミットすると (ステップ スルーするときに) RemoteReplicator_xxx LastACKProcessedTimeUTC が更新されていることがわかります。

どんな助けでも大歓迎です。

ありがとうございました！

-マーク

ターゲット フレームワークを 4.5.1 から 4.6 に変更した後、Azure Fail 内のサービスはローカル デプロイが機能しています。

.Net 4.6 サポートを追加する必要がありますか? - Azure のクラスターで使用できるフレームワークを確認できる場所が見つかりません。

ありがとうございました

ApplicationName: fabric:/Lending20.Service.IdentityManagement AggregatedHealthState
: エラー UnhealthyEvaluations: 異常なサービス: 100% (1/1)、ServiceType='IdentityManagementServiceType'、MaxPercentUnhealthyServices=0%。

異常なサービス: ServiceName='fabric:/Lending20.Service.IdentityManagement/Identity ManagementService'、AggregatedHealthState='Error'。

異常なパーティション: 100% (1/1)、MaxPercentUnhealthyPartitionsPerService=0%。

異常なパーティション: PartitionId='7c68b397-fda3-491d-9e17-921cd24217ca'、AggregatedHealthState='Error'。

エラー イベント: SourceId='System.FM'、Property='State'。

ServiceHealthStates: ServiceName: fabric:/Lending20.Service.IdentityManagement/IdentityManagementService AggregatedHealthState: エラー

DeployedApplicationHealthStates: ApplicationName: fabric:/Lending20.Service.IdentityManagement NodeName: _lending1 AggregatedHealthState: Ok

HealthEvents: SourceId: System.CM Property: State HealthState: Ok SequenceNumber: 3464 SentAt: 11/21/2015 12:38:08 PM ReceivedAt: 11/21/2015 12:38:08 PM TTL: Infinite Description: アプリケーションが作成した。RemoveWhenExpired : False IsExpired : False トランジション : 警告->Ok = 2015 年 11 月 21 日 12:38: