問題タブ [azure-service-fabric]

Azureのワーカープロセスを作成しようとしていますが、nUnitを介してテストしたいと思います。ストレージに接続してデータをアップロードするプロセスを作成する必要があります。問題は、開発ファブリックなどを開始するためのテストフレームワークを実際にどのように設定したかについての参照が見つからないことです。

ワークプロセッサの役割を作成してから、テストプロジェクトを作成し、nunitを接続して開始し、プロジェクトがテストプロジェクトのdllを取得できるようにしました。これはすべてnUnitを開くと正常に機能し、テストdllを確認してテストを実行できます。

私の問題は、「nUnitを介してプロジェクトを実行するときに、開発ファブリックを起動するにはどうすればよいですか？」です。テストプロジェクト内のセットアップルーチンに何かを入れる必要があると思いますが、何を入れるべきかわかりません。

誰かが何かヒントや経験など、方法へのリンクなどを持っているなら、私は非常に感謝しています。Azureプロジェクトをテストしたいと思う最初の人になることはできないと確信しています。

最近、Windows Server Service Bus 1.0を（Windows Server 2008 R2マシンに）インストールしました。

これにより、「WindowsFabric」（AppFabricではない）もインストールされます。

それに関する多くの情報を見つけることができませんでした、そしてそれをググって、私はLyncサーバーの投稿に出くわしました（WindowsFabricはLyncServer2013によってもインストールされています）。

意味：

「WindowsFabricは、信頼性が高く、配布可能で、スケーラブルなアプリケーションを作成するために使用されるMicrosoftテクノロジです。」

Service Busアーキテクチャの概要から、Fabricはサービスの複製、高い可用性、およびフォールトトレランスを可能にするもののように見えます。

カスタム.NETサービスをホストするためにそれを使用できるかどうか誰かが知っていますか？または、どんな方向性でも大歓迎です。

前もって感謝します。

Cos

Service Fabric はビルド カンファレンスで発表されたばかりです。私はそれに関する乏しいドキュメントを読んでいて、質問があります。

現在、ASP.NET WebApi に組み込まれている CRUD のようなマイクロサービスをホストする Service Fabric を評価しています。

Service Fabric は、CRUD WebApi タイプのアプリケーションをホストするのではなく、データを受信して​​処理し、結果を返す小さな機能をホストすることを目的としていますか?

Azure Service Fabric の BUILD カンファレンス ビデオを見た後、これが現在のマイクロサービス ベースのアーキテクチャにどのように適合するかを想像しました。ただし、解決方法が完全にはわからないことが 1 つあります。それは、API ゲートウェイ/プロキシです。

REST エンドポイントを公開する Azure Service Fabric 内で N 個のサービスが実行されている、それほど重要ではないマイクロサービス アーキテクチャを考えてみましょう。多くの場合、これらのフラグメント化された API エンドポイントを、コンシューマーが使用できる単一エントリ API にパッケージ化して、サービス ファブリック インスタンスに直接接続することを避ける必要があります。Azure Service Fabric ソリューションはあらゆる点で非常に完成度が高いように見えるので、BUILD の説明で言及された機能の範囲内でこれを自明に解決する方法が見当たらない場合、明らかな何かを見落としているのではないかと思うほどです。

Vulcanのようなサービスは、サービスにルーティングしたいパスをetcdに登録させることで、この問題を解決することを目指しています。これを解決する1つの方法は、他のサービスが自分自身を登録できる別のステートフルWebサービスを作成し、サービス名とそれらにルーティングする必要があるパスを提供することだと思います. ステートフル Web サービスは、その状態に基づいてトラフィックを正しいインスタンスにルーティングできます。ただし、アプリケーションが削除されたときにルートを削除したり、通常はクラスター内にデプロイされたサービスと状態を同期させたりするなど、これは完全に理想的ではないようです。誰かがこれについて何か考えたことはありますか、または Azure Service Fabric 内でこれを解決する方法についてアイデアを持っていますか?

この MS 記事に従って、Azure Service Fabric SDK - Preview 1 をインストールしようとしています。

Service Fabric Preview 1 のツールは、Visual Studio 2015 RC に依存しており、こちらで見つけることができます。

VS 2015 RC PRO が既にインストールされています。私もVS 2012 U4を持っています。Azure SDK 2.56 も。

ダウンロードしてインストールしようとすると、驚きがあります。エラー メッセージのスクリーンショットを次に示します。Windows Server 2012 が必要です。

これがログ 1 です 。これがログ 2 です。

何が問題なのか、サービス ファブリック向けにどのように開発すればよいのかを理解することはできますか? VS 2015 を搭載した WS 2012 が必要ですか?

現在の WebApps/CloudServices スタックの代替として Azure Service Fabric の評価に夜を費やしていますが、状態を持つサービス/アクターをステートフル アクターにする必要がある場合と、ステートレス アクターにする必要がある場合を判断する方法について少し確信が持てません。外部に永続化された状態 (Azure SQL、Azure Storage、および DocumentDB)。これがかなり新しい製品であることは知っています(少なくとも一般の人々にとっては)。したがって、これに関するベスト プラクティスはまだ多くないでしょう。これに対する答え。

私が現在取り組んでいる問題のドメインは、イベント ストアです。アプリケーションの一部はイベント ソーシングと CQRS に基づいており、このイベント ストアを Service Fabric プラットフォームに移行する方法を検討しています。イベント ストアには多くの時系列データが含まれます。そこに永続化されるデータの唯一の信頼できる情報源であるため、一貫性があり、レプリケートされ、何らかの形式の耐久性のあるストレージに保存される必要があります。

