Um artigo sobre uma decisão errada comum ao migrar para microsserviços. Embora a Microsoft e outras empresas estejam considerando a criação de Serviços de Entidade em seus tutoriais, há todos os motivos para considerá-lo um antipadrão. A seguir, falaremos sobre o que é um Serviço de entidade e quais propriedades ele possui para o sistema final como um todo.
Serviço de entidade - o que é? E como surgiu a ideia de criá-lo?
Todo mundo já ouviu que dividir um monólito em microsserviços oferece muitas vantagens. Aumenta a flexibilidade, simplicidade, escalabilidade, tolerância a falhas, etc. No entanto, também se pode ouvir críticas à abordagem de microsserviços pela complexidade de garantir a consistência dos dados, pois é impossível compartilhar uma transação entre vários microsserviços - eles se comunicam via http. E o próprio sistema como um todo se torna complexo - é muito mais fácil remover as chamadas http e combinar tudo de volta em um monólito com chamadas comuns do código.
Isso sugere que não é suficiente simplesmente quebrar o monólito em várias partes componentes. Você tem que fazer isso direito. Um monólito típico funciona com um banco de dados e contém várias instâncias para melhorar o desempenho e a tolerância a falhas.
Vamos supor que nosso monólito seja uma loja online. Ele contém uma lista de produtos, você pode se cadastrar como usuário, fazer um pedido, pagar e providenciar a entrega. Uma ideia parece cortar o monólito em microsserviços. Já existem entidades dentro do código monolith - pedido, produto, usuário, entrega, etc. É mais fácil isolá-los como microsserviços separados. Basta substituir as chamadas no código por chamadas via http, copiar o código da entidade para um novo serviço, fazer uma fachada de API, etc. Como resultado, teremos um serviço para pedidos, usuários, mercadorias, entrega, etc.
Na figura, o registro do pedido e o planejamento da entrega permaneceram dentro da fachada, mas podem ser movidos para serviços separados - em nosso exemplo, isso não é o mais 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).
. , .
:
.
.
- . . , .
Outra opção que faz sentido prestar atenção é a alocação de microsserviços por subdomínios. Padrão: Decompor por subdomínio Existem mais opções para dividir em microsserviços de acordo com o link acima, mas faz sentido considerar os dois acima em primeiro lugar.
Ambas as opções combinam - você pode combiná-las facilmente. O principal é evitar todas as desvantagens do Entity Service .
Você já encontrou esse antipadrão em sua prática? Como você sugeriria sistemas de refatoração onde já existem? Faça perguntas, expresse sua opinião nos comentários. Sua opinião é interessante!