Este artigo explica principalmente como garantir que a API não relate erros durante o processo de atualização e implantação da versão do serviço na arquitetura de microsserviços de nuvem de primavera.
fundo:
1. O serviço atual está indisponível devido ao lançamento da versão, e uma mensagem de fusível é retornada, o que afeta a experiência do usuário, como "O sistema está ocupado, tente novamente mais tarde"
2. O link de solicitação é interrompido no meio e os dados na primeira metade de uma solicitação estão corretos, mas os dados na segunda metade estão incorretos, resultando em confusão de dados
3. Para problemas causados pela situação 2, os colegas de P&D precisam gastar muito tempo localizando o problema e reparando os dados
Ideia de implementação:
1. Remova o serviço de liberação do centro de registro eureka e libere o serviço depois que o serviço não tiver tráfego
2. Acione outros serviços para atualizar a lista de serviços, interrompa a solicitação do serviço de liberação e deixe o serviço de liberação sem tráfego
3. Depois que o serviço de liberação for iniciado, acione outros serviços para atualizar a lista de serviços, solicite o serviço de liberação e deixe o serviço de liberação compartilhar o tráfego
O seguinte é um exemplo de demonstração simples, queremos liberar a versão do B1
1. Mecanismo de descoberta de serviço do Eureka
Vamos primeiro entender o mecanismo de descoberta de serviço do eureka
O componente que finalmente inicia a requisição no microsserviço é o Ribbon (com uma lista de serviços mantida por ele mesmo). também enviará a solicitação Para B1, B1 é incapaz de processar a solicitação durante o período de desligamento para reiniciar, então ele acionará o mecanismo de fusível interno de A1 ou A2 (como "o sistema está ocupado, tente novamente mais tarde")
Para esse tipo de fusível causado pelo lançamento, podemos realmente evitá-lo. Vamos ver como faço
2. Lançamento elegante
1. Remova B1 de eureka e libere B1 depois que o serviço não tiver tráfego
Embora o B1 aqui tenha sido removido do eureka, o B1 ainda está rodando normalmente.Se você usar o método ip+port para solicitar diretamente a API do B1, ele pode ser processado normalmente.
Como B1 e B2 são os nós do cluster de serviço B, eles se registrarão automaticamente no eureka após o início de B1, distribuirão o tráfego e farão o mesmo processo de liberação para B2 (a liberação do serviço A também é a mesma)
Durante todo o processo, estamos reiniciando o serviço sem tráfego, o que não afeta todo o link de solicitação do microsserviço
2. Como fazer logoff do serviço
1) Desativar readOnlyCacheMap
eureka.server.use-read-only-response-cache: false
Se não estiver desativado, o off-line ativo normal será sincronizado diretamente com readWriteCacheMap, mas não será sincronizado com readOnlyCacheMap, pode haver uma diferença de 30 segundos, ainda há B1 na lista de serviços puxada pelo cliente eureka e B1 não pode ser removido imediatamente
2) Execute DiscoveryClient.shutdown()
Defina uma API para chamar DiscoveryClient.shutdown() para fazer logoff ativamente do eureka
E use o MQ (eu uso o rabbitmq aqui) para enviar uma mensagem de transmissão para todos os outros serviços, informando aos outros serviços que este serviço ficou offline, atualize a lista de serviços da faixa de opções rapidamente e não envie mais solicitações para este serviço
Por que atualizar a lista de serviços do cliente eureka aqui? Porque os dados da lista de serviços do Ribbon são a lista de serviços do cliente eureka (veja a figura anterior)
3) Outros offline (atualmente apenas os consumidores MQ precisam ser atendidos, se você tiver outras necessidades a serem atendidas em seu projeto, também pode consultá-lo)
Embora B1 não processe mais solicitações de API, o consumidor MQ de B1 ainda está consumindo dados. Se o consumidor parar de processar dados, B1 causará problemas. O que devo fazer?
Todos os consumidores MQ de B1 off-line
4) Após o início do serviço, notifique outros serviços para atualizar a lista de serviços e obter tráfego rapidamente
Esta etapa não é necessária. Você também pode esperar que o serviço sincronize automaticamente a lista de serviços. Nesse caso, pode haver um certo atraso. Você precisa aguardar para implantar o próximo nó.
3. Aplicação
Chame principalmente a interface /offline acima (tente manter o bloqueio síncrono, se for alterado para não-bloqueio assíncrono, o processo pode ser encerrado antes que o serviço esteja offline, causando uma exceção)
Uso 1: Solicite diretamente http://localhost:8881/offline , você pode encerrar o processo e reiniciar após a resposta ser bem-sucedida
Uso 2: Combinado com a implantação do jenkins, adicione http://localhost:8881/offline ao shell script, execute o shell script durante o processo de compilação do jenkins, elimine o processo e reinicie após a conclusão da compilação
Que tal isso? Se você achar útil, não hesite em iniciá-lo! ! !
Anexo: o diretório do código envolvido
github: https://github.com/897665787/springcloud-template
gitee: https://gitee.com/jq_di/springcloud-template
springcloud-template
└── template-eureka
eureka.server.use-read-only-response-cache: false -- 禁用readOnlyCacheMap
└── template-framework
└── deploy
└── DeployController -- 部署相关接口（用于优雅发版）
└── MQAutoRefresh -- MQ自动刷新注册列表(如果使用了MQ，可以利用MQ广播消息自动刷新)
└── RefreshHandler -- 刷新处理器
└── StartupApplicationRunner -- 服务启动成功执行