Como você lida com conceitos compartilhados em uma arquitetura de microsserviço?

Estou pesquisando padrões de arquitetura para um aplicativo que estou desenvolvendo e uma abordagem de microsserviço parece ser uma boa opção, mas não sei como lidar com interações entre os serviços.

O aplicativo lida principalmente com usuários, perfis pertencentes a usuários, fotos e tags que representam um a muitos perfis em uma foto. É possível que existam métodos para devolver fotos enviadas por um usuário, devolver fotos que contenham um determinado perfil marcado, etc.

Esta é minha primeira tentativa de projetar uma arquitetura baseada em microsserviços e venho de uma história inspirada no modelo de domínio monolítico . Nesse mundo, os controladores costurariam esses objetos de domínio, mas estou tendo problemas para entender como isso funcionaria de maneira microsserviços.

— anjunatl
fonte

Respostas:

Geralmente, os serviços chamam outros serviços quando precisam acessar seus dados. Cada parte dos dados deve pertencer a um serviço específico, que será o único ponto de entrada para acessar e modificá-los. Alguns serviços serão simples e geralmente correspondem ao modelo do seu domínio (por exemplo, um serviço para manipular usuários), enquanto outros serão de alto nível e usarão dados de outros serviços (por exemplo, exibindo uma lista de fotos juntamente com informações sobre os usuários que os carregaram) )

No seu caso de uso, você deve começar de fora e pensar em quais operações deseja disponibilizar para o usuário por meio de uma API (se for um serviço de back-end) ou quais operações devem estar disponíveis na GUI, se for um aplicativo da web. Observe que a parte da GUI geralmente é um aplicativo comum com seus próprios controladores: as operações podem ser chamadas via REST (como no AngularJS), mas esses pontos de extremidade são projetados apenas para uso do aplicativo da GUI e não são microsserviços no senso comum.

Suponha que você queira exibir fotos juntamente com informações sobre os uploaders. Você pode ter um serviço de usuário que retorna informações sobre um usuário, com o ID do usuário e um serviço de fotos que pode listar fotos (por exemplo, pesquisando por alguns critérios). A lista de fotos conteria para cada foto o ID do usuário que fez o upload. Dessa forma, esses dois serviços não são acoplados - o serviço de fotos conhece apenas os IDs do usuário, mas nada sobre os dados do usuário. Além desses dois serviços, você pode criar um terceiro serviço com uma operação como "listar fotos com informações sobre carregadores" que chamaria os outros dois serviços e combinaria os dados que eles retornam. Como alternativa, essa operação pode ser executada pelo aplicativo da Web em vez de por um serviço.

— Michał Kosmulski
fonte

Isso me ajudou muito. Comecei escrevendo alguns casos de uso de interface do usuário que exercitariam a pilha e tudo se encaixou.

— anjunatl

Neste exemplo em particular, devemos fazer, por exemplo. 10 chamadas para o serviço do usuário para obter dados do usuário se tivermos 10 fotos em nossa lista? Não adicionaria muita sobrecarga?

— Ricardo Souza

@rcdmk Você pode adicionar um ponto de extremidade REST que obtém uma lista de vários IDs como entrada e retorna várias fotos como saída. Isso geralmente é feito na prática por razões de desempenho. Às vezes, o design da API é um compromisso entre pureza e considerações práticas.

— Michał Kosmulski 23/03

@ MichałKosmulski Preciso iniciar a discussão, mas o design do StackExchange os desencoraja :) O que não gosto na abordagem de microsserviço neste exemplo em particular é que a consulta direta ao banco de dados subjacente (onde usuários e imagens são armazenadas) pode ser muito mais eficiente. Imagine se esses serviços upstream dependem de outros serviços upstream e assim por diante. A consulta direta ao armazenamento de dados é muito mais segura. apenas meus 5 centavos - nada mais. Mais uma vez eu realmente gostaria de ter discussão produtiva sobre o tema, mas StackExachange não é bom lugar para isso (você pode recomendar microservices fóruns de discussão?)

— ajukraine

@ajukraine Acho que há chats sobre stackexchange que podem ser um bom lugar para discussões. Quanto ao desempenho: 1. Os microsserviços têm um custo de desempenho e 2. Os microsserviços são bons para algumas situações, mas não para outras. Quanto às dependências: nas arquiteturas de microsserviço, você costuma fazer cópias locais dos dados e usar mensagens assíncronas para reduzir o número de dependências. É uma mudança real na arquitetura, não apenas alterando automaticamente cada módulo de um aplicativo para um aplicativo separado.

— Michał Kosmulski

O aplicativo lida principalmente com usuários, perfis pertencentes a usuários, fotos e tags que representam um a muitos perfis em uma foto. É possível que existam métodos para devolver fotos enviadas por um usuário, devolver fotos que contenham um determinado perfil marcado, etc.

Bem, o serviço de perfil não deve funcionar com o objeto de usuário. Talvez ele saiba apenas o ID do usuário para o qual é solicitado que retorne dados, não mais. Dessa forma, você não exigirá interação entre o serviço do usuário e o serviço de perfil.

Se isso não responder à sua pergunta, você poderia esclarecer descrevendo a situação exata com a qual está lidando?

— Vladislav Rastrusny
fonte

Essa e a resposta de Michal me ajudaram a entender, mas sua sugestão me ajudou a mapear os serviços que eu precisava. Eu estava preso em uma mentalidade de precisar representar um objeto completo em vez de apenas uma referência ao objeto (objeto de usuário versus ID do usuário). Muito apreciado, obrigado!

— Anjunatl 22/03

@anjunatl Welcome;)

— Vladislav Rastrusny;