Please enable JavaScript.

Coggle requires JavaScript to display documents.

Arquitetura baseada em Microsserviços - Coggle Diagram

- - - - Sem sabermos os sinais vitiais não é possível sabermos a saúde do sistema
      - O sistema deve ter autocura, ou seja, se eu interromper o tráfego ele deve se recuperar (e não simplesmente parar um pod e perder os requests sendo processados
      - Não pode ser só o serviço, mas todas as suas dependências, como banco de dados
      - Ativo x Passivo: passivo somente quando alguém o acessa. Ativo tem probes independentes
    - - Protege o sistema baseado no que ele foi projetado para suportar
      - Diferenciar por tipo de client (priorizar quem dá dinheiro para a empresa)
    - - Protege o sistema fazendo com que as requsições feitas para ele sejam negadas
      - Circuitos fechados x abertos x semi-abertos
    - - Pode implementar políticas de Rate Limiting e Health Check
      - Ajuda a organizar os microsserviços em contextos (1 API Gateway na frente de serviços de logísticas, 1 API Gateway na frente de serviços de checkout, etc)
      - Garante que requisições inapropriadas cheguem até o sistema (ex.: usuário não autenticado)
    - - Detém informações sobre todo tráfego de rede da aplicação, através de proxies que ficam entre o serviço A e o serviço B
      - Permite comunicação mTLS mesmo internamente
      - Faz implementações de proteção centralizadas ao invés de ser em cada serviço, como circuit breakers retries, timeouts, testes de injeção de falhas, etc
    - - Tem bibliotecas que fazem isso para o dev
      - Fazer chamadas exponential backoff e não linear backoff. Mas o estado da arte é o exponential backoff com Jitter que gera uma distorção no tempo para o próximo envio e protege contra o exponencial dos clientes também ser o mesmo
    - - Entrega
        
        Transaction outbox forma de garantir a entrega das mensagens quando o próprio message broker ficar fora do ar. Antes de enviar a mensagem para o um Kafka, você salva ela em uma tabela temporária no banco, e quando recebe o ACK do kafka, você a deleta (importante observar o custo de escrita e leitura em BD). Pode ser um RDMBS, Dynamo (KV), Cache, sem colocar no prõprio DB da aplicação. Pode-se criar um SDK da organização que para toda request já faz o retry e se não der certo grava na tabela.
        
        ACK0, ACK1 e ACK ALL (ou -1)
      - Recebimento
        
        Para evitar que logo após eu receber a mensagem meu serviço cair. A mensagem já foi retirada do message broker. Colocar ent"ao o Auto ACK para false
        
        Entender a volumeria que o sistema aguenta para um Prefetch (receber um batch de mensagens e não uma a uma), para evitar que você receba um batch de 100, não terminou de processar e já recebeu mais 100
    - - APM
      - Tracing distribuído, quando consigo ver exatamente cada microsserviço que o request passou
      - Open Telemetry (para tornar a ferramenta de visualização independente.