アクターベースのシステムを構築するための設計パターン/ベストプラクティス
アクターベースのアプリの構築に使用すべきデザインパターン、ベストプラクティス、または優れた基本的なアーキテクチャの原則への適切なリンクを見つけるのに苦労しています。私が知っているそれらのいくつかは：
ブログの投稿、記事、WIKI、ガイド
- OTP設計原則ユーザーズガイド
- エンタープライズ統合のパターンとベストプラクティス （一般に、任意のメッセージ駆動型アーキテクチャに適用できます）
- 一連の 俳優によるデザインの状態の扱いに関するJames Iryによる投稿
- 一連の Scala俳優 のデザインに関する投稿）== by Ittay Dror
- 同時実行パターン ウィキペディアの記事
- スケーラブルなシステム設計パターン （アクターとは直接関係ありませんが、非常に便利です）
- アクターの同時実行性について pt.1 、 pt.2 by Alex Miller
論文
- 信頼できる分散システムを作成する際の混乱 by Joe Armstrong
- Scalabale Component Abstractions Philipp HallerおよびMartin Odersky
- 制御の反転を伴わないイベントベースのプログラミング Martin OderskyおよびMatthias Zengerによる
- マルチヘッドのメッセージ受信パターンを持つ俳優 by Martin Sulzmann
本
- Actors In Scala Philipp HallerおよびFrank Sommers
- プログラミングErlang ジョー・アームストロング
- ErlangとOTPの動作 マーティンローガン、エリックメリット、リチャードカールソン
実装
- Akkaフレームワーク （Scalaでのアクターの代替実装と、いくつかのErlang動作のポートと、アクターのための他の関連するパターンの多く）
- Scalaz Actors （俳優の構成、戦略、約束）
プレゼンテーション
- Actor Thinking by Dale Schumacher
- 1000年前のデザインパターン by Ulf Wiger
- 俳優ベースのプログラミング by Jamie Ridgway
- ШколаАктерскогоМастерства Vasil Remeniuk
Highscalability.comの例
- シンプルキューイングサービス（SQS）-このサービスは、メッセージを格納するためのインターネットスケールキューイングサービスを提供します。分散型アクターは作業を待ち行列に入れ、作業を待ち行列から外します。典型的な使用：集中型作業キュー。ジョブをキューに入れると、さまざまなアクターがキューの作業をポップして、CPU時間を取得したときにそれらを処理できます。スケーラビリティの一部。プロデューサーとコンシューマーをいくつでも持つ。あなたはそれを心配する必要はありません。キューは、複数のマシンと複数のデータセンターに分散しています。
これは 前の質問 に関連していますが、そうでない場合はまったく同じです同じです！
同時実行のactorモデルを使用すると、ステートフルな単一VMアプリケーションから（いくつかの別個のアクタークラス）から、アクタークラスの数千のインスタンスのステートレスクラスターに。
ただし、基本原則は同じです。
- 俳優の状態を公開しないでください
- 不変のメッセージを渡すだけで通信する
私は アクター開発の学習 にブログを投稿しましたScala=数週間前。これは、数年の経験に基づいた、ベストプラクティスと避けるべきことの投稿ですパラダイムで。
本「Reactive Design Patterns」はマニングで作成中です。