Open vahidhedayati opened 5 years ago
Hi Vahid
Thanks for stepping by my humble playground project ;)
I'm aware since I added unit testing something got wrong and did not have time to fix it.
Regarding to your questions I think if you see my article
https://mfarache.github.io/mfarache/Building-microservices-Micronoaut/
I warned that using a Map to store the balance of customers was not a good idea. Quoted from my blog entry:
"In the implementation you will realize that I’m using a in-memory process Map to store the customer bills. We SHOULD be using a proper shared repository (ie, Mongo, KV store, ..whatever), otherwise each service will have its own tracking!!"
I made tests with multiple waiters and a single billing but not the other way around. However in a big bar it makes sense to have a lot cash drawer machines! .
I think I agree that sharing a database between different microservices is not a good idea, but i'm not sure that statement implies that multiple instances of the same microservice share a database instance. So really I would replace the Map with some Dao that connects to some KV storage. Shared memory could be accomplished with HazelCast IMDGor Infinispan or even using Vert.x bus, But really I would opt by a NoSQL storage (mongodb, redis, cassandra)
Another approach that spring to mind but more complex would be split responsabilities using CQRS event sourcing. We would segregate the responsibility between commands (write requests) and queries (read requests)
Imagine we have 3 billing services , in our bar analogy each of them would be a cash drawer machine.
When a new customer ask for a beer, only one of the instances is selected and a "Command" would be responsable to generate a event placed into a Kakfa stream for example. The event is consumed by addin the the money to the cash drawer machine. All the drawer machines use a common KV storageKV store.
The read only bit from the CQRS pattern is implemented by accessing to the KV storage.
This is great and less coupled ...and all that .. but then we need to start fighting with eventual consistency, CAP and sagas ;) Probably too complex for the simple scenario we are showing
I hope could help and thanks for your interest! Mauricio
I have ended up writing a couple of new applications including a frontend application - there are a few videos demonstrating this product - it is not perfect - but something for someone starting to learn micorservices to pickup and mess with - and should be fairly fun :)
https://github.com/vahidhedayati/micronaut-ms
It is a fork of this project - missing test units I think - up to you we can merge it or you can take bits out of that and update yours.
In the end kafka was best option with tab being the fallback of billing in waiter check waiter fallback of billing which piggy backs client of tab and sends beer to tab - tab simply sends event to kafka
As billing comes up those missing transactions are added back in like nothing was wrong
wow, I went through your fork is a-m-a-z-i-n-g what you did!
I saw u added a frontend and watched a couple of videos. Indeed a nice work! I would not call you a beginner, now you are an expert ;)
My project was very simple so could be the basis of my blog entries, and allowed me to evolve recently to run everything in a Kubernetes cluster (Consul + Zipkin + billing + waiter), so I will leave it as it is as is the basis of future work.
Ciao!
Hey Mauricio
Thanks for this sample project, I had issues getting it to work, taken your work and done dabbling, I wouldn't use it to replace yours since I have disabled the tracing and took out the test cases.
The question was more around running multiple instances at the same time.
My working version is here:
https://github.com/vahidhedayati/micronaut-playground/tree/master/micronaut-ms
The problem I faced is if you have multiple billing backends and 1 waiter, randomly different billing systems are hit as per test.sh and each user then builds up a different balance on each billing system.
It probably makes more sense to run multiple waiters and 1 billing with the current way the billing system handles the hashMap.
My question really is what could be used instead to make it more centralised between many billing systems. It isn't generally a good idea to share DB's across micros services and even running a local redis or db would be no different to an in memory concurrent hashMap.