An article about one bad decision that is common when migrating to microservices. While Microsoft and other companies are considering creating Entity Serivces in their tutorials, there is every reason to consider it an anti-pattern. Next, we will talk about what an Entity Service is and what properties it has for the end system as a whole.
Entity Service - what is it? And how does the idea of creating it come about?
Everyone has heard that splitting a monolith into microservices gives many advantages. Increases flexibility, simplicity, scalability, fault tolerance, etc. However, one can also hear criticism of the microservice approach for the complexity of ensuring data consistency, because it is impossible to share a transaction between several microservices - they communicate via http. And the system itself is becoming complex as a whole - it is much easier to remove the http calls and combine everything back into a monolith with the usual calls from the code.
This suggests that it is not enough to simply break the monolith into several component parts. You have to do it right. A typical monolith works with a database and contains multiple instances to improve performance and fault tolerance.
Let's assume that our monolith is an online store. It contains a list of goods, you can register as a user, place an order, pay for it and arrange delivery. An idea appears to cut the monolith into microservices. There are already entities inside the monolith code - order, product, user, delivery, etc. It is easiest to isolate them as separate microservices. It is enough to replace the calls in the code with calls via http, copy the entity code to a new service, make an API facade, etc. As a result, we will get a service for orders, users, goods, delivery, etc.
In the figure, order registration and delivery planning remained inside the facade, but they can be placed in separate services - in our example, this is not the most important thing.
- Entity Service. , CRUD .
, ( ) entity . . .
:
. , ( ). , .
. - , . , . , - , - .
. , . Jaeger Jaeger: open source, end-to-end distributed tracing.
. , .
Microsoft : Creating a simple data-driven CRUD microservice
Entity Service?
entity service . ( ). :
;
, ;
, . , - ;
( , );
;
.
Entity Service :
API , . , - . , . . , .
entity service. , . , -, - :
- . - . - . , . , . . , , , . . .
. . , , . , , - - . . .
, , . - (immutability). - , . :
.
-.
-.
, .. .
(eventual consistency).
. , .
:
.
.
- . . , .
Another option that makes sense to pay attention to is the allocation of microservices by subdomains. Pattern: Decompose by subdomain According to the link above, there are more options for splitting into microservices, but it makes sense to consider the two above in the first place.
Both options go well together - you can easily combine them. The main thing is to avoid all the disadvantages of Entity Service .
Have you ever encountered this anti-pattern in your practice? How would you suggest refactoring systems where it already exists? Ask questions, express your thoughts in the comments. Your opinion is interesting!