Se você escolheu os microsserviços para se beneficiar da escalabilidade, do acoplamento flexível e da fácil modificação independente de cada serviço, você deve cumpri-lo o máximo possível.
Arquitetura geral
Eu acho que a melhor abordagem seria:
- possuir um microsserviço para gerenciamento geral de informações do usuário;
- mantenha informações específicas do usuário do microsserviço (por exemplo, perfis, autorizações, preferências) em cada microsserviço (usando a referência do ID geral)
Leitura adicional:
- Este artigo descreve muito bem esse tipo de arquitetura e lógica, com o caso específico de autorizações.
- Este artigo descreve desafios e soluções para o gerenciamento de identidade do usuário, para evitar que todos os serviços acessem o mesmo repositório.
- Este artigo descreve como usar o JWT para transmitir a identidade do usuário entre os serviços (observando que algumas informações básicas podem ser fornecidas no token de identificação, o que evita a necessidade de consultar o serviço do usuário mais uma vez após o logon, pelo menos para itens muito básicos. em formação).
Compartilhamento de código
Agora, se você concordar com a solução acima, temos um microsserviço de usuário (encapsulando o modelo de domínio para o usuário) e todos os outros serviços são consumidores do mesmo microsserviço. A questão é saber se você deseja:
- cada microsserviço para reinventar o código do consumidor, seguindo o dogma da forte separação para permitir ciclos de liberação flexíveis e distintos,
- ou compartilhar o código do consumidor como parte da biblioteca, considerando que essas informações fundamentais são uma extensão do padrão de infraestrutura do "chassi" .
Não tomarei uma posição clara sobre isso, pois há guerras de opinião sobre este tópico de compartilhamento de código, e não acho que estou em posição de assumir uma posição objetiva. Aqui já está uma leitura adicional:
- Este artigo considera que não há melhor solução e tudo depende dos seus objetivos
- Esta posição do artigo é que o compartilhamento de código é ruim apenas se criar um forte acoplamento, e o compartilhamento de código pode trazer algumas sinergias
- Este artigo (das pessoas que implementaram microsserviços em escala) insiste na necessidade de criar compilações separadas e nos possíveis problemas de desativação do código antigo. Ter uma biblioteca compartilhada para consumir com gerenciamento de versão sólida não impede essas boas práticas.
Minha opinião é que você NÃO DEVE COMPARTILHAR código entre o provedor do usuário e o consumidor do usuário, a fim de evitar um acoplamento rígido. No entanto, você PODE COMPARTILHAR o código de consumo do usuário entre os consumidores, se você tiver um gerenciamento de versão forte. Essa abordagem teria algumas vantagens:
- Diferentes microsserviços que consomem o usuário podem ser criados com versões diferentes do código de consumo do usuário compartilhado (desde que as versões sejam compatíveis com o provedor de usuário independente). A mesma flexibilidade que reinventou a roda, mas maior produtividade.
- Você pode alterar o serviço de provedor de usuário de forma independente, sem afetar os consumidores.
- Se um erro for encontrado no lado do consumo, você poderá corrigi-lo uma vez e implantar todos os consumidores da forma mais adequada (graças ao gerenciamento de versões). Isso pode até levar a uma maior qualidade de serviço.
- Se, por algum motivo, você for obrigado a atualizar a API do provedor de usuários, poderá implantar o consumo de usuário atualizado de forma mais rápida. Se você mantiver o serviço antigo e o novo provedor ativo durante a transição, essa possibilidade de compartilhamento poderá permitir a desativação mais rápida da versão mais antiga do provedor consumidor.