En una gran cantidad de artículos, los microservicios de fuentes, entre otras cosas, se presentan como una forma de construir una solución escalable. Veamos algunos ejemplos de por qué este no es el caso. Y también intentaremos contribuir a la vieja pregunta:
¿Qué es mejor: monolito o microservicio?
Veamos un ejemplo.
Digamos que tenemos un microservicio (lambda) A
que realiza solicitudes de autorización "¿el usuario tiene derecho a realizar la operación?"
Dado que dicho microservicio no puede existir de forma aislada, existe otro microservicio (lambda) junto con él B
, que almacena una lista de correspondencias de derechos de usuario en el almacenamiento.
En la figura se muestra un diagrama aproximado de microservicios (lambdas):
Ambos lambdas / microservicios juntos forman un microservicio de entidad clásico: que encapsula el trabajo con la entidad "usuarios".
Como resultado de los cambios en los datos del usuario (registro de nuevos usuarios, restricciones sobre los existentes, etc.), el microservicio B
"monitorea" la relevancia de los datos en el almacenamiento, que el microservicio utiliza A
para cumplir con las solicitudes de autorización.
Diagrama simple. Está organizado de forma sencilla, funciona de forma fiable.
, , , . "" ?
CPU
A
io-read/select
CPU
B
io-write
CPU . , :
, A
B
?
A
. RO- :
A
, .
: , B
master- , (io-write)?
. , . multi-master:
X
, , - ( - Y
), .
:
. .
, :
CPU
IO
, . , .
. - ( ).
.
:
, , . . , ( ) . , .
? , , ? .
, , , - .
: vs
/FaaS, :
, MVP . - MVP . , , .
- MVP. , , .
? : , :
, ( , )
( )
- " , , ".
Y, en base a lo que se ha escrito, la energía de la eterna disputa "monolito vs microservicio" en la etapa de lanzamiento del proyecto debe dirigirse hacia el desarrollo de un almacén de datos con un enfoque inicial en el escalado. Y en el proceso de desarrollo, el monolito y el microservicio tendrán una arquitectura muy similar. Tan similares que será difícil distinguirlos entre sí.