Observação. trad.: Service mesh é um fenômeno que ainda não tem uma tradução estável para o russo (há mais de 2 anos oferecemos a opção “mesh para serviços” e, um pouco mais tarde, alguns colegas começaram a promover ativamente a combinação “peneira de serviço”) . A conversa constante sobre esta tecnologia levou a uma situação em que os componentes técnicos e de marketing estão intimamente interligados. Este maravilhoso material de um dos autores do termo original tem como objetivo trazer clareza aos engenheiros e não só.
Quadrinhos de
Introdução
Se você é um engenheiro de software que trabalha em algum lugar na área de sistemas back-end, o termo “malha de serviço” provavelmente já se tornou firmemente arraigado em sua mente nos últimos dois anos. Graças a uma estranha coincidência, esta frase está tomando conta cada vez mais da indústria, e o hype e as ofertas promocionais relacionadas estão crescendo como uma bola de neve, voando colina abaixo e não dando sinais de desaceleração.
A malha de serviço nasceu nas águas turvas e tendenciosas do ecossistema nativo da nuvem. Infelizmente, isto significa que grande parte da controvérsia em torno do assunto vai desde “conversas de baixas calorias” até – para usar o termo técnico – besteiras descaradas. Mas se você filtrar todo o ruído, descobrirá que a malha de serviço tem uma função muito real, definida e importante.
Neste post, tentarei fazer exatamente isso: fornecer um guia honesto, aprofundado e orientado para o engenheiro sobre a malha de serviço. Vou responder mais do que apenas a pergunta: "O que é isso?", - mas também "Pelo que?"E "Porque agora?". Por fim, tentarei descrever por que (na minha opinião) essa tecnologia em particular causou tanto entusiasmo, o que por si só é uma história interessante.
Quem eu sou
Olá a todos! Meu nome é . Eu sou um dos criadores - o primeiro projeto de malha de serviço e o projeto responsável pelo surgimento do termo malha de serviço como tal (desculpe pessoal!). (Nota trad.: Aliás, no início do surgimento deste termo, há mais de 2,5 anos, já traduzíamos o material inicial do mesmo autor denominado "".) Eu também lidero é uma startup que cria coisas interessantes de malha de serviço como Linkerd e .
Você provavelmente pode adivinhar que tenho uma opinião muito tendenciosa e subjetiva sobre esse assunto. No entanto, tentarei manter o preconceito ao mínimo (com exceção de uma seção: “Por que se fala tanto sobre a malha de serviço?”, - no qual, no entanto, compartilharei minhas ideias preconcebidas). Também farei o meu melhor para tornar este guia o mais objetivo possível. Em exemplos específicos, contarei principalmente com a experiência do Linkerd, ao mesmo tempo em que apontarei as diferenças (se houver) que conheço na implementação de outros tipos de service mesh.
Ok, é hora de passar para as guloseimas.
O que é uma malha de serviço?
Apesar de todo o hype, a malha de serviço é estruturalmente bastante simples. É apenas um monte de proxies de espaço de usuário localizados “próximos” aos serviços (falaremos um pouco sobre “próximo” mais tarde), além de um conjunto de processos de controle. Os proxies são chamados coletivamente plano de dados, e os processos de controle são chamados plano de controle. O plano de dados intercepta chamadas entre serviços e faz “qualquer coisa diferente” com eles; o plano de controle, respectivamente, coordena o comportamento do proxy e fornece acesso para você, ou seja, operadora, à API, permitindo que a rede seja manipulada e medida como um todo.
O que é esse procurador? Este é um proxy TCP da categoria "Layer 7-aware" (ou seja, "levando em consideração" a 7ª camada do modelo OSI) como HAProxy e NGINX. Você pode escolher um proxy de sua preferência; Linkerd usa um proxy Rust, de nome simples . Nós o compilamos especificamente para a malha de serviço. Outras malhas preferem outros proxies (Envoy é uma escolha comum). No entanto, a escolha de um proxy é apenas uma questão de implementação.
O que esses servidores proxy fazem? Obviamente, eles fazem proxy de chamadas de e para serviços (a rigor, atuam como proxies e proxies reversos, lidando com chamadas de entrada e de saída). E eles implementam um conjunto de recursos focado em chamadas entre Serviços. Esse foco no tráfego entre serviços é o que distingue um proxy de malha de serviço de, digamos, gateways de API ou proxies de entrada (estes últimos focando em chamadas vindas do mundo externo para o cluster). (Observação. trad.: Para uma comparação dos controladores Ingress existentes do Kubernetes, muitos dos quais usam o já mencionado Envoy, consulte .)
Então, descobrimos o plano de dados. O plano de controle é mais simples: é um conjunto de componentes que fornecem toda a mecânica que o plano de dados precisa para funcionar de forma coordenada, incluindo descoberta de serviço, emissão de certificado TLS, agregação de métricas, etc. seu comportamento; por sua vez, o plano de controle fornece uma API que permite alterar e rastrear o comportamento do plano de dados como um todo.
Abaixo está um diagrama do plano de controle e do plano de dados no Linkerd. Como você pode ver, o plano de controle inclui vários componentes diferentes, incluindo uma instância do Prometheus que coleta métricas de servidores proxy, bem como outros componentes, como destination (descoberta de serviço), identity (autoridade de certificação, CA) e public-api (endpoints para web e CLI). Em contraste, o plano de dados é um proxy linkerd simples próximo à instância do aplicativo. Este é apenas um diagrama lógico; em uma implantação no mundo real, você pode ter três réplicas de cada componente do plano de controle e centenas ou milhares de proxies no plano de dados.
(As caixas azuis neste diagrama representam as bordas dos pods do Kubernetes. Você pode ver que os contêineres com o linkerd-proxy estão no mesmo pod que os contêineres do aplicativo. Esse esquema é conhecido como contêiner lateral.)
A arquitetura service mesh tem diversas implicações importantes. Primeiro, como a função de um proxy é interceptar chamadas entre serviços, uma malha de serviço só faz sentido se sua aplicação tiver sido construída para um conjunto de serviços. malha uma lata usar com monólitos, mas isso é claramente redundante para um único proxy, e é improvável que sua funcionalidade seja solicitada.
Outra consequência importante é que a malha de serviço exige enorme número de procuradores. Na verdade, o Linkerd encadeia um proxy linkerd para cada instância de cada serviço (outras implementações adicionam um proxy para cada host/host/VM. Isso é muito, de qualquer maneira). Esse uso ativo de um proxy por si só acarreta uma série de complicações adicionais:
- Os proxies no plano de dados devem ser velozes, porque para cada chamada há algumas chamadas para o proxy: uma no lado do cliente e outra no lado do servidor.
- Além disso, os proxies devem ser pequeno и leve. Cada um consumirá recursos de memória e CPU, e esse consumo crescerá linearmente com o aplicativo.
- Você precisará de um mecanismo para implantar e atualizar um grande número de proxies. Fazer isso manualmente não é uma opção.
Em geral, a malha de serviço se parece com isto (pelo menos do ponto de vista panorâmico): você implanta um monte de proxies de espaço de usuário que "fazem algo" com o tráfego interno entre serviços e usa o plano de controle para monitorá-los e gerenciá-los.
É hora da pergunta "Por quê?"
Para que serve uma malha de serviço?
Para aqueles que encontraram pela primeira vez a ideia de uma malha de serviço, é perdoável ficar um pouco surpreso. O design da malha de serviço significa que não apenas aumentará a latência do aplicativo, mas também consumir recursos e adicionará um monte de novos mecanismos na infraestrutura. Primeiro você configura uma malha de serviço e, de repente, precisa atender centenas (se não milhares) de proxies. A questão é: quem se voluntariará para isso?
A resposta a esta pergunta tem duas partes. Primeiro, os custos de transação associados à implantação desses proxies podem ser significativamente reduzidos devido a algumas mudanças que ocorrem no ecossistema (falaremos mais sobre isso posteriormente).
Em segundo lugar, tal dispositivo é, na verdade, uma ótima maneira de introduzir lógica adicional no sistema. E não apenas porque muitos novos recursos podem ser adicionados usando a malha de serviço, mas também porque isso pode ser feito sem interferir no ecossistema. Na verdade, todo o modelo de service mesh é baseado neste postulado: em um sistema multisserviço, não importa o que aconteça fazer serviços individuais, tráfego entre eles é o ponto ideal para adicionar funcionalidade.
Por exemplo, no Linkerd (como na maioria das malhas) a funcionalidade é focada principalmente em chamadas HTTP, incluindo HTTP/2 e gRPC*. A funcionalidade é bastante rica - pode ser dividida em três classes:
- Recursos relacionados fiabilidade. Solicitações de repetição, tempos limite, abordagem canário (divisão/redirecionamento de tráfego), etc.
- Recursos relacionados monitoramento. Agregação de taxas de sucesso, atrasos e volumes de solicitações para cada serviço ou destinos individuais; construção de mapas topológicos de serviços, etc.
- Recursos relacionados segurança. TLS mútuo, controle de acesso, etc.
* Do ponto de vista do Linkerd, o gRPC praticamente não é diferente do HTTP/2: ele apenas usa protobuf na carga útil. Do ponto de vista do desenvolvedor, essas duas coisas são, obviamente, diferentes.
Muitos desses mecanismos operam no nível de solicitação (daí o “proxy L7”). Por exemplo, se o serviço Foo fizer uma chamada HTTP para o serviço Bar, o linkerd-proxy do lado de Foo poderá balancear a carga de forma inteligente e rotear chamadas de instâncias de Foo para Bar com base na latência observada; pode repetir a solicitação se necessário (e se for idempotente); ele pode registrar o código de resposta e o tempo limite e assim por diante. Da mesma forma, o linkerd-proxy no lado da Barra pode rejeitar uma solicitação se ela não for permitida ou se o limite de solicitações for excedido; pode corrigir o atraso de sua parte, etc.
Os proxies também podem “fazer algo” no nível da conexão. Por exemplo, um linkerd-proxy no lado Foo pode iniciar uma conexão TLS, e um linkerd-proxy no lado Bar pode encerrá-la, e ambos os lados podem verificar os certificados TLS um do outro*. Isso fornece não apenas criptografia entre serviços, mas também uma maneira criptograficamente segura de identificar serviços: Foo e Bar podem “provar” que são quem dizem ser.
* “Amigo de um amigo” significa que o certificado do cliente também é verificado (TLS mútuo). No TLS "clássico", por exemplo, entre um navegador e um servidor, geralmente é verificado o certificado de apenas um lado (o servidor).
Quer operem no nível de solicitação ou de conexão, é importante enfatizar que todos os recursos do service mesh são operacional personagem. O Linkerd não consegue transformar a semântica da carga útil, como adicionar campos a um fragmento JSON ou fazer alterações em um protobuf. Falaremos sobre esse importante recurso mais tarde, quando falarmos sobre ESB e middleware.
Este é o conjunto de funcionalidades que o service mesh oferece. Surge a pergunta: por que não implementá-los diretamente na aplicação? E por que mexer com um proxy?
Por que uma malha de serviço é uma boa ideia
Embora os recursos da malha de serviço sejam cativantes, seu principal valor não reside realmente nos recursos. No final nós lata implementá-los diretamente na aplicação (mais tarde veremos que esta foi a origem do service mesh). Resumindo em uma frase, o valor de uma malha de serviço é: ele fornece funcionalidade crítica para executar software de servidor moderno de maneira consistente, em toda a pilha e independente do código do aplicativo.
Vamos analisar esta proposta.
«Funções críticas para executar software de servidor moderno". Se você estiver construindo um aplicativo de servidor transacional conectado à Internet pública que aceita solicitações do mundo externo e responde a elas em um curto espaço de tempo - por exemplo, um aplicativo da Web, um servidor de API e a grande maioria de outros aplicativos modernos - e se você implementá-lo como um conjunto de serviços que interagem de forma síncrona entre si, e se você está constantemente atualizando este software, adicionando novos recursos, e se você é forçado a manter este sistema em condições de funcionamento durante o processo de modificação - neste caso, parabéns, você está criando um software de servidor moderno. E todos esses ótimos recursos listados acima acabam sendo essenciais para você. O aplicativo deve ser confiável, seguro e você deve poder ver o que ele está fazendo. São essas questões que o service mesh ajuda a resolver.
(Ok, minha convicção de que esta abordagem é a maneira moderna de construir software de servidor apareceu no parágrafo anterior. Outros preferem desenvolver monólitos, "microsserviços reativos" e outras coisas que não se enquadram na definição dada acima. Essas pessoas provavelmente têm opinião diferente da minha e, por sua vez, acredito que estão "errados" - embora, em qualquer caso, a malha de serviço não seja muito útil para eles).
«Uniforme para toda a pilha". Os recursos fornecidos pela malha de serviço não são apenas críticos. Eles se aplicam a todos os serviços de uma aplicação, independentemente da linguagem em que foram escritos, da estrutura usada, de quem os escreveu, de como foram implantados e de todas as outras sutilezas de seu desenvolvimento e uso.
«Código de aplicação independente". Por fim, a malha de serviço não apenas fornece funcionalidade consistente em toda a pilha, mas também de uma forma que não requer edição do aplicativo. A base fundamental da funcionalidade de um service mesh, incluindo as tarefas de configuração, atualização, operação, manutenção, etc., está exclusivamente no nível da plataforma e é independente da aplicação. A aplicação pode mudar sem afetar a malha de serviço. Por sua vez, a malha de serviço pode mudar sem qualquer intervenção do aplicativo.
Resumindo, a malha de serviço não apenas fornece funcionalidades vitais, mas também o faz de maneira global, uniforme e independente da aplicação. E assim, embora a funcionalidade de uma malha de serviço possa ser implementada no código de um serviço (por exemplo, como uma biblioteca incluída em cada serviço), esta abordagem não fornecerá a uniformidade e independência que são tão valiosas no caso de um serviço. malha de serviço.
E tudo que você precisa fazer é adicionar vários proxies! Eu prometo que muito em breve analisaremos os custos operacionais associados à adição desses proxies. Mas primeiro vamos parar e olhar para esta ideia de independência da perspectiva de vários pessoas.
Quem a malha de serviço ajuda?
Por mais inconveniente que seja, para que uma tecnologia se torne uma parte importante do ecossistema, ela deve ser aceita pelas pessoas. Então, quem está interessado em uma malha de serviço? Quem se beneficia com seu uso?
Se você desenvolve software de servidor moderno, pode imaginar aproximadamente sua equipe como um grupo proprietários de serviçosque juntos desenvolvem e implementam lógica de negócios, e proprietários de plataformaenvolvido no desenvolvimento da plataforma interna em que estes serviços funcionam. Em pequenas organizações, podem ser as mesmas pessoas, mas à medida que a empresa cresce, essas funções tendem a se tornar mais pronunciadas e até divididas em subfunções... (Há muito a ser dito aqui sobre a natureza mutável do devops, o impacto organizacional dos microsserviços, etc.) N. Mas, por enquanto, vamos considerar essas descrições como certas).
Deste ponto de vista, os beneficiários claros da malha de serviço são os proprietários da plataforma. Afinal, o objetivo final da equipe da plataforma é criar uma plataforma interna na qual os proprietários de serviços possam implementar a lógica de negócios e fazê-lo de uma forma que lhes garanta a máxima independência dos detalhes sombrios de sua operação. A malha de serviço não apenas oferece os recursos essenciais para atingir esse objetivo, mas também o faz de uma forma que, por sua vez, não impõe dependências aos proprietários do serviço.
Os proprietários de serviços também beneficiam, embora de forma mais indireta. O objetivo do proprietário do serviço é ser o mais produtivo possível na implementação da lógica do processo de negócio, e quanto menos ele tiver que se preocupar com questões operacionais, melhor. Em vez de impor, por exemplo, políticas de nova tentativa ou TLS, eles podem se concentrar apenas nos negócios e esperar que a plataforma cuide do resto. Para eles, esta é uma grande vantagem.
O valor organizacional de tal divisão entre os proprietários de plataformas e serviços não pode ser subestimado. acho que ela contribui primário contribuição para o valor da malha de serviços.
Aprendemos essa lição quando um dos primeiros fãs do Linkerd nos contou por que escolheu a malha de serviço: porque ela lhes permitia “continuar conversando no mínimo”. Aqui estão alguns detalhes: caras de uma grande empresa migraram sua plataforma para o Kubernetes. Como o aplicativo trabalhava com informações confidenciais, eles queriam criptografar todas as comunicações nos clusters. No entanto, a situação foi complicada pela presença de centenas de serviços e centenas de equipas de desenvolvimento. A perspectiva de contactar todos e convencê-los a incluir o apoio ao TLS nos seus planos não os agradou em nada. Ao instalar o Linkerd, eles migraram responsabilidade desde desenvolvedores (de cujo ponto de vista era um problema desnecessário) até criadores de plataformas, para quem esta era uma prioridade de nível superior. Em outras palavras, Linkerd estava resolvendo para eles não tanto um problema técnico, mas sim organizacional.
Em suma, a malha de serviço não é, antes, uma solução técnica, mas sócio técnico problemas (Obrigado pela introdução deste termo.
A malha de serviço resolverá todos os meus problemas?
Sim. Eu quero dizer não!
Observando as três classes de recursos descritas acima – confiabilidade, segurança e observabilidade – fica claro que a malha de serviço não é uma solução completa para nenhum desses problemas. Embora o Linkerd possa enviar solicitações repetidas (se souber que são idempotentes), ele não está em condições de tomar decisões sobre o que retornar ao usuário se o serviço finalmente cair - tais decisões devem ser tomadas pela aplicação. O Linkerd pode manter estatísticas sobre solicitações bem-sucedidas, mas não é capaz de analisar o serviço e fornecer suas métricas internas - um aplicativo deve ter esse kit de ferramentas. E embora o Linkerd seja capaz de hospedar mTLS, soluções de segurança completas exigem muito mais.
Um subconjunto dos recursos nessas áreas oferecidos pela malha de serviço está relacionado a recursos da plataforma. Com isso quero dizer funções que:
- Independente da lógica de negócios. A forma como os histogramas de chamadas são construídos entre Foo e Bar é completamente independente de por que Foo liga para Bar.
- Difícil de implementar corretamente. No Linkerd, as novas tentativas são parametrizadas com todos os tipos de coisas sofisticadas, como orçamentos de novas tentativas. (tentar novamente os orçamentos), uma vez que uma abordagem simplória para a implementação de tais coisas certamente levará ao surgimento da chamada "avalanche de pedidos" (tentar novamente tempestade) e outros problemas específicos de sistemas distribuídos.
- Mais eficaz quando aplicado de forma consistente. O mecanismo TLS só faz sentido se for aplicado em todos os lugares.
Como esses recursos são implementados na camada proxy (e não na camada de aplicação), a malha de serviço os expõe na camada proxy. Plataforma, não aplicativos. Assim, não importa em que língua os serviços estão escritos, que estrutura utilizam, quem os escreveu e porquê. Os proxies funcionam além de todos esses detalhes, e a base fundamental desta funcionalidade, incluindo as tarefas de configuração, atualização, operação, manutenção, etc., reside exclusivamente no nível da plataforma.
Exemplos de recursos de malha de serviço
Em resumo, uma malha de serviço não é uma solução completa em termos de confiabilidade, observabilidade ou segurança. A abrangência destas áreas implica a participação obrigatória dos proprietários dos serviços, das equipas de Ops/SRE e de outros stakeholders da empresa. A malha de serviço fornece apenas uma “fatia” no nível da plataforma para cada uma dessas áreas.
Por que a malha de serviço se tornou popular agora?
Você provavelmente está se perguntando agora: OK, se a malha de serviço é tão boa, por que não começamos a implantar milhões de proxies na pilha há dez anos?
Há uma resposta banal para essa pergunta: há dez anos todo mundo construía monólitos e ninguém precisava de uma malha de serviço. Isso é verdade, mas, na minha opinião, essa resposta não entende o objetivo. Ainda há dez anos, o conceito de microsserviços como uma forma promissora de criar sistemas em grande escala era amplamente discutido e aplicado em empresas como Twitter, Facebook, Google e Netflix. A percepção geral – pelo menos nas partes da indústria com as quais estive em contato – era que os microsserviços são o “caminho certo” para construir grandes sistemas, mesmo que fosse muito difícil.
É claro que, embora houvesse empresas explorando microsserviços há dez anos, elas não colocavam proxies em todos os lugares que podiam para formar uma malha de serviços. No entanto, se você olhar de perto, eles fizeram algo semelhante: muitas dessas empresas exigiram o uso de uma biblioteca interna especial para redes (às vezes chamada de biblioteca fat client, biblioteca de cliente gorda).
A Netflix tinha o Hysterix, o Google tinha o Stubby, o Twitter tinha a biblioteca Finagle. O Finagle, por exemplo, tornou-se obrigatório para todos os novos serviços do Twitter. Ele cuidava do lado do cliente e do servidor das conexões, permitia solicitações repetidas, suportava roteamento de solicitações, balanceamento de carga e medição. Ele forneceu uma camada consistente de confiabilidade e observabilidade em toda a pilha do Twitter, independentemente do que o serviço estivesse fazendo. Claro, só funcionava para linguagens JVM e era baseado em um modelo de programação que deveria ser usado para toda a aplicação. No entanto, sua funcionalidade era quase a mesma do service mesh. (Na verdade, a primeira versão do Linkerd era apenas Finagle embrulhado em formato de proxy.)
Assim, há dez anos não existiam apenas microsserviços, mas também bibliotecas especiais de proto-service-mesh que resolviam os mesmos problemas que a service mesh resolve hoje. No entanto, a malha de serviço em si não existia naquela época. Tinha que haver outra mudança antes que ela aparecesse.
E é aqui que reside a resposta mais profunda, escondida noutra mudança que ocorreu nos últimos 10 anos: houve um declínio acentuado no custo de implementação de microsserviços. As empresas mencionadas acima que usavam microsserviços há uma década – Twitter, Netflix, Facebook, Google – eram empresas de enorme escala e com enormes recursos. Eles não apenas tinham a necessidade, mas também a capacidade de criar, implantar e operar grandes aplicações baseadas em microsserviços. A energia e o esforço que os engenheiros do Twitter investiram na mudança de uma abordagem monolítica para uma abordagem de microsserviços são incríveis. (Honestamente, assim como o fato de ter funcionado.) Este tipo de manobra de infra-estrutura era então impossível para as empresas mais pequenas.
Vamos para o presente. Hoje existem startups onde a proporção de microsserviços para desenvolvedores é de 5:1 (ou mesmo ) e, além disso, eles lidam com eles com sucesso! Se uma startup de 5 pessoas é capaz de operar 50 microsserviços sem esforço, então algo reduziu claramente o custo de sua implementação.
1500 microsserviços em Monzo; cada linha é uma regra de rede prescrita que permite o tráfego
A redução dramática no custo operacional de microsserviços é o resultado de um único processo: crescente popularidade dos contêineres и orquestradores. Esta é precisamente a resposta profunda à questão do que contribuiu para o surgimento da malha de serviços. A mesma tecnologia tornou atrativos tanto a malha de serviço quanto os microsserviços: Kubernetes e Docker.
Por que? Bem, o Docker resolve um grande problema - o problema da embalagem. Ao empacotar um aplicativo e suas dependências de tempo de execução (não relacionadas à rede) em um contêiner, o Docker transforma o aplicativo em uma unidade fungível que pode ser hospedada e executada em qualquer lugar. Ao mesmo tempo, simplifica bastante a operação. multilíngue pilha: como um contêiner é uma unidade atômica de execução, não importa o que está dentro, seja um aplicativo JVM, Node, Go, Python ou Ruby, para fins operacionais e de implantação. Você apenas executa e pronto.
O Kubernetes leva tudo para o próximo nível. Agora que há um monte de "coisas executáveis" e muitas máquinas para executá-las, há necessidade de uma ferramenta que possa combiná-las umas com as outras. Em um sentido amplo, você dá ao Kubernetes muitos contêineres e muitas máquinas, e ele os combina (é claro, este é um processo dinâmico e em constante mudança: novos contêineres se movem pelo sistema, máquinas iniciam e param, etc. No entanto, O Kubernetes leva tudo isso em consideração).
Depois que o Kubernetes estiver configurado, o tempo necessário para implantar e operar um serviço não será muito diferente do custo para implantar e operar dez serviços (na verdade, é quase o mesmo para 100 serviços). Adicione a isso os contêineres como um mecanismo de empacotamento que incentiva a implementação multilíngue e você terá uma tonelada de novos aplicativos implementados como microsserviços escritos em vários idiomas, exatamente o tipo de ambiente para o qual a malha de serviço é tão adequada.
Assim, chegamos à resposta à questão de por que a ideia de uma service mesh se tornou popular agora: a uniformidade que o Kubernetes fornece para serviços é diretamente aplicável às tarefas operacionais enfrentadas pela service mesh. Você empacota proxies em contêineres, dá ao Kubernetes a tarefa de colá-los sempre que possível e pronto! Como resultado, você obtém uma malha de serviço, enquanto o Kubernetes controla toda a mecânica de sua implantação. (Pelo menos do ponto de vista de um pássaro. É claro que há muitas nuances nesse processo.)
Resumindo: a razão pela qual a malha de serviço se tornou popular agora e não há dez anos é que o Kubernetes e o Docker não apenas aumentaram significativamente necessidade nele, simplificando a implementação de aplicativos como conjuntos de microsserviços multilíngues, mas também reduzindo significativamente custos para sua operação, fornecendo mecanismos para implantação e manutenção de parques proxy sidecar.
Por que se fala tanto em service mesh?
aviso: Nesta seção, recorro a todos os tipos de suposições, conjecturas, invenções e informações privilegiadas.
A busca por “malha de serviço” resultará em um monte de conteúdo reciclado e de baixa caloria, projetos estranhos e um caleidoscópio de distorção digno de uma câmara de eco. Qualquer nova tecnologia moderna tem isso, mas no caso da malha de serviço, o problema é especialmente grave. Por que?
Bem, em parte é minha culpa. Tenho feito o meu melhor para promover o Linkerd e o service mesh em todas as oportunidades, através de inúmeras postagens de blog e artigos como este. Mas eu não sou tão poderoso. Para realmente responder a esta pergunta, precisamos falar um pouco sobre a situação geral. E é impossível falar sobre isso sem citar um projeto: é uma malha de serviço de código aberto desenvolvida em conjunto pelo Google, IBM e Lyft.
(Essas três empresas têm funções muito diferentes: o envolvimento da Lyft parece estar limitado apenas ao nome; elas são autoras do Envoy, mas não usam ou estão envolvidas no desenvolvimento do Istio. A IBM está envolvida no desenvolvimento do Istio e o utiliza. O Google é fortemente envolvido no desenvolvimento do Istio , mas até onde sei, na verdade não o utiliza.)
O projeto Istio é notável por duas coisas. Em primeiro lugar, é o enorme esforço de marketing que o Google, em particular, coloca na sua promoção. Estimo que a maioria das pessoas que atualmente conhecem o conceito de service mesh aprenderam sobre ele graças ao Istio. A segunda característica é o quão mal o Istio foi recebido. Neste assunto, obviamente, sou parte interessada, mas tentando ser o mais objetivo possível, ainda não posso deixar de , não muito específico (embora não seja único: o systemd vem à mente, ...) para um projeto Open Source.
(Na prática, o Istio parece ter problemas não apenas com complexidade e UX, mas também com desempenho. Por exemplo, durante conduzido por terceiros, os especialistas encontraram situações em que a latência de cauda do Istio era 100 vezes maior que a do Linkerd, bem como situações de falta de recursos, quando o Linkerd continuou a funcionar com sucesso e o Istio parou completamente de funcionar.)
Deixando de lado minhas teorias sobre por que isso aconteceu, acredito que o hype fora de escala em torno da malha de serviço se deve ao envolvimento do Google. Ou seja, uma combinação dos três fatores a seguir:
- promoção obsessiva do Istio pelo Google;
- atitude apropriada de desaprovação e crítica em relação ao projeto;
- a recente popularidade crescente do Kubernetes, cuja memória ainda está fresca.
Juntos, estes factores fundem-se numa espécie de ambiente inebriante e anóxico, no qual a capacidade de julgamento racional é enfraquecida e apenas resta uma variedade maravilhosa. .
Do ponto de vista de Linkerd, isso é... eu descreveria como uma bênção duvidosa. Quer dizer, é ótimo que o service mesh tenha entrado no mainstream - o que não foi o caso em 2016, quando o Linkerd apareceu pela primeira vez e foi realmente difícil chamar a atenção das pessoas para o projeto. Agora não existe esse problema! Mas a má notícia é que a situação da malha de serviço é tão confusa hoje que é quase impossível descobrir quais projetos realmente pertencem à categoria da malha de serviço (e muito menos descobrir qual é o melhor para um caso de uso específico). Isso certamente atrapalha a todos (e definitivamente em alguns casos o Istio ou outro projeto é melhor que o Linkerd, já que este último não é uma solução única para todos).
Do lado de Linkerd, nossa estratégia tem sido ignorar o barulho, continuar focando na solução dos problemas reais da comunidade e, essencialmente, esperar que o entusiasmo diminua. Eventualmente, o entusiasmo diminuirá e poderemos continuar a trabalhar em paz.
Até lá, todos teremos que ser pacientes.
A malha de serviço será útil para mim, um modesto engenheiro de software?
O seguinte questionário ajudará a responder a esta pergunta:
Você lida exclusivamente com a implementação da lógica de negócios? Nesse caso, a malha de serviço não será útil para você. É claro que você pode estar interessado nisso, mas o ideal é que a malha de serviço não afete diretamente nada em seu ambiente. Continue trabalhando naquilo pelo que você é pago.
Você mantém uma plataforma em uma empresa que utiliza Kubernetes? Sim, neste caso você precisa de uma malha de serviço (é claro, se você não estiver usando K8s apenas para executar um processamento monolítico ou em lote - mas então eu gostaria de perguntar por que você precisa de K8s). Muito provavelmente, você se encontrará em uma situação com muitos microsserviços escritos por pessoas diferentes. Todos eles interagem entre si e estão ligados a um emaranhado de dependências de tempo de execução, e você precisa encontrar uma maneira de lidar com tudo isso. O uso do Kubernetes permite que você escolha uma malha de serviço “para você”. Para fazer isso, familiarize-se com suas capacidades e características e responda se algum dos projetos disponíveis é adequado para você (recomendo começar sua pesquisa com Linkerd).
Você está administrando uma plataforma para uma empresa que NÃO usa Kubernetes, mas usa microsserviços? Nesse caso, a malha de serviço será útil para você, mas seu uso não será trivial. Claro que você pode imitar service mesh hospedando vários proxies, mas uma vantagem importante do Kubernetes é justamente o modelo de implantação: a manutenção manual desses proxies exigirá muito mais tempo, esforço e custo.
Você é responsável pela plataforma em uma empresa que trabalha com monólitos? Nesse caso, você provavelmente não precisa de uma malha de serviço. Se você estiver trabalhando com monólitos (ou mesmo conjuntos de monólitos) que possuem padrões de interação bem definidos e que raramente mudam, então a malha de serviço tem pouco a oferecer. Então você pode simplesmente ignorá-lo e esperar que desapareça como um pesadelo...
Conclusão
Provavelmente, a malha de serviço ainda não deveria ser chamada de “a tecnologia mais badalada do mundo” - essa honra duvidosa provavelmente pertence ao bitcoin ou à IA. Talvez ela esteja entre os cinco primeiros. Mas se você romper as camadas de ruído e barulho, fica claro que a malha de serviço traz benefícios reais para quem cria aplicações no Kubernetes.
Gostaria que você experimentasse o Linkerd - instalando-o em um cluster Kubernetes (ou até mesmo Minikube em um laptop) e você pode ver por si mesmo do que estou falando.
Perguntas frequentes
- Se eu ignorar a malha de serviço, ela desaparecerá?
- Devo decepcioná-lo: a malha de atendimento está conosco há muito tempo.
— Mas NÃO QUERO usar service mesh!
- Bem, não é necessário! Basta ler meu questionário acima para ver se você deveria pelo menos se familiarizar com o básico.
— Não é o bom e velho ESB/middleware com um molho novo?
- A malha de serviço trata da lógica operacional, não da semântica. barramento de serviço corporativo (). Manter essa separação ajuda a malha de serviço a evitar o mesmo destino.
- Qual a diferença entre uma malha de serviço e gateways de API?
Há um milhão de artigos sobre esse assunto. Basta pesquisar no Google.
O Envoy é uma malha de serviço?
- Não, o Envoy não é um service mesh, é um servidor proxy. Ele pode ser usado para organizar uma malha de serviço (e muito mais – é um proxy de uso geral). Mas por si só não é uma malha de serviços.
- Network Service Mesh - é uma malha de serviço?
- Não. Apesar do nome, esta não é uma malha de serviços (você gosta das maravilhas do marketing?).
- A malha de serviço ajudará no meu sistema assíncrono reativo baseado em fila de mensagens?
- Não, a malha de serviço não vai te ajudar.
- Qual malha de serviço devo usar?
- , acéfalo.
- O artigo é uma merda! / O autor - na novela!
— Por favor, compartilhe o link com todos os seus amigos para que eles possam se convencer disso!
Agradecimentos
Como você pode imaginar pelo título, este artigo foi inspirado no fantástico tratado de Jay Kreps "". Conheci Jay há dez anos, durante uma entrevista no Linked In, e ele tem sido uma inspiração para mim desde então.
Embora eu goste de me chamar de "desenvolvedor Linkerd", a realidade é que sou mais um mantenedor do arquivo README.md em um projeto. Trabalhando no Linkerd hoje , , pessoas, e este projeto não teria sido possível sem a incrível comunidade de colaboradores e usuários.
E por fim, um agradecimento especial ao criador do Linkerd, (primus inter pares), que, junto comigo há muitos anos, mergulhou de cabeça nessa confusão toda com a malha de serviço.
PS do tradutor
Leia também em nosso blog:
- «";
- «";
- «";
- «";
- «".
Fonte: habr.com