Em um grande número de artigos, microsserviços de fontes, entre outras coisas, são apresentados como uma forma de construir uma solução escalonável. Vejamos alguns exemplos de por que isso não acontece. E também tentaremos contribuir para a velha questão:
O que é melhor: monólito ou microsserviço?
Vejamos um exemplo.
Digamos que temos um microsserviço (lambda) A
que realiza solicitações de autorização "o usuário tem o direito de realizar a operação?"
Uma vez que tal microsserviço não pode existir isoladamente, outro microsserviço (lambda) existe em conjunto com ele B
, que armazena uma lista de correspondências de direitos do usuário no armazenamento.
Um diagrama aproximado de microsserviços (lambdas) é mostrado na figura:
Os lambdas / microsserviços juntos formam um microsserviço de Entidade clássico: que encapsula o trabalho com a entidade "usuários".
Como resultado das alterações nos dados do usuário (registro de novos usuários, restrições aos existentes, etc.), o microsserviço B
"monitora" a relevância dos dados no armazenamento, que o microsserviço usa A
para atender às solicitações de autorização.
Diagrama simples. Ele é organizado de forma simples e funciona de maneira confiável.
, , , . "" ?
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. , , .
? : , :
, ( , )
( )
- " , , ".
E, com base no que foi escrito, a energia da eterna disputa "monólito vs microsserviço" na fase de lançamento do projeto deve ser direcionada para o desenvolvimento de um data warehouse com um foco inicial em escala. E no processo de desenvolvimento, o monólito e o microsserviço terão uma arquitetura muito semelhante. Tão semelhantes que será difícil distingui-los.