On Monday, June 15, 2015 at 1:57:23 PM UTC+1, Carsten Saathoff wrote: > > Am Samstag, 6. Juni 2015 00:24:16 UTC+2 schrieb Guido Medina: >> >> No, I have a single cluster, each micro-service is an Akka system that is >> subscribed to cluster events and once a system is up, it sends a message to >> every other node saying, hey, I'm here, lets exchange information, call it, >> synchronizing their cache. >> > > The draw back here is that having microservices within a single akka > cluster results in strong coupling between the services. All nodes need to > share at least the message classes that are used within an exchange. Of > course one could configure the serializer to work around that with > protobuf, e.g., but using REST APIs or message queues in between basically > result in higher decoupling of the microservices for less effort. And that > is usually something that you want. One often mentioned advantage of > microservice architectures is independence of the technology stack, which > is something that is sacrificed if we use Akka Cluster as the microservice > platform. >
Yes, I use a common project for things like that, but you can always fallback to Json and send/receive byte[] messages using Json with Jackson Smiley for an even faster performance, that's what I used do when I used RMQ, Hazelcast and JMS in general. Each project is different, I'm the only developer on my company at the moment so cost wise it was very easy for me to create a template Main class that starts the micro-service and join the cluster, create the deployables and have a friendly start/stop via standard JVM execution inside IntelliJ so for me, that type of "semi-automatic" cluster came handy for me and friendly of development is very valuable, I hate such development environments that to test/run something you have to follow 1000 steps, maybe I'm lazy :( > >> If you are not going to send messages (remotely) between systems then why >> use Akka at all? It is like, oh, I like Akka but I don't want to use its >> messaging system. That being the case then people should be afraid of CAP >> theorems, CRDTs, eventual consistent data and just use the good old >> messaging systems like RabbitMQ and relational DBs, etc, but then, they are >> not that safe anyway. >> > > Akka has other advantages than sending messages remotely. I would even > argue that there are much better approaches to sending messages around > remotely than using Akka. But, how do you guarantee message delivery? Do > you handle that in your application? Is that an issue at all in your > application? What do you do if one microservice is not available, i.e., how > do you ensure resilience? > I don't, if I can't deliver a message in time in the industry my application is built for I can't retry, I just fail-fast and report the error though it has never happened, there are pros and cons in the system I have built, like, adding nodes to the cluster will rebalance sharded components *-best efforts to keep order of supervisors associated with list of actors, I have my own sharding based on IDs that is fed via Cluster events-* and load-balanced components so my application is not so much designed for resiliency *-for now, I will add Hazelcast on top of the Akka cluster, so each Akka node will also be a Hazelcast node-* > >> I have my system running on a controlled environment and in production >> now for almost a month and I haven't lost a message, the bugs I have fixed >> have been related with my own code. Network failures are going to happen >> and in that case any system can fail so risk is only a relative word. >> > > My personal experience with Akka Cluster is that sending around large > amounts of messages between nodes will result in an unstable cluster. This > was also discussed in different threads on this mailing list. The messages > between nodes always go over the default TCP connection between different > actor systems. If that connection is occupied with application messages, it > means that system messages will take longer until received often rendering > the cluster instable. IIRC it was even a suggestion by the Akka team to use > a dedicated connection channel (e.g. HTTP or TCP via akka-io) to send > around large volumes of application messages. > My main problem is not with Akka cluster, I think that has been improved a lot, at least from version 2.3.11 and on, my main problem is with Akka remote that for such a great toolkit like Akka, I consider Akka remote extremely slow but I'm not giving up my hope on it, I can't, time is not on my side so I'll have to work around it somehow. > Akka Cluster is great technology, specifically features like cluster > sharding and the cluster singleton are extremely useful. But when it comes > to communicating between microservices, I usually use HTTP or queues like > RabbitMQ and Kafka, as they are technology independent, allow for loose > coupling of the microservices, and provide for additional features, such as > transparent proxying/load balancing (HTTP) or guaranteed > delivery/persistent messaging (Rabbit MQ). > I'm too afraid of cluttering my system with so many third party sub-systems, then I have to write more docs for the IT people, maybe, I eventually get there, in the meantime, Hazelcast dynamic cluster with programmatic auto joining and cluster creation will give me the backup with some TTL I need. > Just my 2 cents > My many thanks for your opinion, it is good to know different perspectives to a problem or set of problems ;-) > Carsten > > On Friday, June 5, 2015 at 12:21:36 PM UTC+1, wonderful world wrote: >>> >>> I have a BillingManager Bounded Context (DDD concept) whose job is to >>> charge the user for the orders they have placed. There is an OrderManager >>> that places the orders. They exist in two different Bounded Contexts. >>> >>> As per the DDD, one Bounded Context should interact with another Bounded >>> Context via messages or events only. I'm trying to understand the right >>> pattern for the integration of these BCs. Is the right pattern (1) the >>> OrderManager and the BillingManager live in the same actor system and they >>> interact each other via pub-sub? (2) OrderManager and BillingManager exist >>> in two actor systems, and the OrderManager actor system TELL the Billing >>> Manager to process the order (3) introduce a Bus or Queue so the >>> OrderManager queue up the orders and the BillingManager poll the queue to >>> retrieve orders and process them? >>> >>> What would you suggest? >>> >>> -- >>>>>>>>>> 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.
