architecture - What is the main idea of microservices?

Question

I have read several sources and tried to find out a simple explanation, but unfortunately everywhere there are a lot of words with extensive explanations, but nowhere there is a simple picture, literally a few sentences that would explain the main idea. I wanted to find something that would be easy to understand, a short explanation, but at the same time where the main idea was explained, so that the rest of the words would be secondary. And here, in my opinion, everything is bad, because I have not found such a concise presentation. Is this a sign that the concept of microservices is rather vague and misleading? This worries me. There are also quite a few articles that have caveats against using microservices, and in which there are thoughts that in most cases microservices are not required, your tasks are not so complex, and yout team is not so numerous to use microservices. As a result, I developed a somewhat dismissive attitude towards the idea of ​​microservices. Is it true that microservices is a buzzword that repeats a few old ideas and collects them together?

First, I list the ideas (as I understand it) that are used to explain microservices:

1. Microservices are usually explained as the opposite of a monolith. For example, there is a monolithic application that implements several functions. A microservice is an opposite of a monolith, in which individual functions are designed as separate applications interacting with each other using some kind of protocol. Here, the term "microservices" literally stands for "small services". If we consider this explanation from the point of view of working instances, then although a monolith can have several simultaneously working instances, in this explanation this is not the main idea. In this explanation, the main thing is to separate the work to be done and the program code into separate parts.

2. Another idea in explaining microservices is asynchronous processing of requests and interaction of individual instances with each other. This is a rather old idea, it is not clear why this is considered as some kind of mandatory part in microservices. Well, let's say we don't have asynchronous processing and what we cannot say that we have microservices? In my opinion, this is clearly a secondary feature that I would like to have, but which is not mandatory.

3. Separate your team on small teams working on separate services with separate codebases, with different programming languages ​​and separate databases. Here, the main idea is to reduce the number of connections between teams. The connectivity between services will be minimal if the only linkage is an interaction protocol. This should speed up development and be easier to make changes in code, as the different teams can work independently. If the changes don't change the protocol, then the other parts of the system do not notice it.

4. Using virtualization and containerization. Here, the main problem that is being solved is the ease of deployment and scalability of the application. It looks like everyone uses virtualization, any fashionable thing should have virtualization, let's use it too.

5. Service auto-discovery ability. Services find each other automatically, it is easy to add new instances and move them. There is no need to reconfigure the system when the instance topology changes.

I was looking for something in common in all these ideas and I think I found it. So, here is my definition: microservices are a system built from several instances, such that it is easy to add, remove running instances and scale the entire system, so that even in the case of instance crush, the system continues to perform. Thus, none of the above ideas is mandatory, but only an optional extension. We have to start from what problem we have and take an idea that helps to solve this problem. From this point of view, the main thing is the ability of the system to have several running instances, so if some of them stop working, then this does not affect the functioning of the system. We even may have a monolith, the main thing is the ability to run several instances of the monolith and the ability to work in parallel. That is, the idea of ​​dividing the system into separate functions (into small services) becomes secondary and optional. Actually my question is how true is my understanding of the main idea of ​​microservices?

标签： architecturemicroservicessystem-design

Answer 1

你的理解是有缺陷的。

微服务是独立的，即使另一个完整的微服务完全不可用（例如，离线进行维护），一个完整的微服务也可以继续运行并做有用的事情。

在您的应用程序示例中，该应用程序运行多个实例，每个实例包含应用程序的完整副本：是的，即使一个实例失败，您的应用程序仍然可以工作。但是，如果您需要使应用程序的一项功能脱机进行维护，那么您需要关闭每个实例，整个应用程序将关闭。

使用微服务，每个微服务都是单独部署的，并且有一个单独的数据存储区。如果您需要关闭微服务 A 进行维护，那么您关闭微服务 A 的所有实例，但微服务 B 仍然启动并运行并且可以做有用的事情。