Estamos construindo o celld, um runtime para aplicativos Cloudflare Workers e Durable Objects nas suas próprias máquinas. Pode executar com um armazenamento de objetos compatível com S3 como única dependência de serviço externo.
celld é um sistema distribuído. Construir sistemas distribuídos confiáveis é difícil, parcialmente porque podemos depender involuntariamente de suposições que não se sustentam na prática, mesmo quando conhecemos os perigos. A lista de Peter Deutsch os oito erros do computação distribuída lista oito suposições, incluindo "The network is reliable" e "Latency is zero."
Um bug pode depender de uma sequência particular de mensagens atrasadas, gravações falhas e reinicialização de nós. Esses eventos podem acontecer em uma ordem diferente na próxima rodada de testes, tornando a falha difícil de reproduzir. Precisamos ser capazes de repetir a execução com falha para que possamos investigar a causa e verificar se uma proposta de correção realmente resolve o problema. Por isso usamos simulação determinista (DST).
Nosso simulador ainda está em desenvolvimento e não está incluído no repositório público do celld, mas já encontrou bugs anteriormente desconhecidos. Neste artigo, passaremos por como o DST funciona no celld e como ele nos ajudou a encontrar, reproduzir e corrigir um desses bugs. O DST executa o código de produção do celld em um ambiente controlado por um simulador. Uma célula no celld executa código de aplicação e tem seu próprio banco de dados SQLite. À medida que as células fazem seu trabalho, o celld lida com eventos como solicitações entrantes, operações de armazenamento concluídas e disparos de temporizadores. O código que seleciona o próximo evento é separado do código que o lida. Isso permite que o simulador controle a ordem dos eventos enquanto roda o mesmo código de manipulação de eventos que em produção.
Fonte: Hacker News · Resumido por HeadlinesBriefing