私がこれを行うことを検討した 1 つの方法は、ステートフルな「EventStream」アクターを使用することです。イベント ソーシングを使用する集約の各インスタンスは、そのイベントを分離されたストリーム内に格納します。これは、ステートフル アクターが独自のストリームのすべてのイベントを追跡できることを意味し、データの保存方法 (トランザクション、レプリケート、耐久性) に関する要件を満たしていることになります。ただし、一部のストリームは非常に大きくなる可能性があり (数百万とは言わないまでも数十万のイベント)、これが私が確信を持てなくなっているところです。大量の状態を持つアクターを持つことは、これらの大きなデータ モデルをディスクにシリアル化またはディスクから逆シリアル化する必要がある場合に、システムのパフォーマンスに影響を与えると思います。

もう 1 つのオプションは、これらのアクターをステートレスに保ち、Azure SQL などの外部ストレージからデータを読み取らせるか、アクターの代わりにステートレス サービスを使用することです。

基本的に、アクター/サービスの状態の量が「多すぎる」のはいつで、状態を処理する他の方法を検討し始める必要があるのはいつですか?

また、Service Fabric Actors デザイン パターンのこのセクション: Some anti-patterns documentationは、私を少し困惑させます:

Azure Service Fabric アクターをトランザクション システムとして扱います。Azure Service Fabric Actors は、ACID を提供する 2 フェーズのコミット ベースのシステムではありません。オプションの永続性を実装せず、アクターが実行されているマシンが停止した場合、その現在の状態はそれに伴います。アクターは別のノードで非常に高速に起動しますが、バッキング永続性を実装しない限り、状態はなくなります。ただし、再試行、重複フィルタリング、および/またはべき等設計を活用することで、高レベルの信頼性と一貫性を実現できます。

「オプションの永続性を実装しない場合」は、ここで何を示していますか? 状態を変更するトランザクションが成功する限り、データは耐久性のあるストレージに保持され、少なくともレプリカのサブセットに複製されるという印象を受けました。このパラグラフは、アクター/サービス内の状態が失われる状況があるかどうか、またこれは自分で処理する必要があるかどうか疑問に思っています。ドキュメントの他の部分にあるステートフル モデルから得た印象は、この主張を否定しているようです。

Azure Service Fabric は、すべてのデータが RAM 内に収まり、永続性がバッキング ストアとして使用されるシナリオに重点を置いているようです。Reliable Services は、ログに記録された情報が RAM に書き込まれるログチェックポイント システムを使用する Reliable Collections に情報を格納するように設計されています。一方、Reliable Actors の場合、既定のアクター状態プロバイダーは "Service Fabric プラットフォームによって提供される分散型の Key-Value ストア" です。これは、同じ制限が適用されることを示しているようです。

ただし、"ホット データ" には Service Fabric を使用し、"コールド データ" を何らかの形式の永続的なストレージに書き込みたい場合があります。この移行を処理するためのベスト プラクティスは何ですか?

Orleans では、Azure テーブルなどの永続ストアを使用して、これが自動的に処理されるようです。しかし、Service Fabric と Reliable Collections の主な設計目的は、外部サービスを必要としないようにして、データの局所性を高めることであるようです。現在のドキュメントでは、障害復旧と分析のためにデータを何らかの永続的なストアに移動する可能性を想定していますが、永続性に支えられたインメモリ アクターとより永続的な形式のストレージの間でデータをやり取りする可能性については説明していません。 .

考えられる答えは、Service Fabric が既にこれを行っているということです。おそらく、Reliable Dictionary には、永続性に裏打ちされたメモリ内ストレージと永続ストレージを切り替えるためのメカニズムが組み込まれています。

あるいは、答えは、自分で管理しなければならないということかもしれません。1 つのアプローチは、アクターがどの程度「ホット」であるかを追跡し、必要に応じて永続ストアを切り替えることです。しかし、これはアクター モデルの利点の 1 つであるアクターの自動割り当てと割り当て解除を犠牲にします。同様に、定期的に Reliable Dictionary からアイテムを削除し、それを他の永続ストアに追加してから、再度追加することもできます。繰り返しになりますが、これには、いつ移行を行うのが理にかなっているかについての知識が必要です。

いくつかの例がこれを具体化するのに役立つかもしれません:

(1) 多くの異なる「部屋」を持つマルチプレイヤー ゲームを実装しているとします。すべてのルームを一度にメモリに格納する必要はありませんが、それらをメモリに移動し、プレイヤーがルームに参加したらバックアップとしてローカル永続性を使用する必要があります。

(2) データベースの一部として追加専用の B ツリーを実装するとします。各 B ツリー ノードをステートフルなアクターにしたくなるでしょう。ホット B ツリーをメモリに残しておきたいのですが、もちろんインデックス全体をメモリに残すことはできません。これは、DocumentDB などで既に実装されているコア シナリオのようですが、ドキュメントからは、これを行う方法が明確ではありません。

私が見つけた関連する質問はこちらです。しかし、その質問は、Azure Service Fabric と外部サービスをいつ使用するかということに焦点を当てています。私の質問は、それらの間で移行する必要があるかどうか、または Azure Service Fabric がここで必要なすべての機能を既に備えているかどうかです。

アプリケーション プロジェクトを右クリックして [デプロイ] を選択するか、F5 キーを押して、Visual Studio 2015 からアクター サービスをデプロイすると、次のエラーが発生します。

Test-ServiceFabricApplicationPackage : 「Test-ServiceFabricApplicationPackage」という用語は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。名前のスペルを確認するか、パスが含まれている場合は、パスが正しいことを確認してから再試行してください。

Windows Server 2012 R2 を実行しています。

Import-Module "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ServiceFabric\ServiceFabric.psd1" を実行しようとしましたが、常に同じエラーが発生します。

PS を使用して VS が実行する同じスクリプトを実行すると、展開が機能します。

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

ありがとう、ルディ