Manipulando mensagens de erro de outros serviços na Micro Service Architecture

Nossa empresa executa aplicativos em uma arquitetura de microsserviço que inclui milhares de serviços. Estou trabalhando em um aplicativo de back-end "X" que fala com mais de 50 serviços. Os serviços de front-end chamam meu serviço "X" para executar solicitações em outros serviços.

Problema :

O front end deseja mostrar mensagens amigáveis ​​quando algo falhar em outros serviços.

1. Outros serviços não retornam mensagens amigáveis. Não é possível solicitar alterações por outras equipes, pois existem várias.
2. Não há códigos de erro acordados como tal. Outros serviços retornam uma mensagem de erro de sequência. Atualmente, ele é retornado à interface do usuário. Às vezes, as mensagens de erro são referências a um ponteiro (código incorreto: /)

Solução possível :

Verifique a cadeia de mensagens de erro e tenha um mapeamento em meu serviço para uma mensagem amigável. Mas as coisas podem quebrar se o serviço de chamada alterou sua mensagem de erro. Retorno a uma mensagem de erro padrão quando um mapeamento de erro personalizado não é encontrado.

Mais alguma idéia sobre solução escalável e sustentável? Obrigado!

Isenções de responsabilidade

Nossa empresa executa aplicativos em uma arquitetura de microsserviço que inclui milhares de serviços. Estou trabalhando em um aplicativo de back-end "X" que fala com mais de 50 serviços. Os serviços de front-end chamam meu serviço "X" para executar solicitações em outros serviços.

Antes de tudo, milhares de serviços aleatórios não transformam uma arquitetura em microsserviços como a arquitetura. Ainda é necessário um certo senso de "todo" e um pouco de disposição entre os serviços. Diretrizes ou regras práticas.

Contextualize o back-end dentro do 'todo'

Presumo que seu back-end não seja gateway nem proxy . Eu acho que ele tem seu próprio negócio e um contexto limitado bem definido. Portanto, em relação a outros serviços, o back-end é uma fachada .

Como fachada, ocultar detalhes de implementação (como, por exemplo, integrações com serviços remotos) está entre suas responsabilidades. Para o front-end (e, portanto, o usuário final), o único interlocutor confiável é Xe nenhum detalhe de implementação deve atingir as camadas externas. O que quer que tenha acontecido sob o capô, não é da conta do usuário.

Isso não significa que não podemos dizer ao usuário que algo deu errado. Podemos, mas fazemos isso abstraindo esses detalhes. Não daremos a sensação de que algo remoto está falhando. Bem ao contrário, algo Xfalhou e é isso.

Como estamos falando de milhares de integrações possíveis (+50 atm), o número de possíveis e diferentes erros é significativo. Se mapearmos cada um deles para uma mensagem personalizada, o usuário final ficará impressionado com tantas informações (e não contextualizadas). Se mapearmos todos os erros para um pequeno conjunto de erros personalizados, estamos enviesando as informações, dificultando o rastreamento e a solução do problema.

Na minha opinião, as mensagens de erro devem fornecer ao usuário a sensação de que podemos fazer algo para corrigir o problema.

No entanto, se os usuários finais ainda querem saber o que está acontecendo, existem outras maneiras mais úteis para toda a organização.

Prestação de contas

1. Outros serviços não retornam mensagens amigáveis. Não é possível solicitar alterações por outras equipes, pois existem várias. Não há códigos de erro acordados como tal.

2. Outros serviços retornam uma mensagem de erro de sequência. Atualmente, ele é retornado à interface do usuário. Às vezes, as mensagens de erro são referências a um ponteiro (código incorreto: /)

Como desenvolvedor, sua responsabilidade é expor esses argumentos às partes interessadas. É uma questão de responsabilidade. Na minha opinião, há um vazamento de liderança técnica e esse é um problema real quando se trata de sistemas distribuídos.

Não há visão técnica. Se houvesse, os serviços seriam implementados com base em regras práticas abordadas para tornar o sistema escalável e facilitar as integrações entre os serviços. No momento, parece que os serviços aparecem descontroladamente, sem o senso de contribuição para o "todo".

Se me pedissem para fazer o que você foi solicitado a fazer (e algumas vezes fiz), eu argumentaria se transformar a anarquia atual em mensagens amigáveis ​​está além do escopo de X.

Pelo menos, "levante a mão", exponha suas preocupações, exponha suas alternativas e deixe quem tiver a responsabilidade de decidir.

Torne suas soluções valiosas para a empresa

Verifique a cadeia de mensagens de erro e tenha um mapeamento em meu serviço para uma mensagem amigável. Mas as coisas podem quebrar se o serviço de chamada alterou sua mensagem de erro. Retorno a uma mensagem de erro padrão quando um mapeamento de erro personalizado não é encontrado.

Você está certo. Essa é uma solução fraca. É quebradiço e ineficiente a médio prazo.

Também acho que isso causa acoplamento, pois as alterações nessas seqüências de caracteres podem forçar você a refatorar os mapeamentos. Não é uma grande melhoria.

Mais alguma idéia sobre uma solução escalável e sustentável?

Relatórios . Manipule os erros, forneça um código / ticket / ID e relate. Em seguida, permita que o front-end visualize o relatório. Por exemplo, compartilhando um link para o serviço de relatório .

Erro. <Uma mensagem de erro amigável e muito padrão>. Siga o link para mais informações

Dessa forma, você pode integrar quantos serviços precisar. E você se liberta da sobrecarga de manipulação e conversão de seqüências aleatórias em novas seqüências aleatórias, mas fáceis de usar.

O serviço de relatório é reutilizável para os demais serviços, para que, se você tiver IDs correlacionados, seja possível permitir que os usuários tenham uma visão panorâmica dos erros e das causas. Em arquiteturas distribuídas, a rastreabilidade é bastante importante.

Posteriormente, o serviço de relatório pode ser aprimorado com tantos mapeamentos quanto necessário para fornecer instruções legíveis e úteis sobre o que fazer se o erro X ocorrer . Se as strings mudarem aqui, isso não importa. O que temos (loja) é um estado final do relatório.

O serviço de relatório abrirá a porta para uma possível normalização dos erros dentro da organização, pois o serviço expõe uma API pública (portanto, um contrato).

Não há milagre no seu caso. A solução possível parece a solução que você já propôs.

Verifique a cadeia de mensagens de erro e tenha um mapeamento em meu serviço para uma mensagem amigável. Mas as coisas podem quebrar se o serviço de chamada alterou sua mensagem de erro. Retorno a uma mensagem de erro padrão quando um mapeamento de erro personalizado não é encontrado.

Não há problema em uma API alterar a mensagem de erro se ela também retornar algum tipo de código de erro, que o consumidor da API pode usar para rastrear o erro e mapear para outra mensagem (como você está tentando fazer, mas com a mensagem).

Certifique-se de registrar apenas a mensagem que a API retornou antes de executar o erro de fallback. Talvez você possa adicionar a mensagem da API de alguma forma developerMessageno seu erro personalizado, ajudando a identificar o problema sem usar o log (verifique se a API deles não transmite nenhuma mensagem com informações confidenciais).

Se você tiver algum canal de comunicação com a equipe que está executando esses serviços, explique seu problema e peça ajuda para eles, pois esse pode ser o mesmo problema para a outra equipe que está tentando usar sua API.