Azure Service Fabric：2番目のステップ

映画「New Times」の工場で再びチャーリー・チャップリン

Azure Service Fabricに関する会話を続けます。 前の記事で、最初にステートフルサービスについて記述し、次にASFのアクターモデルに移る計画について述べました。 概念が変更されました。例として、実稼働ソリューションではなく、近いものを使用して、理論上の利点と実用的な意味があるようにするとよいと思いました。 ASFのすべてのコンポーネントを1つのボトルにまとめることができます。これにより、ルナパーク、プーさん、そしてすべてすべての王冠をcrownい上げることができます。 そのような考えを持って、私は活性化の候補者を探してホームプロジェクトの墓地に行きました。

生きている死者

そして、そのような候補が見つかりました。 彼らは「鉄」の記事を書くのが好きなので、「スペアパーツを入れた箱に詰め込む」ことは、そこからAdvanced Direct Connectプロトコルを使用した未完成のライブラリを見つけ出しました。 「顔にはひどい、ひどい」とはいえ、ほこりでほこりを払い落として、彼は人生がまだ内部で暖まっていると確信しました。 このライブラリはかつて未作成のADCクライアントを対象としていましたが、それに基づいてADCハブを作成してみませんか？ これは新鮮で独創的なアイデアです-試してみてください。

残念ながら、ADCの仕様には想像の余地が残されています。「ゲームの音楽はプロのプログラマーによって書かれている」だけでなく、RFCの精度やW3C標準からはほど遠いことです。 このため、途中で、既存のADC実装（ADCH ++、AirDC ++など）の詳細を明確にする必要がありました。

組立モデル

通常どおり、一般的なアーキテクチャの見積もりから始めます。 簡単にするために、ハブは開いています。つまり、ユーザーは登録とパスワードなしでログインできますが、名前は一意でなければなりません。 全体像の3つの論理部分がすぐに表示されます-これはTCP接続サーバー、クライアントと交換するためのADCを実装するオブジェクト、各クライアントに1つ（ユーザーと呼びます）、最後にすべてのアクティブなクライアントの共通カタログです。

TCPサーバーはTCP接続を確立し、クライアントとシリアル化されたADCメッセージを交換します。ユーザーは仕様に従ってプロトコルを正しく実装する責任があり、カタログはアクティブなクライアント（識別子の発行を含む）およびブロードキャストメッセージのリストを管理する役割を担います。 ここでこのストーブから踊ります。

ジオリファレンス

ここで、各論理部分は、ASFコンポーネント間の一致を見つける必要があります。 主な制限は、ASFに存在する最小の自己記述コードと最大の機能です。

TCPサーバー

TCPサーバーには状態がなく、ASFクラスターの各ノードに1つのインスタンスが必要です-明らかに、これはステートレスサービスです （前の記事で説明したので、繰り返しません）。

ユーザー

ADCチームとクライアントとのやり取りをアクターに委ねます。

俳優

奇妙なことに、科学者の環境から俳優モデル（俳優モデル）が登場しました（しかし、1973年には当時のコンピューターサイエンスにとって驚くべきことではありませんでした）。 このモデルによると、エンティティとは、（原則として）状態を持ち、他のアクターとは独立して機能し、非同期でメッセージを送受信でき、他のアクターも作成できる特定のエンティティです。 アクターのセット（またはシステム）は、異なるタイプのアクターを結合できます。 各アクターには、メッセージング用の特別なアドレス（通常は数値またはテキスト）があります。 すべてのアクターは並行して動作し、メッセージングは​​非同期ですが、これらのメッセージの処理はシーケンシャルです-アクターは「シングルスレッド」であり、同期ポイントとして機能し、一度に最大1つのメッセージを処理します。

この投機的モデルはさまざまな方法で実装できます。Akka.NET 、 Orleans 、ASFアクターの3つの異なる実装があります。 Akka.NETでは、アクターの作成、システムからのアクターの削除、およびアクターへのメッセージの送信が明確に区別されます。 Akka.NETアクターは階層を形成するため、「親」は「子供」の行動を監視できます。 OrleansとASFは異なるパスを取りました- 分散仮想アクターのフラットモデルを採用しました。このモデルでは 、すべてのアクターが常に存在しますが、暗黙的な状態での最初の呼び出しまで。 呼び出されると、アクターが作成され、その状態がリブート間で維持されます。 非同期メッセージングは​​C＃インターフェイスの呼び出しによってモデル化され、Orleansでの完全な「ガルバニック分離」のために、Pub-Subを実装する永続的なストリームがあります。 ASF Streamsはサポートしていませんが、サブスクライブできるアクターイベントがあります。 （Akka.NETのように）アクターの削除とその状態のクリアがあります-削除後、アクターは次の呼び出しの前に再び「影の世界」に入ります。 ご覧のように、すべての実装で同様の機能と異なる機能があります。

