Akka short introduction - nloutas/akkacluster GitHub Wiki

Actor model based on Reactive principles

  • Decoupling: distributed architecture, microservices
  • Responsiveness: fast and consistent
  • Fault-tolerance/Resilience: bulk-heading, throttling, work delegation
  • Elasticity/Scalability: reactive resource allocation (scale-in and scale-out) according to current load
  • Message Driven: Inherent queuing mechanism with back-pressure and asynchronous processing, non-blocking communication

Decoupling

Any component of the application can be deployed in a separate node with distinct "local" actor system (participating in the overall Cluster or connecting through Akka Remote) running on an own JVM with separate resources (CPU, memory etc.) This level of flexibility addresses all levels of software development issues

  • Maintainability: easy to apply, test and verify changes on the separate component with lesser risk of problem in the integration phase. This enables continuous refactoring as such.
  • Deployability: flexible deployment of changed component. So far as the common message API has not changed, the new code may be deployed in the component node without affecting other nodes, especially if message queuing is reasonably handled (unprocessed messages are persisted and the queue is restored after a node restart or the unanswered messages are resent from the other nodes). This enables continuous delivery and deployment as such.

Responsiveness and Resilience

Due to the parallelism of the Actor model, where the system brings up as many of the lightweight actors as needed to do their bit of processing and given a reasonable supervision strategy, where failing actors are restarted with no harm done (provided any existing state is taken care of through persistency), the system can be very responsive and provide reliably a consistent throughput and fine quality of service

There are plenty of mechanisms to handle sudden spikes of workload and unpredictable failures due to lack of running resources. This is enshrined in the akka motto "let it crash".

  • Bulk-heading in Akka is done by defining separate (hopefully fine-tuned) dispatchers for problematic actors (i.e. actors performing potentially blocking work like I/O or DB accessing). Each dispatcher gets a separate thread pool and the rest of the actor system is not blocked by delays and problems in the actors under heavy load
  • Throttling: the message queuing aspect of akka allows for circuit breakers, mailbox size limits (message overflow goes to "dead letters"), message timeout limits on the sender's side, even a custom Deadline attribute may be added to a message to immediatelly stop processing at the receiver's side. All of these can be useful tools to implement throttling patterns and maintain some responsiveness from an overloaded system
  • Work delegation: actual processing work can be delegated to multiple separate actors doing their bit and returning a result message. A well-defined hierarchy with appropriate supervision strategies and watches on critical actors allow for graceful handling of actor failures and similar problems.

Elasticity

As stated above in the "Decoupling" section, akka clustering offers great elasticity in the deployment of participating nodes. Each type of node is configured with a set of roles it can play in the cluster and the akka routing mechanisms drives the traffic accordingly, so that nodes of a given type can be added (scale-out) when the load is heavy or removed (scale-in) when the load subsides. There are various monitoring tools (for example akka offers the akka-cluster-metrics extension) to streamline the process and make informed desicions about scaling the cluster as needed.

Message Driven

The actor model is inherently message-driven, so that communication can be asynchronous, non-blocking and highly performant. Message communication to remote nodes is handled transparently, while the routing can be explicitly configured and fine-tuned according to specific requirements.