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. > 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 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. 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). Just my 2 cents 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.
