How to understand microservices?

Question

Software design

Now the task is to rewrite the project. There are many different services and APIs with which the application must communicate, it was decided to check the possibility, switch to a micro-service architecture (micro-monoliths are even more suitable for us). But there are misunderstandings:

1. If each service has its own api, why API Gateway (entry point), is it possible to make a call to the required api on nginx by location?
2. Should I use RabbitMQ to communicate between services? Do I understand correctly that the entry point on the node sends a request to the rabbit and waits for a response from it and gives it to the client?
3. For example, we are doing a microservice for user authorization and registration. Should he have his own database? How, for example, in the admin panel to contact users to add or block them, should I request users from the microservice? It turns out the microservice is responsible for users CRUD + Registration, authorization, password reset?

Answer 1

How to understand microservices?

Read the relevant book (or rather a couple more about DDD, or at least watch this report )
Then answer a few questions:
1. Why did you decide that microservices would give you something?
2. Do you have real reasons for microservice architecture? (Namely: a zoo of technologies with the inability to write 99% in one language; more than a thousand developers; the complexity of rolling out a monolith in the form of hours of CI / CD runs - tests, build, deployment, rollout stoppers in the form of a bunch of problems due to developers; you are the same big ones like google, uber, amazon, etc.). Or do you just like the buzzword "microservices"?
You cannot create a good microservice architecture without the ability to create a good modular monolith. In this case, you will get not only all the problems of a bad monolith: high connectivity, cascading drops, long CI / CD; but also all the problems of microservices: they need to be orchestrated (do you have a team that will support the infrastructure?); each microservice needs its own CI / CD (and a good one); the network can (and will) lag and break; the duration of requests will increase by an order of magnitude (ki) (especially if you choose some kind of JSON-RPC over HTTP); you need to provide for a failover strategy (for example, idempotent retrays. You already know about correlation id, sagas and what to do if a network error arrives at a request to another service "write off 10 bucks"?) and circuit breakers; traces and logs that would not have to be searched for in hundreds of . log files from each service; the business logic will spread across different microservices and violate the SRP (do not care what it violates, more importantly, it will be much more difficult to fix it). The list can be continued for a long time.

Answer 2

Microservices are not written just to redesign APIs.
The main point of microservices is to isolate components from your product that are heavily loaded so that these components can be easily scaled horizontally.
And from this point of view:

1. If each service has its own api, why API Gateway (entry point), can nginx make a request by location to the desired api?

And if you need a lot of instances, will you distribute one nginx over 10 locations? Microservices in the modern world are supposed to be run in docker on their own lightweight web server (like Jetty), raise the required number of instances and balance something at the input, but not by locations.

2. Should I use RabbitMQ to communicate between services? Do I understand correctly that the entry point on the node sends a request to the rabbit and waits for a response from it and gives it to the client?

RabbitMQ or kafka allows multiple instances of your service to process messages, with the guarantee that nothing will disappear from the queue, and if an instance dies, then another instance will process this request. It is probably not the most correct thing to wait for an answer, but you can watch it as it is more convenient for you - periodically poll the queue, or configure the message service itself to push on an event.

3. For example, we are doing a microservice for user authorization and registration. Should he have his own database? How, for example, in the admin panel to contact users to add or block them, should I request users from the microservice? It turns out the microservice is responsible for users CRUD + Registration, authorization, password reset?

It's how you want. If you have a lot of users and authorization slows down, but you can make a microservice with authorization, make a database cluster with replication. Then you can balance users and there already decide how to scatter them. Or the base is powerful and all instances can work with the cluster. Or divide the base into parts, and scatter users alphabetically (user base from A* to H*, user base from I* to M*, by region or whatever you like).
Microservices cannot be written until you have in your head the overall architecture of the entire project, and what problem you want to solve.
The second important plus of microservices is that it is easier to work on a small microservice than on a large monolith. Its refactoring support is simplified. That is, ultimately, the requirements for the qualification of a programmer are simplified. But the overall architecture of the project becomes more complicated, that is, the burden on seniors / technical leaders increases.

Answer 3

Good afternoon!
First of all, answer one question - what kind of problem do you want to solve by switching to a microservice architecture. Note that providing ACID in a microservice framework is more difficult than in monoliths. Also maintaining microservices is also more difficult. If there is a load on the service, then it is not a fact that you need microservices. It is possible that you need service optimization or more productive hardware.

If each service has its own api, why API Gateway (entry point), can nginx make a request by location to the desired api?

For example, in the case of the Spring API Gateway, it has a balancer. The balancer helps to reduce the load from the microservice, if you have several copies, then each time the requests go to different copies. Gateway is also convenient in that the client does not worry about which endpoint the request should be sent to. It is possible that you have several copies of the same service, and which one should respond to the client's request, this does not concern the client itself.

Should I use RabbitMQ to communicate between services? Do I understand correctly that the entry point on the node sends a request to the rabbit and waits for a response from it and gives it to the client?

It is also possible through RabbitMQ. And so, for example, Spring API Gateway uses asynchronous requests (Spring Webflux) to implement this task.

For example, we are doing a microservice for user authorization and registration. Should he have his own database?

It depends on your task. Yes, maybe your own database. Or maybe not.

It turns out the microservice is responsible for users CRUD + Registration, authorization, password reset?

Again, it depends on your task, on the load, etc. It is possible that registration, authorization and password reset will be separate microservices. And it is possible that User CRUD will be one microservice.