The Actor Model is one of the most interesting models I've seen so far. It's designed for high concurrency, scalability and fault tolerance. Most programming languages have a framework that implements it, but some programming languages like Erlang/Elixir are designed with this model in mind.
History
The actor model was created in 1973, inspired by physics and some programming languages like Smalltalk, Lisp and others. It was designed to handle highly parallel computer machines consisting of dozens, hundreds, or even thousands of independent microprocessors, each with its own local memory and communications processor, communicating via a high-performance communications network.
Fundamentals concepts
In Object-Oriented Programming, we treat everything as an object, in the actor model we treat everything as an actor.
Actor
It treats the actor as a basic block of concurrency, where an actor reacts to a message, by changing your states, modifying our behaviour for the next message, and sending more messages. In other words, an actor can:
- Send a finite number of messages to other actors
- Create a finite number of new actors
- Designate the behaviour to be used for the next message it receives.
Message
Message is a unit of communication between actors, a message should be serializable and be transmitted over networks.
Mailbox
The mailbox is how an actor reads messages, every message it receives goes to a mailbox, typically Actor System uses FIFO(First-In First-Out) but depending on the case, we can implement a Mailbox using a different approach if you need, for example, to prioritize a message over other
State
State it's the actor state, it can be read from other actors, but only the actor itself can modify your state.
Behaviours
The behaviour is how an actor will react to a message.
PID or Actor Reference
Process Identification (PID) or Actor Reference is the actor's address. Using this address an actor can send a message to another actor. This address can be local or on the remote machine.
Supervision
Supervision is how the Actor Model coordinates your tasks and ensures resilience.
So imagine, you create an actor and you ask to that actor do an action and it fails to do it, how are you going to handle this failure? Should you retry? Should you stop the all process? Should you stop only that actor?
When the actor fails it'll emit a signal to the supervisor and it decides what to do, stop only that actor (One-For-One), stop all children actors (All-For-One) or send the signal to its supervisor and let the layer above decide what to do. All actors are supervisors.
Virtual Actor/Grain
The virtual actor is a concept created by Microsoft on the Orleans project where you don't need to know the Actor ID, you will have a unique identifier and the actor framework will find the corresponding actor (or create a new one if case it doesn't find it).
Virtual Actor seems to fit very well with DDD and event source, where you can use the Actor ID as the Domain ID, and the message you received you can store in some database, so when you load the domain you can easily reply to all message to get the current state (or save the state as a snapshot).
Framework
The framework to use the Actor Model will depend on the programming language, I can only talk about it for C#
Microsoft Orleans
Microsoft Orleans is an Actor Model implementation from Microsoft, but it doesn't implement the Actor Model completely, only the Virtual Actor, also Microsoft decided to change some terms, like Silos = Node, Grain = Virtual Actor. One advantage of Microsoft Orleans is it's very easy to use and requires a minimal setup, but it doesn't implement the supervision like it's described in the book, so you have less flexibility.
Akka
Akka.net is a good framework (it's a port from Java), it has almost all concepts of the Actor Model, is very flexible and seems easy to use. The main disadvantage is Akka doesn't implement a Virtual Actor Model, so if you want to implement DDD with Akka, it can be a challenge to mimic the Virtual Actor Model.
Proto.Actor
Proto.Actor is the best framework for the Actor Model (you can use it with Go), it is implemented by the book (like Akka) Actor Model and supports the Virtual Actor Model (like Orleans). I would give a change for this framework
Elixir/Erlang
Elixir/Erlang is based on BEAM VM, which is based on the Actor Model, so you won't need any framework. Because the Virtual Actor model is a kind of new concept Elixir doesn't have native support for it, so you need to use an external library. I highly recommend you study about them
Conclusion
The actor model is very interesting, if you are also interested in it I recommend that you look deep. We use the actor model to create high-scale applications and it can be combined with Domain-Driven Design, Event Source and CQRS, in the next article I'll explorer how we can combine them and another aspect of the Actor Model.
References
https://proto.actor/docs/actors/
https://doc.akka.io/libraries/akka-core/current/general/actors.html
Top comments (0)