English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

visitante
1 / ?

Nós, Pontes, Direções

Uma Solicitação como Caminhada em um Gráfico

Cada componente que uma solicitação toca é um : cliente, resolvente DNS, borda da CDN, proxy reverso, réplica de back-end, banco de dados, cache.

Cada conexão entre dois nós é uma ponte direcionada: as solicitações fluem para frente, as respostas fluem de volta. A ponte para frente representa uma conexão TCP aberta mais o protocolo em cima.

Uma única solicitação é uma ponte neste gráfico. O total de trabalho que o sistema faz para responder à solicitação é igual à soma do trabalho em cada nó, mais a latência de cada ponte.

Por que se importar? Assim que desenhar o gráfico, propriedades que são invisíveis no código saltam:

- Contagem de saltos: o número de pontes na rota. Cada salto adiciona latência (retornar de rede + processamento do nó). Menos saltos = piso mais baixo na latência.

- Grau de entrada: quantas pontes apontam PARA UM nó. Alto grau de entrada significa que o nó recebe solicitações de muitos originais e deve escalar ou se proteger.

- Grau de saída: quantas pontes apontam DE UM nó. Alto grau de saída significa que o nó depende de muitos downstreams e tem muitas maneiras de falhar.

- Vértice de corte: um único nó cuja remoção desconecta o gráfico. Um proxy reverso sem parceiro é um vértice de corte; removê-lo remove todo o acesso aos seus originais.

Solicitação como caminho através do gráfico direcionado: cliente, proxy, back-end, banco de dados

Desenhe (ou descreva em texto) o gráfico de solicitação para: navegador do cliente -> borda da CDN -> proxy reverso -> réplica de back-end -> banco de dados. Conte os saltos. Identifique os vértices de corte. Preeça uma consequência operacional de ter muitos vértices de corte em fila.

Onde o tráfego se concentra

Fan-In = Concentração

Grau de entrada de uma nó = número de arestas apontando para ele. Em uma rede de solicitações, grau de entrada = número de fontes de upstream que enviaram solicitações.

Padrão de fan-in: muitos clientes -> um CDN; muitos bordos CDN -> poucas proxies de origem; muitos proxies -> menos réplicas de back-end; muitos backends -> única base de dados.

**Importa a concentração porque a nó de maior grau de entrada vê a maior carga agregada. A DB no final da cadeia pode ver consultas de cada solicitação ativa no sistema, mesmo se nenhuma única usuário gera muito.

Fan-Out = Dependência

Grau de saída de uma nó = número de arestas apontando para fora dele. Alto grau de saída significa muitas dependências downstream.

Uma réplica de back-end que chama uma base de dados, dois caches, três APIs externos e uma fila tem saída 7. Sua probabilidade de sucesso é aproximadamente o produto de cada downstream's probabilidade de sucesso (se todas forem necessárias para uma resposta bem-sucedida).

0,999 ^ 7 ≈ 0,993: uma réplica de back-end com 7 downstreams cada um com 99,9% de confiabilidade pode atingir apenas ~99,3% de confiabilidade, mesmo sem erros próprios.

Reduzir o grau de saída por: armazenar resultados downstream em cache, tornar não-críticos downstreams opcionais (degradação graciosa), parallelizar o que pode ser parallel.

A Asimetria

O fan-in concentra a carga; o fan-out multiplica o risco. Uma rede bem-formada minimiza ambos nos nós de maior impacto.

A base de dados (maior fan-in): cache agressivamente para reduzir a carga. Réplicas de leitura para espalhar o fan-in entre vários nós.

O serviço de orquestrador (maior fan-out): circuit breakers por dependência, degradação graciosa, bulkheads.

Uma réplica de back-end chama 4 serviços downstream, cada um independentemente com 99,95% de disponibilidade. (1) Qual é o limite superior de disponibilidade do back-end se todas as 4 chamadas forem necessárias para uma resposta bem-sucedida? (2) Se 2 dos 4 downstreams forem tornados opcionais via degradação graciosa (substituídos por fallbacks em cache quando indisponíveis), qual será o limite?

Um Nó Inserido Compra Flexibilidade

Indireção = Adicionar um Nó Intermediário

Sem um proxy, o gráfico é: cliente -> backend. O cliente deve saber sobre a endereço do backend. Mover o backend requer atualizar o cliente (via DNS ou configuração). Isso é uma ligação apertada.

Com um proxy, o gráfico se torna: cliente -> proxy -> backend. O cliente sabe apenas sobre o proxy. Mover o backend requer atualizar a configuração de upstream do proxy, não o cliente.

A operação do gráfico: inserir um nó ao longo de uma borda existente. A nova borda cliente -> proxy é estável; a nova borda proxy -> backend é agora a equipe para gerenciar.

Leitura geométrica: a indireção adiciona uma camada que desacopla o upstream do downstream. Cada camada pode recolocar as bordas independentemente.

Custos da Indireção

Cada camada adiciona:

- Uma latência de salto (a borda de cliente para proxy)

- Mais um vértice de corte (o proxy em si)

- Mais um lugar onde a configuração pode falhar

Os benefícios (recolocar, escalar, abrigar, terminar TLS, distribuir carga) geralmente superam os custos para qualquer sistema não trivial. Mas há um limite: cada camada de indireção adiciona mais um salto & outro candidato a SPOF.

A regra do povo: qualquer problema pode ser resolvido adicionando uma camada de indireção (exceto o problema de muitas camadas de indireção).

Uma equipe adiciona um CDN na frente de um proxy existente. A rota vai de `cliente -> proxy -> backend` (2 saltos) para `cliente -> CDN -> proxy -> backend` (3 saltos). Nomeie dois benefícios da indireção (termos gráficas-teóricas bem-vindas) & dois custos.

Ler uma Arquitetura como um Gráfico

Síntese

Agora você pode ler uma arquitetura de sistema como um gráfico: contar saltos, identificar vértices de corte, medir concentração de entrada em ângulo, calcular teto de disponibilidade a partir de saída em ângulo e avaliar os contrapés de indireção.

Aplicar todos os quatro.

Uma nova service tem essa arquitetura: clientes -> CDN -> reverse proxy (2 replicas) -> camada de backend (8 replicas) -> { DB primário, cluster de cache (3 nós), external API }.

Analisar: (1) qual é o máximo número de saltos em uma única rota de solicitação, (2) qual camada tem o maior nível de entrada em ângulo (& o que implica para a escala), (3) qual é o teto de disponibilidade do backend se o DB é 99,95%, o cache é 99,95% e a API externa é 99,9%, todos necessários, e (4) qual único nó, se removido, desconectaria o maior número de usuários?

Notas de Companhia

Notas de Companhia

Essa geometria-aula reformula a Proxies & Origins aula principal como uma análise de gráfico direcionado.

A próxima companheira nessa série, geometry_of_stateless_horizontal_scaling, toma a matemática de replica da aula principal de escalabilidade e deriva a curva de fila, a Lei de Little e a perna geométrica de 80% de utilização.

Bem feito.