O Cloudflare Workers fornece um ambiente de execução Serverless que permite criar aplicativos totalmente novos ou aumentar os existentes sem configurar, ou manter a infraestrutura. O Cloudflare Workers é executado na rede global de nuvem da Cloudflare, a sua principal vantagem é a arquitetura existente com datacenters espalhados por mais de 200 cidades globalmente, oferecendo planos gratuitos e pagos.
Como Cloudflare Workers trabalha?
Embora os Cloudflare Workers se comportem de maneira semelhante ao JavaScript no navegador ou no Node.js, existem algumas diferenças em como você deve pensar sobre o seu código. Sob o capô, o tempo de execução dos Workers usa o mecanismo V8 — o mesmo mecanismo usado pelo Chromium e Node.js. O tempo de execução dos Workers também implementa muitas das APIs padrões disponíveis na maioria dos navegadores modernos.
As diferenças entre JavaScript escrito para o navegador ou Node.js acontecem em tempo de execução. Em vez de ser executado na máquina de um indivíduo (por exemplo, um aplicativo de navegador ou num servidor centralizado), as funções dos Cloudflare Workers são executadas na Edge Network da Cloudflare – uma rede global crescente de milhares de máquinas distribuídas em centenas de locais.
Cada uma dessas máquinas hospeda uma instância do tempo de execução dos Trabalhadores e cada um desses tempos de execução consegue executar milhares de aplicativos definidos pelo usuário. Este guia revisará algumas dessas diferenças.
As três maiores diferenças são: Isolados, Computação por Solicitação e Execução Distribuída.
Isolates cloudflare Workers
O V8 orquestra isolados: contextos leves que fornecem ao seu código variáveis que ele pode acessar e um ambiente seguro para ser executado. Você pode até considerar isolar um sandbox para que a sua função seja executada.
Um único tempo de execução pode executar centenas ou milhares de Isolate, alternando perfeitamente entre eles. A memória de cada Isolate é completamente isolada, portanto, cada pedaço de código é protegido de outro código não confiável ou escrito pelo usuário no tempo de execução.
Os Isolate também são projetados para iniciar muito rapidamente. Em vez de criar uma máquina virtual para cada função, é criado um isolado dentro de um ambiente existente. Este modelo elimina as partidas a frio do modelo de máquina virtual.
Ao contrário de outros provedores sem servidor que usam processos em contêiner, cada um executando uma instância de um tempo de execução de linguagem, o Workers paga a sobrecarga de um tempo de execução de JavaScript uma vez no início de um contêiner de borda. Os processos Workers são capazes de executar scripts essencialmente ilimitados com quase nenhuma sobrecarga individual, criando um isolado para cada chamada de função Workers.
Qualquer Isolate pode iniciar cerca de cem vezes mais rápido que um processo Node em um contêiner ou máquina virtual. Notavelmente, na inicialização, os isolados consomem uma ordem de magnitude menos memória. Um dado Isolate tem o seu próprio escopo, mas isolados não são necessariamente de longa duração. Um isolado pode ser desfeito e despejado por vários motivos:
- Limitações de recursos na máquina.
- Um script suspeito – qualquer coisa vista como uma tentativa de sair da
sandbox Isolate. - Limites de recursos individuais.
Por causa disso, geralmente é aconselhável que você não armazene o estado mutável no seu escopo global, a menos que tenha considerado essa contingência.
Computação por requisição
A maioria dos scripts de Workers é uma variação do fluxo de Trabalhadores padrão:
// código executado em uma aplicação Cloudflare Workers
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request));
});
async function handleRequest(request) {
return new Response('Hello worker!', { status: 200 });
}Code language: JavaScript (javascript)Quando uma solicitação ao seu subdomínio *.workers.dev ou ao seu domínio gerenciado pela Cloudflare é recebida por qualquer um dos tempos de execução da Cloudflare, o script Workers recebe um argumento FetchEvent para o manipulador de eventos definido no script. A partir daí, você pode gerar uma resposta calculando uma resposta no local, chamando para outro servidor usando fetch, etc.
Os ciclos de CPU necessários para chegar ao ponto da chamada respondWith contribuem para o tempo de computação. Por exemplo, um tempo limite setInterval não consome ciclos de CPU enquanto espera.
Execução distribuída
Os Isolate são resilientes e continuamente disponíveis durante uma solicitação, mas em casos raros os isolados podem ser despejados. Quando um script atinge os limites oficiais ou quando os recursos são excepcionalmente limitados na máquina onde a solicitação está sendo executada, o tempo de execução despeja seletivamente os isolados após os seus eventos serem resolvidos adequadamente.
Como todas as outras plataformas JavaScript, uma única instância de Workers pode lidar com várias solicitações, incluindo solicitações simultâneas num loop de eventos de thread único. Isso significa que outras solicitações podem (ou não) ser processadas durante a espera de qualquer tarefa assíncrona (como fetch) se outras solicitações forem recebidas durante o processamento de uma solicitação.
Como não há garantia de que duas solicitações de usuário serão roteadas para a mesma ou para uma instância diferente do seu Worker, recomendamos que você não use ou altere o estado global.
Conclusão
Em 2019 eu utilizei alguns serviços serverless, de lá pra cá não tive mais contato com a arquitetura, recentemente tive contato com cloudflare Workers e estou impressionado com a estrutura criada pela Cloudflare, a infraestrutura já existente para serviços de CDN ajudou a criar uma rede distribuída muito eficiente. Além da sua comunidade ativa com o discord com mais de 18 mil participantes e uma ótima documentação.
Fonte: https://developers.cloudflare.com/workers/learning/how-workers-works/
Gostou do conteúdo sobre Cloudflare Workers, confira mais posts relacionados.
Deixe um comentário