奇妙なことに、質問はかなり頻繁にあります-ASFアクターはASFサービスとどう違うのですか？ 参照してください-サービスインスタンスはクラスターの開始時に一度作成され、ASFが停止または再起動するまで機能し、外部および/または内部の通信ポイントを持ちます。 アクターは外部リクエストによって作成および削除され、その数はクラスターの物理的な能力によってのみ制限されます。 したがって、作業中に動的に変更されるオブジェクトのコレクション（異なるタイプの可能性がある）を実装する必要がある場合、これらはアクターです。 事前に既知の数のオブジェクトを作成する必要がある場合、特にこれらのオブジェクトが外部通信または内部機能を実装している場合、これらはサービスです。 また、アクターは呼び出しを順番に処理し、サービスを並行して処理することを覚えておくことが重要です。

ユーザーディレクトリ

コンポーネントに戻る-アクティブなクライアントのカタログについては、 ステートフルサービスを選択するのが論理的です。

ステートフルサービス

つまり、ステートフルサービスはステートレスと同じですが、ステートがあります。 実際、それらのライフサイクルは似ています-同じOnOpen、OnClose、およびRunAsyncです。 コミュニケーションのリスナー、ASF Remotingなども可能ですが、状態の存在によって顕著な違いが生じます。 まず第一に、これらは用語の違いです。ステートレスサービスのインスタンスについて話すことが理にかなっている場合、ステートフルサービスにはレプリカがあります。 レプリカはレプリカセットに結合されます。各レプリカセットには、このサービスの他のセットとは無関係に独自の状態があります。 各セットでは、1つのレプリカのみがプライマリであり、残りはセカンダリです。プライマリレプリカのみが状態を変更でき（それに対してのみライフサイクル関数が呼び出されます）、残りはすべて状態を読み取ります。 サービスがパーティション化されている場合、各パーティションはそのようなレプリカのセットであり、したがって、独自の個別の状態になります。 パーティションとレプリカの数の両方が、アプリケーション構成を通じて（ステートレスサービスの場合と同様に）そこに設定されます。 プライマリレプリカが落ちた場合、セカンダリレプリカの1つがこの役割を引き継ぎます。したがって、信頼性のために、ASFはクラスターノードに沿って同じセットのすべてのレプリカを分散し、サービスステータスがノード間で複製されます。 IReliableStateインターフェイスから派生したオブジェクトのみを状態に保存できます。 インターフェイス自体はトークン1に似ているため、実際に実装することは不可能であるため、箱から出してすぐに使用できる信頼できるオブジェクトは、ReliableDictionaryとReliableQueue（辞書とFIFOキュー）の2つだけです。 トランザクションを使用して、いくつかの信頼できるオブジェクトの変更を同期できます。

合計：

悪魔の詳細

ブレーンストーミングは終了しました。考え出されたすべての実装に移りましょう。 ここでは、技術的な詳細に入ることを避け、一般的な説明と薄い場所に自分自身を制限し、必要に応じて、好奇心reader盛な読者がソースコードを直接参照できるようにします（記事の最後にリンクがあります）。

だから、順番に。

TCPサーバー

TCPサーバーの場合、標準のTcpListener / TcpClientを使用できます。これは、非標準のTcpCommuncationListenerにラップされます。 TcpListenerはOpenAsyncで開始し、CloseAsyncで停止します。 TcpCommuncationListenerはCreateServiceInstanceListenersに作成されます。

設定には小さな詳細があります-Local.xmlでのローカルデバッグ用に設定しました

  <パラメーター名= "TcpServer_InstanceCount"値= "1" /> 

、Azureのパラメーターは

  <パラメータ名= "TcpServer_InstanceCount"値= "-1" /> 

これは、デバッグクラスターのノードが同じコンピューター上でローカルに起動され、それらの間で411ポートを共有できないため、必要なサービスインスタンスは1つだけです。 「-1」は、ASFクラスターの各ノードでサービスの1つのインスタンスが実行されている必要があることを意味します。Azureでは、ASFノードは異なるVMにあり、それぞれ独自の411ポートを持っています。

