Un artículo sobre una mala decisión que es común al migrar a microservicios. Si bien Microsoft y otras compañías están considerando crear Entity Services en sus tutoriales, existen muchas razones para considerarlo un anti-patrón. A continuación, hablaremos sobre qué es un Servicio de Entidad y qué propiedades tiene para el sistema final en su conjunto.
El original está en el enlace.
Servicio de entidad: ¿qué es? ¿Y cómo surge la idea de crearlo?
Todo el mundo ha oído que dividir un monolito en microservicios ofrece muchas ventajas. Aumenta la flexibilidad, simplicidad, escalabilidad, tolerancia a fallos, etc. Sin embargo, también se pueden escuchar críticas al enfoque de microservicios por la complejidad de garantizar la coherencia de los datos, porque es imposible compartir una transacción entre varios microservicios; se comunican a través de http. Y el sistema en sí se vuelve complejo en su conjunto: es mucho más fácil eliminar las llamadas http y combinar todo de nuevo en un monolito con las llamadas ordinarias del código.
Esto sugiere que no es suficiente simplemente dividir el monolito en varios componentes. Tienes que hacerlo bien. Un monolito típico funciona con una base de datos y contiene varias instancias para mejorar el rendimiento y la tolerancia a fallas.
Supongamos que nuestro monolito es una tienda online. Contiene una lista de productos, puede registrarse como usuario, realizar un pedido, pagarlo y concertar la entrega. Parece una idea cortar el monolito en microservicios. Ya existen entidades dentro del código monolito: pedido, producto, usuario, entrega, etc. Es más fácil aislarlos como microservicios separados. Basta con reemplazar las llamadas en el código con llamadas vía http, copiar el código de la entidad a un nuevo servicio, hacer una fachada API, etc. Como resultado, obtendremos un servicio para pedidos, usuarios, mercancías, entrega, etc.
En la figura, el registro de pedidos y la planificación de la entrega permanecieron dentro de la fachada, pero se pueden mover a servicios separados; en nuestro ejemplo, esto no es lo más importante.
- 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).
. , .
:
.
.
- . . , .
Otra opción a la que tiene sentido prestar atención es la asignación de microservicios por subdominios. Patrón: descomponer por subdominio Hay más opciones para dividir en microservicios de acuerdo con el enlace anterior, pero tiene sentido considerar los dos anteriores en primer lugar.
Ambas opciones van bien juntas: puede combinarlas fácilmente. Lo principal es evitar todas las desventajas de Entity Service .
¿Alguna vez se ha encontrado con este anti-patrón en su práctica? ¿Cómo sugeriría refactorizar los sistemas donde ya existe? Haga preguntas, exprese sus pensamientos en los comentarios. ¡Tu opinión es interesante!