Em uma arquitetura de microsserviços fracamente acoplada, como você monitora suas dependências?

Uma opção popular de arquitetura de alto nível no programa moderno é um sistema de microsserviços baseado em REST. Isso tem várias vantagens, como acoplamento flexível, reutilização fácil, restrição limitada de tecnologias que podem ser usadas, alta escalabilidade etc.

Mas um dos problemas que eu prevejo em uma arquitetura desse tipo é a pouca visibilidade de quais são as dependências de um aplicativo. Por exemplo, digamos que eu tenho um aplicativo que usa um conjunto de chamadas REST diariamente. Esse aplicativo também usa um segundo conjunto de chamadas REST, mas apenas uma vez por trimestre. Se eu fosse verificar os logs da semana passada, veria todas as chamadas diárias, mas provavelmente não veria as chamadas trimestrais. Quando chega a hora de refatorar, as chamadas trimestrais correm alto risco de interrupção.

Quais padrões ou ferramentas podem ser usados ​​para reduzir esse risco e fornecer maior visibilidade sobre quais são as dependências de uma arquitetura fracamente acoplada?

Quais padrões ou ferramentas podem ser usados ​​para reduzir esse risco

Mantendo suas APIs e recursos de negócios compatíveis com versões anteriores.

fornecer maior visibilidade sobre quais são as dependências de uma arquitetura fracamente acoplada

Verificações de saúde.

Meu serviço é um cliente para sua capacidade mensal de API. Mas meu serviço é o cliente da sua API sempre que meu serviço está sendo executado. Portanto, meu serviço é ativado a cada 10 minutos, ou o que for, se conecta à sua API mensal e executa o protocolo para garantir que a capacidade que meu serviço precisa ainda esteja disponível.

Portanto, seus logs mostrarão com que frequência algum outro serviço está verificando se cada serviço específico que você oferece ainda está disponível, assim como mostra com que frequência cada serviço específico que você oferece é realmente usado.

Existem pelo menos dois locais onde você pode encontrar as dependências:

• Configuração. Para acessar APIs externas, é necessário conhecer um monte de informações sobre cada uma dessas APIs. IDs de acesso, chaves secretas, terminais. Tudo isso não pode estar no código, porque essas informações serão alteradas. Como exemplo, comecei recentemente a migrar todos os meus microsserviços para SSL. Isso significa que todo serviço que depende do que está sendo migrado deve ser reconfigurado para apontar para a https://versão em vez de http://. Fico feliz que os pontos de extremidade estavam na configuração em vez de serem codificados.

• Interfaces. Você não acessa um serviço diretamente do seu código, porque a versão da API será alterada e você pode até decidir mudar para uma API diferente. Em vez disso, você cria uma camada de abstração e usa a dependência por meio de uma interface. Seguindo uma lógica comum ao criar essas interfaces, você pode facilitar sua vida mais tarde ao procurar as dependências.

Quando chega a hora de refatorar, as chamadas trimestrais correm alto risco de interrupção.

É para isso que serve o teste de regressão.

Você não pode simplesmente olhar para o código, alterá-lo e confiar em si mesmo que nada foi quebrado. Isso não funcionará em uma arquitetura de microsserviços. Isso também não funcionará em um aplicativo monolítico. Um compilador pode detectar alguns dos erros que você apresentará ao modificar o código. Em alguns idiomas, como Haskell, o compilador pode ser muito capaz e detectar a maioria dos erros; compiladores para idiomas comuns, no entanto, não farão muito por você. Se você não tiver testes, está ferrado. A presença de microsserviços é irrelevante.

As APIs REST são vagamente especificadas, portanto, em algum momento, pode ser útil mudar para gRPC, google protobufs ou Thrift para definir uma interface RPC e depois fazer a versão.