適切な俳優に連絡する方法と彼の住所は何ですか？ これについては、アクターの実装でさらに説明しますが、現時点では（予測可能ですが）最初の問題は、TCP接続の確立です。これにより、TcpClientのインスタンスが作成され、クライアントが接続するクラスターノードにしっかりと固定されます。 アクターはノード間を移動できますが、呼び出すのは難しくありません-アドレス指定可能ですが、アクターからTcpClientを呼び出す方法は？ 結局のところ、メッセージは受信と送信の両方を行う必要があります。 ステートレスサービス自体では不可能です。どのサービスインスタンスに必要なTcpClientが含まれているかはわかりません。 そして、アクターイベントが助けになります-TcpClientは、「その」アクターのイベントをサブスクライブし、それらを介して送信メッセージを受信できます（ストリームを好むが、何であるかを取得しようとします）。

ユーザー

アクターには、次のメッセージの受信と処理、およびクライアントへのメッセージ送信という2つの機能しかありません。 それでも、プロトコルのサポートを担当するのはアクターであるため、これはハブの最も複雑な部分です。 ニュートンの箱ではなく、熟考するものもあります。 最初に、アクターに対処する方法を選択する必要があります。 このプロトコルでは、クライアントはハブによって発行されるSIDによってアドレス指定されます。このSIDをASFアクターのアドレスとして使用しないのはなぜですか？ さらに、ADCは、ハブの4つのプロトコル状態-PROTOCOL（接続パラメーターのネゴシエーション）、IDENTIFY（クライアント情報）、VERIFY（パスワード検証）、NORMAL（通常操作）を想定しています。 ハブが開いているため、パスワードはなく、VERIFYは不要です。 また、ASFのアクターは仮想であるため、生きているように見えてもまだどこにも接続されていないアクターにUNKNOWN状態を追加することは理にかなっています。

問題の発生のこの部分で2つの問題が発生しました。 最初のメインは「シングルスレッド」アクターです。 正式には、これはアクターから別のオブジェクトを呼び出すことができることを意味しますが、この呼び出しからアクターをコールバックすることはできません。 実際、ASFはアクターの再入場を引き続きサポートしていますが、コールチェーンが彼から始まった場合のみです。 さらに、このような解決策は、アクター間の呼び出しにのみ適用されます。たとえば、アクターからサービスを呼び出して、アクターをコールバックすることはできません。 そして、そのような機能は、例えば、アクターが開始し、ディレクトリが実行されるブロードキャストのために必要であり、メッセージはメーリングリストの作者自身に送られるべきです。 良い解決策が見つからなかったので、アクターを2つの部分に分割しました。1つはクライアントからメッセージを受信して​​アクターの状態を制御し、2つ目はクライアントにメッセージを送信するだけです。 その結果、単方向データストリームが通過する2つのアクターがあります。 アクターのタイプは異なるため、SIDを介して等しくアドレッシングできます（ASFでは、アクターのタイプはそのアドレスに含まれているため、同じSIDでもアクターのアドレスは異なります）。

2番目の問題は、接続セットアップ時間です（ADCの用語では、これはNORMAL状態への移行です）。 それを制限することは理にかなっており、DCの前駆体が同じポートを使用し、ハブが最初のメッセージをDCに送信するという事実によって状況が悪化します。 その結果、接続しているDCクライアントは、2番目の出現まで応答を待ちます。 次は、ASF タイマーとアラームを適用します。

タイマーとリマインダー

ASFのタイマーとアラームは、その名前が示すように、アラームとして機能します。 これらは似ていますが、指定された間隔に従って指定された関数を呼び出すという点のみが異なります。 タイマーは、アクティブなアクターにのみ存在するより軽量なオブジェクトであり、アクターが非アクティブ化されると消えます。 リマインダーは保存され、アクターとは別に機能するため、非アクティブ化されたアクターでもアクティブ化できます。 他のすべてのタイマーやリマインダーのアクターメソッドの呼び出しは、依然として「シングルスレッド」ですが、リマインダーからの呼び出しは「本格的な」呼び出しと見なされ、非アクティブなアクターを非アクティブ化するときに考慮されます。 アクターを使用するタイマーからの呼び出しは考慮されないため、アクターがタイマーで非アクティブになるのを防ぐことはできません。

接続時間を制限するには、疑似ADCコマンドConnectionTimedOutを送信する1回限りのリマインダーを使用するのが最も簡単です。NORMAL状態は単純にそれを飲み込み、他のすべてはプロトコルに従って接続を切断します。

ユーザーディレクトリ

