Thanks for the feedback! Regards, Stefan
On Tuesday, January 3, 2017 at 1:19:02 PM UTC+1, Patrik Nordwall wrote: > > In general we recommend one Akka cluster per microservice and something > else than Akka remoting/clustering for communication between different > microservices, such as http or message broker. That gives best deployment > isolation. Any general recommendation has exceptions of course, e.g. the > convenience of using one Akka cluster for a few coupled microservices might > be more important than the drawbacks. > > Regards, > Patrik > > On Mon, Jan 2, 2017 at 3:30 PM, Stefan Larsson <[email protected] > <javascript:>> wrote: > >> Hi, >> >> I'm new to Akka and need some advice on architecture to migrate a set of >> "legacy" components to Akka. >> >> I have two existing microservices-based components which I'm considering >> to modify to use Akka actors and clustering. It's currently load-balanced >> across multiple nodes each having an instance of the component, but >> sessions are not sticky to each user, so archived event state is cached in >> a Redis in-memory cache and persisted to MongoDB. As the components need >> some modifications anyhow to implement new features, thought it would be a >> good opportunity to migrate them to an Akka-based system where actors >> manage the state per-user to co-locate code and cache (remove Redis) while >> simplifying consistency and concurrency and not introduce "wrong-direction" >> dependencies between existing components. >> >> The system stores an archive of user events, both per-user and per-group >> events, which users can query. Seems Akka actors, remoting, clustering and >> ClusterSharding would be a good match. As part of the modifications, I was >> considering splitting it into two different front-end components (managing >> groups including archiving requests and per-user archive queries, >> respectively) and one back-end component (managing actual event archive >> storage and querying). The current front-end protocol is asynchronous (it's >> about XMPP server components). >> >> Would it be feasible to have three or four separate components (each one >> with separate source code repositories and separate deployments) sharing a >> single Akka cluster using Akka remoting to query the back-end? Or should I >> look into using a more traditional HTTP-based REST endpoints, possibly >> using Lagom? Will deploying application upgrades without downtime, >> monitoring and operations be more difficult with the first approach? I only >> found a few reference projects online using the shared Akka cluster >> approach, but it seems appealing to not introduce more remoting protocols >> than necessary and to use messaging throughout. >> >> Regards, >> Stefan >> >> -- >> >>>>>>>>>> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > Patrik Nordwall > Akka Tech Lead > Lightbend <http://www.lightbend.com/> - Reactive apps on the JVM > Twitter: @patriknw > > -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
