分散アプリケーションの構成要素。 最初のアプローチ

過去に статье 私たちはリアクティブ アーキテクチャの理論的基礎を検討しました。データ フロー、リアクティブな Erlang/Elixir システムの実装方法、およびそれらのメッセージング パターンについて話す時期が来ました。

• リクエストとレスポンス
• リクエストのチャンク化されたレスポンス
• リクエストを含むレスポンス
• パブリッシュ/サブスクライブ
• 反転パブリッシュ/サブスクライブ
• タスクの分散

SOA、MSA、およびメッセージング

SOA、MSA はシステムを構築するためのルールを定義するシステム アーキテクチャであり、メッセージングは​​その実装のためのプリミティブを提供します。

あれこれのシステム アーキテクチャを宣伝するつもりはありません。私は、特定のプロジェクトやビジネスに最も効果的で役立つ実践方法を使用することに賛成です。どのようなパラダイムを選択するにしても、Unix 方式を念頭に置いてシステム ブロックを作成することをお勧めします。つまり、コンポーネントは接続性が最小限で、個々のエンティティを担当します。 API メソッドは、エンティティに対して最も単純なアクションを実行します。

メッセージングは​​、名前が示すように、メッセージ ブローカーです。その主な目的はメッセージを送受信することです。情報を送信するためのインターフェイス、システム内で情報を送信するための論理チャネルの形成、ルーティングとバランシング、およびシステム レベルでの障害処理を担当します。
私たちが開発しているメッセージングは​​、rabbitmq と競合したり置き換えたりしようとするものではありません。その主な特徴:

• 分布。
  Exchange ポイントは、すべてのクラスター ノード上で、それを使用するコードのできるだけ近くに作成できます。
• シンプル。
  定型コードの最小化と使いやすさに重点を置きます。
• よりよい性能。
  ここでは、rabbitmq の機能を繰り返すつもりはありませんが、アーキテクチャ層とトランスポート層のみを強調し、コストを最小限に抑えるために、これらの層を可能な限り単純に OTP に適合させます。
• 柔軟性。
  各サービスは、多くの交換テンプレートを組み合わせることができます。
• 設計による復元力。
• スケーラビリティ。
  メッセージングは​​アプリケーションとともに成長します。負荷が増加した場合、交換ポイントを個々のマシンに移動できます。

備考 コード構成の観点から見ると、メタプロジェクトは複雑な Erlang/Elixir システムに適しています。すべてのプロジェクト コードは XNUMX つのリポジトリ、つまりアンブレラ プロジェクトに配置されます。同時に、マイクロサービスは最大限に分離され、別個のエンティティを担当する単純な操作を実行します。このアプローチを使用すると、システム全体の API の保守が容易になり、変更も容易になり、単体テストや統合テストの作成も容易になります。

システム コンポーネントは、直接またはブローカーを介して対話します。メッセージングの観点から見ると、各サービスにはいくつかのライフ フェーズがあります。

• サービスの初期化。
  この段階では、サービスを実行するプロセスと依存関係が構成され、起動されます。
• 交換ポイントの作成。
  サービスは、ノード構成で指定された静的な交換ポイントを使用することも、交換ポイントを動的に作成することもできます。
• サービス登録。
  サービスがリクエストに対応するには、交換ポイントにサービスを登録する必要があります。
• 正常に機能しています。
  このサービスは有益な作品を生み出します。
• シャットダウン。
  シャットダウンには通常と緊急の 2 種類があります。通常の運用中、サービスは交換ポイントから切断され、停止します。緊急事態では、メッセージングによってフェイルオーバー スクリプトの XNUMX つが実行されます。

かなり複雑に見えますが、コードはそれほど怖いものではありません。コメント付きのコード例は、少し後のテンプレートの分析で示されます。

交換について

Exchange ポイントは、メッセージング テンプレート内のコンポーネントとの対話ロジックを実装するメッセージング プロセスです。以下に示すすべての例では、コンポーネントは交換ポイントを通じて対話し、その組み合わせによってメッセージングが形成されます。

メッセージ交換パターン (MEP)