このサービスには外部通信がなく、内部タスクの実行のみを目的としているため、 Remotingを使用して通信することは論理的です。 ディレクトリのパーティション化はあまり意味がありません-サービスの状態は識別子のコレクションを保存し、サービス自体は全体としてオペレーションを実装します。 ただし、ブロードキャストにより、1つのプライマリサービスレプリカでは不十分な負荷が発生する可能性があります。 また、ここでは、ステートフルサービスの好奇心feature盛な機能を利用できます。セカンダリレプリカでもリスナーを開くことができますが、読み取り専用です。 カタログ状態のメールは何も変更しないため、すべてのサービスレプリカを使用することを妨げるものは何もありません。

現在のSIDのリストはReliableDictionaryに格納されます-トランザクション内で列挙でき、ユーザー情報（名前、サポートされているクライアント機能など）がキー値に格納されます。 別のReliableDictionaryを使用して、値のない一意のキーのように、クライアントの名前の一意性を確認する必要があります。 カタログの開発には特別な熊手はありませんでしたが、クライアントの切断に関連するニュアンスがあります。

クライアントを切断する理由は2つしかありません。これは、通信チャネルのエラー（ソース-TCPサーバー）とプロトコルのエラー（ソース-アクター）です。 両方のエラーは致命的と見なされ、クライアントから切断されます。 エラーを一元的に処理したいのですが、プロトコルの責任者としてアクターでこれを行うのが論理的です。 これを行うには、リマインダーと同じことを行うことができます-別の疑似ADCメッセージDisconnectOccuredを追加し、それをアクターのステートマシンに含めます。 完全にクリーニングするには、アクターを完全に削除するのが良いでしょうが、シャットダウンのイニシエーターがアクター自身である場合、これを行う方法はありますか？ この機能は、ReliableQueueを使用するディレクトリに転送できます。このキューには、切断されたクライアントのSIDが追加されます。RunAsyncディレクトリでは、このキューはキューから識別子を受け取り、対応するアクターを削除する無限ループで処理されます。

そのような状態は次のとおりです。

そして一般的に、開発は終わりました。 ローカルクラスタでのテストでは、焼きたてのハブに2つのADCクライアント（AirDC ++を使用）が相互に接続し、ファイルを交換できました。 大丈夫ですが、すでにAzureにハブを展開してみてください。

Azureの展開

展開はメモのようなものだったため、ストーリーの最も退屈な部分です。 無料試用版サブスクリプションを使用して展開した場合、ASF管理は新しいポータルから利用できます 。 最初に、クラスター名、RDPユーザーデータ、リソースグループ、および場所を選択します。 「プライマリノードタイプの5つ未満の初期VM容量を選択すると、このクラスターがテストクラスターとして指定されます。」-テストクラスターが何であるかが見つかりませんでしたが、ポータル自体がこの推奨事項を記述しているためです。 カスタムエンドポイントでは、ロードバランサーがこのポートで接続を渡すように411を忘れずにインストールする必要があります。 テスト目的では、安全でないクラスターを作成する方が簡単です-それだけです。 ASFクラスターは明らかに単純ですが、Azureは次のようなリソースセット全体を作成します。

リストには、VMのvhdストレージ（3ではなく5が存在する理由は明らかではありません）、Azure Diagnosticsのログおよび情報のストレージ、VPNに統合された仮想マシンのセットが含まれ、これらすべてにパブリックIPアドレスが割り当てられたロードバランサーが含まれます。

Azureでの展開により、1つの問題が明らかになりましたが、解決できませんでした。 Azureは411ポートの可用性をチェックし、その上でTCP接続を作成してすぐに切断するようです。 接続が発生するとすぐに、TCPサーバーはSIDを作成しますが、SIDはすぐに不要になります。 理論的には、これは正しい動作です-サーバーがいっぱいになる可能性があります（ADCでは1つのハブのユーザー数に制限があります）が、実際にはこのアプローチは失敗します。 一方、単純な検証では、これらの空の接続は頻繁に行われます-一般的に、暗闇に覆われた謎である限り。

ただし、これは機能に影響を与えないので、テスト、再び2つのADCクライアント、再びファイル共有-すべてが機能しているようです。 今、絶対に乾杯。

おわりに

一般に、このアイデアは成果を上げました。ASF全体を調べて、関与していなければ、少なくともさまざまな機能とその機能の詳細に精通することができました。 また、すべてがASFでスムーズに実行されたわけではありませんが、最終結果はテストプロジェクトにとってそれほど悪くはありません。 読者が好奇心that盛であることを願っています。 プロジェクト全体のソースコードはGitHubにあります。新しい記事に別れを告げます。