Microservice architecture: how micro? and why there are no problems with long waiting?

Question

PHP

I began to study the topic of microservice architecture, painted our monolith because of scalability problems.

As I want to study, I also began to study different cases, and when I hear that some have hundreds, or even thousands of microservices, my hair began to move.

The tutorials say that a microservice should adhere to the SRP pattern, i.e. each microservice should be responsible for only one task.

When developing applications in OOP, I intuitively understand how to share responsibilities in classes.

But I don't understand how to do it in microservices.

Problem 1:

For example: I need to separate a catalog from my monolithic system and split it into microservices.

For a directory, I can only imagine 3 microservices:
1. Directory structure.
2. Information on goods (descriptions, pictures, characteristics).
3. Information on offers (balances, prices).

Can you please tell me if I imagined this correctly? (because when studying cases, I see that some get a dozen microservices) if not, what is the problem, and what do I not understand? It is clear that everyone is different, and it all depends on the tasks.

Problem 2:

because we can have a huge number of microservices, then when generating a website page, we may need to get data from dozens of microservices.

Question: why does it not slow down? after all, getting data in classic microservices is rest requests.

Problem 3:

When dividing one entity into many microservices, how are data consistency problems solved? Transactional (is it decided at the application level?) ?

I will be very grateful if someone will explain so that I have an understanding of such an architecture.
And I will also be grateful for links to case studies / training materials on the topic.

Answer 1

You are asking very difficult questions, a detailed answer to each of which is unlikely to fit into the resource character limit. To deal with the first problem, it's worth reading Evans ' Domain-Oriented Design . Roughly speaking, a microservice should operate on a small independent subset of data . For answers to the second and third problem, a good start might be " Highly loaded applications"Klepman. Yes, interaction within a microservice system is obviously slower than calls within a monolith, everything has a price. But with the right code, the right architecture and the right infrastructure, the speed is still enough to respond to requests in a fraction of a second. And for consistency, you have to use approaches like the saga pattern.

Answer 2

1. IMHO, 90% depends on the tasks and the organization. That is, it makes sense in hundreds of services for a huge company, but it's hard for me to imagine that it makes sense for a group of three developers
2. As already said, if it doesn't slow down, it's because the services are very close to each other. But speed is not the only problem. Monitoring, debugging - everything looks completely different from before.
3. As far as I understand, there is a serious dispute here - one base for all or a base for a microservice.
Disclaimer - I'm a DevOps, not an architect.
See
https://world.hey.com/joaoqalves/disasters-i-ve-se...
https://medium.com/microservices-in-practice/micro...
https://k8s.af/ - Kubernetes Failure Stories
highscalability.com/blog/category/example- Real Life Architectures

Answer 3

for painted our monolith due to scalability issues

Didn't really understand the connection between monolith and scalability. If you follow these rules , then any monolith will scale perfectly. If I were you, I would bring the project to compliance with these rules, and not rush to climb over to microservices, because. and they have enough problems.

Problem 1:

Why only 3? Your store is not authorized? Yes, it is a separate microservice. Is there an email distribution? There is another microservice. Do you send sms? Another. Another thing is that it’s understandable that more than one person should write all this, and, most likely, not everything in php.

Problem 2:

Sequentially (synchronously) no one makes requests to a bunch of services. Guzzle (a library for http requests) has an asynchronous mode, by the way. That is, you can immediately make a call to several services and collect the results (the time will be equal to the execution time of the slowest request). But you can also call several services from the frontend asynchronously at once. If the issue is authorization, then jwt tokens can be used for this - each service can validate them itself. You can also cache data in certain situations and even duplicate it in different services (this is acceptable in a microservice architecture).

Problem 3:

Usually it doesn't work, oddly enough. Distributed transactions are a pain. And you can’t use a common database for several microservices - this is an anti-pattern.
Ps perhaps, in your case, you don’t need to split everything into heaps of microservices. It is long, expensive, laborious - and it is difficult to make it convenient, especially when there is no experience. Try to separate one thing as needed, then another. And it makes absolutely no sense to crush mindlessly.

Answer 4

usually microservices are cut so that they serve a separate "topic" that could be separately scaled and modified separately from everyone else. Example:
a microservice that processes the work of the catalog (and everything related to it), a separate microservice that will work with the delivery and dispatch of orders, a microservice that works with an affiliate program and the accrual of loyalty points, and a microservice that processes payments. It is desirable for each of these microservices to have their own database, then they can work independently of each other and scale independently, only meeting the needs of their load - obviously the load on the catalog is much higher than on the payment processing service (for example, the catalog can process 10 nodes, orders process 3 node and payments 1 node)
When using a monolith, you scale all services at once to the nodes, which is not so efficient.
-------
Regarding the performance - with such cutting as described above, you will extremely rarely have a situation where, in order to respond to one request from the user, you will need to poll several services at once, BUT even in such situations, the delay between calls, how much the ability to scale the processing of these requests.
-------
transactionality is usually done through the SAGA pattern.
Regarding consistency - if you start scaling the system, then the state is spread over many different nodes / services, the whole point is that these nodes / services can work independently of each other, then consistency will interfere with independent work (that is, performance), if services are dependent, then they are not scaled (since one node expects something to work from another node), so there are "weakened requirements" for state consistency, as a rule they use eventual consistency (ultimately consistency), they say that sooner or later the type of state in the system will be consistently if no new data arrives)
but as long as the data arrives, the state may not be consistent between the nodes.

Answer 5

A well-written monolith has no scalability issues. I strongly doubt that you have Google volumes there. On the other hand, for a career, for a resume, for practice, of course, it is better to tear apart a monolith from your current employer, for his own money. So don't worry too much about what and how. Seriously, no irony. Life is like that, we are not like that.

Answer 6

I began to study the topic of microservice architecture, painted our monolith because of scalability problems.

Welcome to the wonderful world of microservices. Now you will have not only scalability problems, but also a bunch of others.

...SRP, i.e. each microservice should be responsible for only one task.

This is not so, SRP says something else.
All other problems are big questions that need to be sorted out for a long time.
And read here . In short: microservices are infrastructure. If you think that they will solve your business problems, you will get even more business problems and a whole mountain of infrastructure ones. And you can scale and the monolith is fine.

Answer 7

If the only problem is performance scaling, before trying to solve it with hardware and minimal application separation. Rewriting a monolith to microservices is always more expensive, VERY MUCH more expensive.

Answer 8

How does it not slow down, go to any modern large resource, any account of any bank or mobile operator is loaded for several minutes (the very stubs in all places where there should be any data), constantly in the playmarket, users write they say what is there it can take so long to load, but everything has already been rewritten at one time to microservices, because it’s fashionable for the youth, don’t rewrite it back.