Closed pedrofgd closed 1 year ago
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.
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
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 ?
No ponto 10: registrar resposta provedor. Quais informações são armazenados? as informações armazenadas vai ser usado para ranqueamento?
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.
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
Como já apresentamos essa versão para a professora ontem, vou fechar essa issue. As alterações necessárias serão feitas em outras
Versão inicial (aprimorar após discussão):