Diagrama de sequência do health check

[pedrofgd]

Versão inicial (aprimorar após discussão):

sequenceDiagram
    participant Healthcheck
    participant Broker
    participant Validador
    participant Monitorador
    participant Configurações
    participant Provedor

    autonumber
    Healthcheck->>Broker: Envia uma requisição para um provedor
    Broker->>Configurações: Obtém configurações do provedor
    Configurações->>Broker: Configurações
    Broker->>Provedor: Requisição
    Provedor->>Broker: Resposta
    Broker->>Validador: Verificar se o provedor atingiu os critérios
    Validador->>Configurações: Obtém os critérios de health check do provedor
    Configurações->>Validador: Critérios
    Validador->>Broker: Resultado da validação
    Broker->>Monitorador: Registra os resultados da validação
    Monitorador-->>Monitorador:  Reordenar lista de provedor com base nos resultados
    Broker->>Configurações: Obter configurações de health check do provedor
    Configurações->>Broker: Configurações
    Broker-->>Broker: Agendar próxima execução do health check
    Broker->>Healthcheck: Resposta

[pedrofgd]

Em termos práticos de implementação, o trigger dos health checks pode ser na primeira inicialização do Broker. Ou seja, assim que a aplicação iniciar, é feito um health check para todos os provedores. Com base nas configurações de health check de cada provedor, os próximos são agendos.

[pedrofgd]

Removido o antigo ponto 11, em que o Monitorador reordenava a lista de provedores. Como agora teremos o Ranqueador, que faz uma consulta ao monitorador, não há necessidade do Monitorador ter nenhuma regra de negócio. Ele será utilizado apenas para armazenar dados e toda lógica para decisão do provedor ativo estará na aplicação Broker, no componente Ranqueador. Esse componente será relevante no fluxo da requisição no Broker.

Removidos antigos pontos 12 e 13, que eram para o Broker obter as configurações de health check do provedor. O ponto 2 já pega as configurações do provedor, o que inclui as definições sobre health check.

Removido antigo ponto 15, que era retornar resposta do check para o Healthchecker. O check dos provedores é disparado na inicialização do Broker e esse processo não espera a resposta do check.

sequenceDiagram
    participant Healthchecker
    participant Broker
    participant Validador
    participant Monitorador
    participant Configurações
    participant Provedor

    autonumber
    Healthchecker-->>Broker: Envia uma requisição para um provedor
    Broker->>Configurações: Obtém configurações do provedor
    Configurações->>Broker: Configurações
    Broker->>Provedor: Requisição
    Provedor->>Broker: Resposta
    Broker->>Validador: Verificar se o provedor atingiu os critérios
    Validador->>Configurações: Obtém os critérios de health check do provedor
    Configurações->>Validador: Critérios
    Validador->>Broker: Resultado da validação
    Broker->>Monitorador: Registra os resultados da validação
    Broker-->>Broker: Agendar próxima execução do health check

[pedrofgd]

Talvez o health check não precise passar pelo Validador. Só registramos a resposta do provedor no monitoramento e agenda o próximo. Essa ideia (inicialmente colocada em um comentário em #9) deixa a função do Validador mais simples: apenas verificar se o Broker precisa acionar o próximo provedor ou não (estando válido, retorna para o cliente). Avaliar remover os atuais pontos 6, 7, 8 e 9 e alterar o ponto 10 para: registrar resposta provedor

Complementar ao comentário feito em #9 no dia 03/04/23 sobre a real função do Validador. O que acham @ClaudioSiqueira @lucas-ye @An-225 ?

[lucas-ye]

No ponto 10: registrar resposta provedor. Quais informações são armazenados? as informações armazenadas vai ser usado para ranqueamento?

[pedrofgd]

As informações são registradas pelo monitorador. Detalhes sobre a modelagem dos dados no InfluxDB aqui

Essas informações serão utilizadas pelo ranqueador, que está sendo implementado em #22.

Na definição atual, o ranqueador faz uma consulta ao banco de dados para obter as informações que considera relevante no processo de decidir qual o melhor provedor.

[pedrofgd]

Atualizado com base no que foi implementado:

%%{init: {'theme': 'neutral'}}%%

sequenceDiagram
    participant Healthchecker
    participant Configurações
    participant Requisitor
    participant Provedor
    participant Monitorador

    autonumber
    Healthchecker->>Configurações: Obtém configurações do provedor
    Configurações->> Healthchecker: Configurações
    Healthchecker->>Requisitor: Enviar requisição
    Requisitor->>Provedor: Requisição
    Provedor->>Requisitor: Resposta
    Healthchecker->>Monitorador: Registra métricas da resposta
    Healthchecker-->>Healthchecker: Agendar próxima execução do health check

[pedrofgd]

Como já apresentamos essa versão para a professora ontem, vou fechar essa issue. As alterações necessárias serão feitas em outras