Como migrar entre provedores de RPC com zero downtime

Times adiam trocar de provedor de RPC porque parece que vão ter que reconstruir tudo. Na maioria das vezes são algumas horas de configuração. Todo provedor relevante segue o mesmo padrão JSON-RPC, então a requisição que seu app envia hoje é a mesma requisição que o novo provedor espera amanhã. Migrar de provedor de RPC é trocar um endpoint, não reescrever o código.

O trabalho que resta fica em volta da troca, não dentro dela: encontrar todos os lugares onde uma URL de endpoint está escondida, mapear o punhado de chamadas específicas do provedor que não se transferem, e fazer o corte de tráfego em uma ordem que seus usuários nunca percebem.

O que significa compatibilidade drop-in de endpoint?

Compatibilidade drop-in de endpoint significa que dois provedores de RPC aceitam as mesmas requisições e retornam as mesmas respostas para métodos JSON-RPC padrão. Uma aplicação troca de provedor mudando a URL do endpoint que chama. Nomes de métodos, parâmetros e formatos de resposta permanecem idênticos, então a superfície padrão não exige nenhuma mudança de código.

A compatibilidade vem do protocolo, não de algum acordo entre provedores. eth_call, eth_getLogs, eth_sendRawTransaction, e o resto das famílias eth_*, net_* e web3_* são definidos pela especificação JSON-RPC do Ethereum, e todo provedor sério os implementa conforme a especificação. O mesmo vale para streaming. eth_subscribe via WebSocket carrega os mesmos streams newHeads, logs e newPendingTransactions nos nossos endpoints de subscription que em qualquer outro provedor relevante.

Aqui está o formato do nosso endpoint ao lado do padrão que a maioria dos outros provedores usa:

Ambos são uma URL com um secret no path. Se o seu endpoint vive em uma variável de ambiente, migrar seu tráfego padrão significa mudar o valor dessa variável. É também por isso que a recomendação padrão de confiabilidade de manter um endpoint de RPC de backup configurado funciona como seguro de migração. O mecanismo de fallback que você adicionaria para uptime é o mesmo mecanismo que você usa para trocar.

Chamadas JSON-RPC padrão rodam no novo provedor sem mudanças. O trabalho se esconde onde quer que seu app dependa de algo específico do provedor, e encontrar esses lugares é para isso que serve a auditoria.

O que você deve auditar antes de migrar?

A maioria das surpresas em uma migração de provedor é descoberta depois da troca, e todas elas poderiam ter sido encontradas antes. Para uma base de código típica, a auditoria leva uma ou duas horas.

Encontre toda referência a endpoint. URLs de endpoint se acumulam em mais lugares do que qualquer um lembra. Procure em arquivos de ambiente, configs do Hardhat e Foundry, imagens Docker, pipelines de CI e builds de frontend pelo domínio do provedor atual e por qualquer URL hardcoded. A referência que você não encontra costuma estar em um cron job ou em um pipeline de CI que ninguém abre há meses.

Mapeie métodos com prefixo de provedor. A maioria dos provedores oferece métodos de conveniência sob um prefixo próprio (o nosso é alchemy_), e esses não se transferem entre plataformas. Consultas de token mapeiam para equivalentes da Data API como alchemy_getTokenBalances, e histórico de transferências vai para alchemy_getAssetTransfers. Os equivalentes existem, mas os formatos de resposta são diferentes, então trate cada um como uma pequena mudança de código, não como um find-and-replace.

Verifique como você autentica. Uma chave no path da URL se transfere sem problemas. Se você autentica com um header x-token ou com JWTs, esses controles precisam ser recriados no novo provedor. Do nosso lado, allowlists de domínio e IP ficam no dashboard da Alchemy e levam poucos minutos para configurar.

Reavalie o preço do seu tráfego sob o novo modelo de medição. Este é o item da auditoria que afeta sua fatura, não seu código. Muitos provedores medem um orçamento fixo de requisições por segundo. Nós medimos compute units, onde uma chamada leve como eth_blockNumber custa menos que uma chamada pesada como eth_getLogs, e o throughput é uma taxa de compute units em uma janela móvel, não uma contagem fixa de requisições. O efeito vai nos dois sentidos. Workloads de indexação pesados em logs consomem orçamento mais rápido do que sua contagem de requisições sugere, enquanto workloads de polling leve consomem menos. A maioria das equipes calcula o preço da hora de tráfego real mais movimentada contra nossos preços antes de trocar, em vez de estimar a partir de totais mensais.

Verifique o gating de plano em métodos de trace e debug. Métodos debug_ e trace_ são limitados por plano na maioria dos provedores. Na Alchemy eles estão disponíveis nos planos pay-as-you-go e enterprise, mas não no tier gratuito, então se você rodar sua prova de conceito em um endpoint gratuito, espere que chamadas de trace falhem ali mesmo que tudo o mais funcione.

