Hey guys,
I would like to run an idea by the fine Akka community - which is to
discuss what it would take to turn Akka into a platform for building a
network of "microservices": each one independently redeployable and easy to
change, yet through a common platform, take advantage of the distributed
supervision, messaging and other goodies from Akka.
Here are some characteristics of such a platform:
-
Service discovery
-
Supporting different kinds of data flow topologies - request response,
as well as streaming data; pub-sub, etc.
-
Provide common abstractions for efficient data serialization
-
Support backpressure and flow control, to rate limit requests
-
Support easy scaling of each component, including routing of messages or
requests to multiple instances
-
Enable easy testing of multiple services (for example, see Akka’s
sbt-multi-jvm plugin)
-
A common platform for application metrics
-
Distributed message or request tracing, to help with visibility and
debugging
-
Support polyglot development - it should be possible to develop services
in different languages
I think many of these are already provided by Akka, but I wanted to run
through each one in more detail:
*Service Discovery*
Right now every actor talks to another actor location-transparently;
however, when looking up an external ActorRef, one does have to know the
mechanism, ie is it looking up in cluster, or remote, etc.... is it
another actorsystem etc... (this could have changed in 2.2 and 2.3, but
I'm not up to date :-p) What I'm looking for is a
mechanism-independent way of looking up actors, remote or not. IE, I
should just need to do this:
val downstreamActorRef = System.lookupByName(service = "tradingSystem",
actor = "masterTrader", ....)
Under the hood this looks up the actorRef using one of configurable
mechanisms:
- Akka Cluster is certainly one way to go, with nodes
- At work we use Zookeeper and Curator. It would be great to make this
platform support multiple discovery types
*Data Flow Topology*
- Akka is pretty good at this already, supporting many types of data flow.
The only concern I see is that you have to define the flow via the like of
routers and such, which are defined in the code on each node, rather than
externally via say a message queue (see ZMQ, NSQ etc). This can be
mitigated through DI and configuration and things like that, of course.
*Data Serialization*
If we are using native Akka protocol to talk over the wire, this is already
really good. One defines case classes, and Akka transparently serializes
them over the network if the actor is remote. This is one thing about Akka
that really appeals to me.
So the question is can we make this work for Play / Akka HTTP transparently
as well?
*Related - Polyglot support*
How would a Ruby/Python/etc process talk to an Akka network? My thoughts:
- Easiest way would be to have a way to automagically generate HTTP
endpoints that includes case class serialization to/from JSON. Type
classes to handle special data types.
- Did you guys define the Akka binary protocol and keep it stable?
Client libraries could then be written for different langauges, but this
doesn't solve the problem of message format -- Java serialization and
Chill/Kryo won't work.
*Backpressure and Flow Control*
Reactive streams looks really promising here. How it ties into routing,
topologies, etc. I'd like to find out more about.
Also, reactive streams won't work for request/response protocols.
*Application Metrics and Tracing*
Microservices means it becomes more and more important to figure out what's
going on across many services. Fortunately there's a lot of work in this
area; multiple third party libs to provide automatic metrics; somebody
wrote an Akka integration with Twitter's Dapper-like tracing system, and I
have written a tracing/graphing system as well.
*Hot Reloads*
I didn't include this in the list above, because the assumption is that
with lots of independent small services, they will be naturally easier to
redeploy. Some will argue that the JVM is heavyweight (actually I think a
lightly loaded JVM app is under 50MB, which is very reasonable), and will
want Erlang-style hot reloads of individual actors. This is really tricky
area though.
Anyways, I'd love to get the thoughts of the community about this idea of
using Akka as a "microservice" platform.
Thanks!
Evan
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