世界的に、交換パターンは双方向と一方向に分類できます。前者は受信メッセージへの応答を意味しますが、後者はそうではありません。クライアント/サーバー アーキテクチャにおける双方向パターンの典型的な例は、要求/応答パターンです。テンプレートとその変更を見てみましょう。

リクエスト/レスポンスまたは RPC

RPC は、別のプロセスから応答を受け取る必要がある場合に使用されます。このプロセスは同じノード上で実行されているか、別の大陸にある可能性があります。以下は、メッセージングを介したクライアントとサーバー間の対話の図です。

メッセージングは​​完全に非同期であるため、クライアントにとって交換は 2 つのフェーズに分割されます。

1. リクエストの送信

   messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).

   応募者と ‒ 交換ポイントの一意の名前
   応答マッチングタグ - 応答を処理するためのローカルラベル。たとえば、異なるユーザーに属する複数の同一のリクエストを送信する場合です。
   リクエスト定義 - リクエスト本文
   ハンドラープロセス - ハンドラーの PID。このプロセスはサーバーから応答を受け取ります。

2. 応答を処理しています

   handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)

   応答ペイロード - サーバーの応答。

サーバーの場合も、プロセスは 2 つのフェーズで構成されます。

1. 交換ポイントの初期化
2. 受信したリクエストの処理

このテンプレートをコードで説明してみましょう。単一の正確な時刻メソッドを提供する単純なサービスを実装する必要があるとします。

サーバーコード

api.hrl でサービス API を定義しましょう。

%% =====================================================
%%  entities
%% =====================================================
-record(time, {
  unixtime :: non_neg_integer(),
  datetime :: binary()
}).

-record(time_error, {
  code :: non_neg_integer(),
  error :: term()
}).

%% =====================================================
%%  methods
%% =====================================================
-record(time_req, {
  opts :: term()
}).
-record(time_resp, {
  result :: #time{} | #time_error{}
}).

time_controller.erl でサービス コントローラーを定義しましょう

%% В примере показан только значимый код. Вставив его в шаблон gen_server можно получить рабочий сервис.

%% инициализация gen_server
init(Args) ->
  %% подключение к точке обмена
  messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())
  {ok, #{}}.

%% обработка события потери связи с точкой обмена. Это же событие приходит, если точка обмена еще не запустилась.
handle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->
  erlang:send(self(), monitor_exchange),
  {noreply, State};

%% обработка API
handle_info(#time_req{opts = _Opts}, State) ->
  messaging:response_once(Client, #time_resp{
result = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())}
  });
  {noreply, State};

%% завершение работы gen_server
terminate(_Reason, _State) ->
  messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),
  ok.

クライアントコード

サービスにリクエストを送信するには、クライアントのどこからでもメッセージング リクエスト API を呼び出すことができます。

case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of
    ok -> ok;
    _ -> %% repeat or fail logic
end

分散システムでは、コンポーネントの構成が大きく異なる可能性があり、リクエストの時点ではメッセージングがまだ開始されていないか、サービス コントローラーがリクエストを処理する準備ができていない可能性があります。したがって、メッセージングの応答を確認し、失敗した場合に対処する必要があります。
送信が成功すると、クライアントはサービスから応答またはエラーを受け取ります。
handle_info で両方のケースを処理しましょう。

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) ->
  ?debugVal(Utime),
  {noreply, State};

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) ->
  ?debugVal({error, ErrorCode}),
  {noreply, State};

リクエストのチャンク化されたレスポンス

巨大なメッセージの送信は避けるのが最善です。システム全体の応答性と安定した動作はこれに依存します。クエリへの応答が大量のメモリを消費する場合、応答を複数の部分に分割することが必須です。

そのような場合の例をいくつか挙げてみましょう。

• コンポーネントはファイルなどのバイナリ データを交換します。応答を小さな部分に分割すると、あらゆるサイズのファイルを効率的に処理し、メモリ オーバーフローを回避できます。
• リスト。たとえば、データベース内の巨大なテーブルからすべてのレコードを選択し、それらを別のコンポーネントに転送する必要があります。

私はこれらの反応を機関車と呼んでいます。いずれの場合も、1024 MB のメッセージを 1 個送信するほうが、1 GB のメッセージを XNUMX つ送信するよりも優れています。

