60

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

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

4

3 に答える 3

24

選択肢の 1 つは、状態の「一部」をアクターに保持し (たとえば、すぐに利用できるようにする必要があるホット データと考えられるものを考えてみましょう)、その他すべてを SQL Azure などの「従来の」ストレージ インフラストラクチャに格納することです。 、DocDB、.... ローカル状態が多すぎることについて一般的なルールを定めることは困難ですが、ホット データとコールド データについて考えるのに役立つかもしれません。Reliable Actors は StateProvider をカスタマイズする機能も提供するため、データ量、レイテンシーに関する要件をより効率的にするために必要な特定のポリシーを使用して、カスタマイズされた StateProvider を (IActorStateProvider を実装することによって) 実装することを検討することもできます。 、信頼性など (注:

アンチパターンについて: このメモは、複数のアクターにまたがるトランザクションの実装に関するものです。Reliable Actors は、アクターの境界内のデータの信頼性を完全に保証します。アクター モデルは分散型で疎結合であるため、複数のアクターが関与するトランザクションの実装は簡単な作業ではありません。「分散」トランザクションが強い要件である場合は、Reliable Services プログラミング モデルの方が適している可能性があります。

于 2015-05-06T22:14:08.297 に答える
5

私はこれが答えられたことを知っていますが、最近、CQRS/ES システムで同じ苦境に陥っていることに気付きました。

  1. 各 Aggregate は、現在の状態のみが格納されたアクターです。
  2. コマンドで、集約は状態の変更に影響を与え、イベントを発生させます。
  3. イベント自体は DocDb に格納されていました。
  4. AggregateActor インスタンスはアクティブ化時に、状態を再作成できる場合は DocDb からイベントを読み取ります。これは明らかに、アクターのアクティブ化ごとに 1 回だけ実行されます。これにより、アクター インスタンスが 1 つのノードから別のノードに移行されるケースが処理されました。
于 2016-05-25T05:31:13.207 に答える
3

@Trond の sedcondary の質問に答えるには、「「オプションの永続性を実装しない場合」はここで何を示しますか?」

アクターは常にステートフル サービスであり、その状態は、アクター クラスの属性を使用して、次の 3 つのモードのいずれかで動作するように構成できます。

  1. しつこい。状態はすべてのレプリカ インスタンスにレプリケートされ、ディスクにも書き込まれます。この状態は、すべてのレプリカがシャットダウンされても維持されます。
  2. 揮発性。状態はすべてのレプリカ インスタンスにレプリケートされますが、メモリ内のみです。これは、1 つのレプリカ インスタンスが存続している限り、状態が維持されることを意味します。ただし、すべてのレプリカがシャットダウンされると、状態が失われ、再起動後に復元できなくなります。
  3. 持続性なし。状態は、他のレプリカ インスタンスにもディスクにも複製されません。これにより、最小限の状態保護が提供されます。

このトピックの完全な説明は、Microsoft のドキュメントにあります。

于 2017-11-04T04:00:45.243 に答える