I am converting a monolith to micro services architecture using RESTful apis using C#. I have identified various micro services that will completely represent my monolithic application.
One important service is a configuration service which holds important configuration information which would be needed by the remaining micro-services.
What is the best way for the services to communicate with the Configuration service?
Can I directly invoke the configuration service URL from other services using HTTP?
I have looked into other approaches like RabbitMQ, pub/sub, but i believe that these approaches are more suited for use cases where broadcasting of information is needed to multiple services.
What would be the best approach for communication between services in the above case?
-
1Please read the help center articles, before posting. Cross posting is very discouraged. Only post on ONE (the most suitable one for your topic) stack exchange Q/A, not multiple– TsengCommented Feb 11, 2020 at 8:03
-
Have you considered refactoring your current application rather than going straight to microservices? The work you have done to identify logically separate areas of code can still be used, and you dont have the deployment / communication / performance overhead that microservices introduce.– richzillaCommented Feb 11, 2020 at 15:03
3 Answers
May i suggest using gRPC. It's relatively easy to build services with it and you get a lot of benefits:
- you have a strong api contract and strong api governance as the api spec is put apart from the code
- you can generate client/server code in many languages
- it's well supported with current asp .net core technology
One word of caution, think twice before moving to the all new hot stuff called microservices. We tried microservices, but ended up with a totally over engineered distributed application not solving any real problems... ;-)
See here why the istio team is switching back.
I don't see why you see RabbitMQ as a broadcasting solution, RabbitMQ is a Messaging Bus. I think it's a very good solution for inter-service communication.
For a configuration service, why not use Observer Pattern where your apps read the initial configuration and then be notified whenever a config change (that matters to them) occurs
-
He didn't say RabbitMQ was a broadcasting solution, he said it was a pub/sub. Which, according to their documentation, it implements that pattern. In your response, try to focus on the question - what is the best way for the services to communicate with the configuration service,– Martin KCommented Feb 11, 2020 at 12:05
-
@MartinK: Question reads differently: I have looked into other approaches like RabbitMQ, pub/sub, but i believe that its an enumeration, RabbitMQ along with pub/sub (assuming the interprocess pattern for message communication - everything else makes no sense since there is no product named pub/sub afaik) and pub/sub as a pattern is broadcasting like: You fire up an event and don't know if anyone will handle it or if its. MessageBus on other side has more stuff (routing, persistance) that a simple pub/sub pattern doesnt– TsengCommented Feb 11, 2020 at 13:27
-
Assumptions:
- You have a sound architectural vision for moving from the monolith to micro services
- A lot of these micro services are processes that has a life cycle and are long running
- These micro services need to know when a configuration data entity/attribute is changed, but they do not change configuration data.
I would suggest that the primary IPC (inter process (service) communication) is REST with JSON. So when one of these other services are woken – called for the first time it calls (REST API) the configuration services for “all” configuration data – that is available/needed.
And when needed it could check for a specific configuration data through another REST API.
Issues to be aware of is the timing, update cycle of all / different configuration data. So when other services are trying to read a configuration data being updated they will wait and the REST API will return when the update is COMMIT.
If they need to know instantly when a configuration data is changed then you in addition will need to use preferably a MQ solution most of them provide a REST API eg. https://activemq.apache.org/rest. So the configuration services publish on a specific message que a topic of a changed configuration data and all services subscribing to that que/topic gets notification to pull that new configuration data.
If you need to scale (out) the configuration service, i.e. running several instances of it then the solution will become more complex and you will need a different data management approach.
A good source for these type of pattern and variants are Chris Richardson – his site https://microservices.io/ and his book microservices pattern https://www.manning.com/books/microservices-patterns