Erlang クラスターでは、応答が交換ポイントをバイパスして直ちに受信者に送信されるため、交換ポイントとネットワークの負荷が軽減されるという追加の利点も得られます。

リクエストを含むレスポンス

これは、ダイアログ システムを構築するための RPC パターンのかなり珍しい変更です。

パブリッシュ/サブスクライブ (データ分散ツリー)

イベント駆動型システムは、データの準備が整うとすぐに消費者にデータを配信します。したがって、システムはプル モデルやポーリング モデルよりもプッシュ モデルの傾向が高くなります。この機能を使用すると、常にデータを要求して待機することによるリソースの無駄を回避できます。
この図は、特定のトピックにサブスクライブしているコンシューマにメッセージを配布するプロセスを示しています。

このパターンを使用する典型的な例は、状態の分布です。コンピューター ゲームのゲーム世界、取引所の市場データ、データ フィードの有用な情報です。

加入者コードを見てみましょう。

init(_Args) ->
  %% подписываемся на обменник, ключ = key
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {ok, #{}}.

handle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->
  %% если точка обмена недоступна, то пытаемся переподключиться
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {noreply, State};

%% обрабатываем пришедшие сообщения
handle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->
  ?debugVal(Msg),
  {noreply, State};

%% при остановке потребителя - отключаемся от точки обмена
terminate(_Reason, _State) ->
  messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),
  ok.

ソースは関数を呼び出して、都合の良い場所にメッセージをパブリッシュできます。

messaging:publish_message(Exchange, Key, Message).

応募者と - 交換ポイントの名前、
キー - ルーティングキー
メッセージ - ペイロード

反転パブリッシュ/サブスクライブ

pub-subを展開するとロギングに便利なパターンを取得できます。ソースとコンシューマのセットはまったく異なる場合があります。この図は、XNUMX 人のコンシューマと複数のソースのケースを示しています。

タスクの分散パターン

ほぼすべてのプロジェクトには、レポートの生成、通知の配信、サードパーティ システムからのデータの取得などの遅延処理タスクが含まれます。これらのタスクを実行するシステムのスループットは、ハンドラーを追加することで簡単に拡張できます。残っているのは、プロセッサのクラスタを形成し、プロセッサ間でタスクを均等に分散することだけです。

3 つのハンドラーの例を使用して、発生する状況を見てみましょう。タスク分散の段階でも、分散の公平性やハンドラのオーバーフローの問題が生じます。ラウンドロビン分散は公平性を保ち、ハンドラーのオーバーフローの状況を避けるために、制限を導入します。 プリフェッチ制限。過渡状態では プリフェッチ制限 XNUMX つのハンドラーがすべてのタスクを受信できなくなります。

メッセージングは​​キューと処理の優先順位を管理します。プロセッサはタスクが到着するとそれを受け取ります。タスクは正常に完了する場合もあれば、失敗する場合もあります。

• messaging:ack(Tack) - メッセージが正常に処理された場合に呼び出されます
• messaging:nack(Tack) - すべての緊急事態に呼び出されます。タスクが返されると、メッセージングは​​それを別のハンドラーに渡します。

1 つのタスクの処理中に複雑な障害が発生したとします。プロセッサ 3 は、タスクを受信した後、交換ポイントに何も報告する時間がないままクラッシュしました。この場合、交換ポイントは、ack タイムアウトが経過した後、タスクを別のハンドラーに転送します。何らかの理由でハンドラー XNUMX がタスクを放棄し、Nack を送信したため、タスクも別のハンドラーに転送され、タスクは正常に完了しました。

予備結果

私たちは分散システムの基本的な構成要素をカバーし、Erlang/Elixir でのそれらの使用についての基本的な理解を獲得しました。

基本的なパターンを組み合わせることで、新たな問題を解決するための複雑なパラダイムを構築できます。

シリーズの最後の部分では、サービスの編成、ルーティング、バランシングに関する一般的な問題を検討し、システムのスケーラビリティとフォールト トレランスの実際的な側面についても説明します。

第二部の終わり。

フォト マリウス・クリステンセン
websequencediagrams.com を使用して作成されたイラスト

出所： habr.com