Nenhum desses itens bloqueia uma migração, mas juntos eles definem seu escopo. Para a maioria dos apps, a auditoria termina com uma lista curta de variáveis de ambiente, um ou dois mapeamentos de métodos, e uma estimativa de preço.

Como fazer o corte de tráfego sem downtime?

O padrão de zero downtime é o mesmo que equipes usam para migrações de banco de dados. Rode o antigo e o novo em paralelo, mova o tráfego em estágios, e mantenha o caminho antigo ativo até que o novo tenha conquistado confiança.

Bibliotecas de cliente tornam a fase paralela quase gratuita. O fallback transport do viem recebe uma lista ordenada de endpoints e desce a lista quando um falha:

Com o novo provedor em primeiro e o antigo em segundo, toda requisição tenta o novo endpoint e cai de volta para o que já estava funcionando. Seu pior caso durante o corte é a configuração que você já tem hoje. O ethers.js oferece o mesmo padrão no FallbackProvider, com uma opção de quorum que consulta vários provedores e aceita um resultado quando concordam, o que te dá verificações de concordância entre provedores dentro do próprio cliente.

A ordem em que você move o tráfego importa mais do que a velocidade com que você o move, e o princípio é leituras primeiro, escritas por último. Leituras são stateless e fáceis de verificar, então direcione o tráfego de leitura para o novo endpoint cedo e compare o que volta. Rode suas queries mais pesadas nos dois provedores, eth_getLogs sobre os ranges de bloco mais movimentados dos seus contratos e eth_call contra seus contratos principais, e compare as respostas. O envio de transações se move por último, depois que as leituras já rodaram sem problemas, porque uma leitura falha é uma nova tentativa e uma escrita falha é um chamado de suporte.

Subscriptions via WebSocket precisam de um passo extra. Uma subscription está vinculada à conexão que a criou, então ela não faz failover. Ela cai, e você a recria. Planeje se reinscrever no novo endpoint e preencher a lacuna com uma query eth_getLogs sobre os blocos que passaram durante a reconexão, para que nenhum evento se perca. Nossas boas práticas de WebSocket também recomendam manter o escopo da subscription estreito, o que torna tanto a reinscrição quanto o preenchimento mais baratos.

Duas coisas merecem um dashboard durante a execução em paralelo. A primeira é o atraso de altura de bloco. Dois provedores saudáveis podem estar em tips de chain ligeiramente diferentes a qualquer momento, então alerte quando o novo endpoint ficar consistentemente atrás do antigo, não em diferenças momentâneas. A segunda é o formato de erro. Respostas de rate limit diferem entre provedores. Sobre HTTP, as nossas retornam um 429 com um header Retry-After; sobre WebSocket, o mesmo limite aparece como um erro JSON-RPC 429 sem header. Exercite sua lógica de retry contra o novo endpoint, nos dois transportes que você usa, antes que ele carregue tráfego de produção.

A maioria das equipes dá à fase paralela um ou dois dias de tráfego de produção, e então torna o novo endpoint o padrão. Mantenha o endpoint antigo configurado como fallback até o período de cobrança dele acabar. O rollback fica a uma mudança de configuração de distância o tempo todo, e é isso que zero downtime significa na prática. Coisas ainda podem dar errado. Elas só nunca precisam chegar aos seus usuários.

Como saber se o novo provedor está se saindo bem?

A comparação que você rodou durante a fase paralela se torna sua baseline. Depois da troca, continue observando os números que você comparou antes: taxa de sucesso, latência p95 e frescor de bloco. Se a migração valeu a pena, pelo menos um desses deve se mover a seu favor.

Você também não precisa confiar em alegações de latência por fé. Nossos benchmarks de RPC ao vivo nos comparam com outros provedores relevantes em diversas chains e regiões, e a metodologia por trás deles é pública, então você pode reproduzir os números a partir da sua própria região antes de se comprometer. Para a história mais profunda de por que esses números se mantêm sob carga, nossa reconstrução do edge proxy percorre a camada de roteamento que toda requisição atinge primeiro.

E se você ainda está avaliando provedores em vez de verificar um, nosso guia para escolher um provedor de nó e o guia de avaliação de RPC enterprise cobrem as perguntas que valem a pena fazer antes mesmo da questão da migração surgir.

Mantenha as verificações da execução paralela ativas depois que a migração terminar. Os diffs de resposta e os dashboards de latência que validaram o corte de tráfego vão sinalizar regressões de provedor e dados desatualizados meses depois, e eles já estão construídos.

Pronto para trocar de provedor de RPC?

Qualquer que seja o provedor que você está deixando, tudo acima se aplica como está escrito.

Crie um endpoint gratuito no dashboard da Alchemy e aponte seu ambiente de staging para ele hoje. Sem contratos, sem chamada de vendas, sem compromisso mínimo. O tier gratuito inclui 30M compute units por mês, suficiente para rodar toda a comparação da fase paralela em tráfego real de produção, e a mesma troca de endpoint funciona nas mais de 100 chains que suportamos.