Olá novamente!.. Na véspera do início do curso preparamos mais uma tradução útil.
Service Mesh é uma camada de infraestrutura configurável de baixa latência, necessária para gerenciar um grande volume de comunicações entre processos de rede entre interfaces de programação de aplicativos (API). O Service Mesh fornece comunicação rápida, confiável e segura entre serviços em contêineres que frequentemente são efêmeros. O Service Mesh oferece funcionalidades como descoberta de serviços, balanceamento de carga, criptografia, transparência, rastreabilidade, autenticação e autorização, assim como suporte ao padrão de quebra de circuito (circuit breaker).
O Service Mesh geralmente é implementado fornecendo uma instância de proxy para cada instância do serviço, chamada de Sidecar. Sidecar processam comunicações entre serviços, realizam monitoramento e solucionam problemas de segurança, ou seja, tudo o que pode ser abstraído dos serviços individuais. Assim, os desenvolvedores podem escrever, manter e operar o código do aplicativo nos serviços, enquanto os administradores de sistema podem trabalhar com o Service Mesh e executar o aplicativo.
O Istio, da Google, IBM e Lyft, é atualmente a arquitetura de Service Mesh mais conhecida. E o Kubernetes, que foi originalmente desenvolvido no Google, agora é o único framework de orquestração de contêineres suportado pelo Istio. Os fornecedores estão tentando criar versões comerciais suportadas do Istio. É interessante ver o que de novo eles poderão trazer ao projeto de código aberto.
No entanto, o Istio não é a única opção, pois outras implementações de Service Mesh estão sendo desenvolvidas. O padrão sidecar proxy é a implementação mais popular, como pode ser observado em projetos como Buoyant, HashiCorp, Solo.io e outros. Existem arquiteturas alternativas: a ferramenta tecnológica da Netflix é uma das abordagens, onde a funcionalidade do Service Mesh é realizada por meio das bibliotecas Ribbon, Hysterix, Eureka, Archaius, além de plataformas como Azure Service Fabric.
O Service Mesh também possui sua própria terminologia para componentes de serviços e funções:
- Framework de orquestração de contêineres. À medida que mais e mais contêineres são adicionados à infraestrutura do aplicativo, surge a necessidade de uma ferramenta dedicada para monitorar e gerenciar contêineres — um framework de orquestração de contêineres. O Kubernetes ocupa esse nicho de forma tão eficiente que até mesmo seus principais concorrentes, Docker Swarm e Mesosphere DC/OS, oferecem integração com o Kubernetes como alternativa.
- Serviços e instâncias (pods do Kubernetes). A instância é uma única cópia em execução de um microsserviço. Às vezes, uma instância é um único contêiner. No Kubernetes, uma instância consiste em um pequeno grupo de contêineres independentes, chamado de pod. Os clientes raramente se comunicam diretamente com a instância ou pod; na maioria das vezes, eles interagem com o serviço, que representa um conjunto de instâncias ou pods (réplicas) idênticos, escaláveis e tolerantes a falhas.
- Proxy Sidecar. O Proxy Sidecar funciona com uma única instância ou pod. A essência do Proxy Sidecar é direcionar ou fazer proxy do tráfego que chega do contêiner com o qual trabalha, assim como do tráfego de retorno. O Sidecar interage com outros Proxies Sidecar e é gerenciado pelo framework de orquestração. Muitas implementações de Service Mesh utilizam Proxy Sidecar para interceptar e gerenciar todo o tráfego de entrada e saída da instância ou pod.
- Descoberta de serviços. Quando uma instância precisa se comunicar com outro serviço, ela precisa encontrar (descobrir) uma instância disponível e funcional desse serviço. Normalmente, a instância faz a pesquisa através de DNS. O framework de orquestração de contêineres mantém uma lista de instâncias prontas para receber requisições e fornece uma interface para consultas DNS.
- O balanceamento de carga. A maioria dos frameworks de orquestração de contêineres fornece balanceamento de carga no nível 4 (transporte). O Service Mesh implementa um balanceamento de carga mais complexo no nível 7 (aplicação), rico em algoritmos e mais eficaz na gestão do tráfego. Os parâmetros de balanceamento de carga podem ser alterados por meio de API, permitindo orquestrar uma implantação blue-green ou canary.
- Criptografia. O Service Mesh pode criptografar e descriptografar solicitações e respostas, aliviando essa carga dos serviços. O Service Mesh também pode melhorar o desempenho, priorizando ou reutilizando conexões persistentes existentes, o que reduz a necessidade de computação dispendiosa para criar novas conexões. A implementação mais comum de criptografia de tráfego é mutual TLS (mTLS), onde a infraestrutura de chave pública (PKI) gera e distribui certificados e chaves para serem utilizados no Sidecar Proxy.
- Autenticação e autorização. O Service Mesh pode autorizar e autenticar solicitações feitas de fora ou dentro da aplicação, enviando instâncias apenas de solicitações validadas.
- Suporte ao padrão de desligamento automático. O Service Mesh suporta , que isola instâncias não saudáveis e, em seguida, as retorna gradualmente ao pool de instâncias saudáveis quando necessário.
A parte do aplicativo Service Mesh que gerencia o tráfego de rede entre instâncias é chamada de Data Plane. A criação e implantação da configuração, que gerencia o comportamento Data Plane, é realizada por meio de um Control Plane. Control Plane que geralmente inclui ou é projetado para se conectar a APIs, CLIs ou GUIs para gerenciar o aplicativo.
O Control Plane no Service Mesh distribui a configuração entre o Sidecar Proxy e o Data Plane.
Frequentemente, a arquitetura do Service Mesh é aplicada para resolver desafios operacionais complexos usando contêineres e microsserviços. Pioneiros na área incluem empresas como Lyft, Netflix e Twitter, que fornecem serviços estáveis a milhões de usuários em todo o mundo. (). Para tarefas de aplicativos menos exigentes, provavelmente bastará uma arquitetura mais simples.
A arquitetura do Service Mesh dificilmente será a resposta para todas as questões relacionadas ao funcionamento das aplicações e sua entrega. Arquitetos e desenvolvedores têm um enorme arsenal de ferramentas, sendo que uma delas é o martelo, que deve resolver apenas uma tarefa entre muitas – pregar pregos. , por exemplo, inclui vários modelos diferentes que oferecem um espectro contínuo de abordagens para resolver problemas com microserviços.
Os elementos que se unem na arquitetura Service Mesh, como NGINX, contêineres, Kubernetes e microserviços como abordagem arquitetônica, podem ser utilizados de forma igualmente produtiva em implementações sem Service Mesh. Por exemplo, o Istio foi desenvolvido como uma arquitetura Service Mesh completa, mas a modularidade permite que os desenvolvedores escolham e apliquem apenas os componentes tecnológicos de que precisam. Tendo isso em mente, é necessário formar uma compreensão clara do conceito de Service Mesh, mesmo que você não esteja certo de que algum dia conseguirá implementá-lo integralmente em sua aplicação.
Fonte: habr.com
