Nota. transl.: A malla de servizo é un fenómeno que aínda non ten unha tradución estable ao ruso (hai máis de 2 anos ofrecíamos a opción "malla para servizos", e un pouco máis tarde, algúns compañeiros comezaron a promover activamente a combinación "peneira de servizo"). . Falar constantemente sobre esta tecnoloxía levou a unha situación na que os compoñentes técnicos e de marketing están demasiado entrelazados. Este marabilloso material dun dos autores do termo orixinal pretende aportar claridade aos enxeñeiros e non só.
Cómic de
Introdución
Se es un enxeñeiro de software que traballa nalgún lugar da área dos sistemas backend, o termo "malla de servizo" probablemente xa se afiance na túa mente nos últimos dous anos. Grazas a unha estraña coincidencia, esta frase está a apoderarse da industria cada vez máis, e o bombo e as ofertas promocionais relacionadas crecen como unha bola de neve, voando costa abaixo e non mostran sinais de desaceleración.
A malla de servizo naceu nas turbias e tendenciosas augas do ecosistema nativo da nube. Desafortunadamente, isto significa que gran parte da polémica que o rodea abarca desde "charlas baixas en calorías" ata, para usar o termo técnico, unha merda flagrante. Pero se filtras todo o ruído, podes descubrir que a malla de servizo ten unha función moi real, definida e importante.
Nesta publicación, tentarei facer exactamente iso: proporcionar unha guía honesta, profunda e centrada nos enxeñeiros sobre a rede de servizo. Non vou responder só á pregunta: "Que é?", - pero tamén "Por que?"E "Por que agora?". Finalmente, tentarei esbozar por que (na miña opinión) esta tecnoloxía en particular causou un bombo tan tolo, que en si é unha historia interesante.
Кто я?
Ola a todos! O meu nome é . Eu son un dos creadores - o primeiro proxecto de malla de servizo e o proxecto culpable da aparición do termo malla de servizo como tal (perdón rapaces!). (Nota transl.: Por certo, nos albores da aparición deste termo, hai máis de 2,5 anos, xa traducíamos o material temperán do mesmo autor chamado "".) Eu tamén dirixo é unha startup que constrúe cousas interesantes de malla de servizos como Linkerd e .
Probablemente poidas adiviñar que teño unha opinión moi tendenciosa e subxectiva sobre esta cuestión. Non obstante, tentarei manter o sesgo ao mínimo (a excepción dunha sección: "Por que se fala tanto da rede de servizo?", - no que, non obstante, compartirei as miñas ideas preconcibidas). Tamén farei todo o posible para que esta guía sexa o máis obxectiva posible. En exemplos específicos, confiareime principalmente na experiencia de Linkerd, mentres sinalarei as diferenzas (se as hai) que coñezo na implementación doutros tipos de malla de servizo.
Vale, é hora de pasar ás golosinas.
Que é unha malla de servizo?
A pesar de todo o bombo, a malla de servizo é estruturalmente bastante sinxela. É só unha morea de proxies de espazo de usuario situados "a carón" dos servizos (falaremos un pouco de "preto" máis adiante), ademais dun conxunto de procesos de control. Os proxies chámanse colectivamente plano de datos, e os procesos de control chámanse plano de control. O plano de datos intercepta chamadas entre servizos e fai "calquera cousa diferente" con elas; O plano de control, en consecuencia, coordina o comportamento do proxy e proporciona acceso para ti, é dicir. operador, á API, permitindo manipular e medir a rede no seu conxunto.
Que tipo de proxy é este? Este é un proxy TCP compatible coa capa 7 (é dicir, "tendo en conta" a capa 7 do modelo OSI) como HAProxy e NGINX. Podes escoller un proxy ao teu gusto; Linkerd usa un proxy Rust, nomeado sen complicacións . Compilámolo especificamente para a malla de servizo. Outras mallas prefiren outros proxies (Envoy é unha opción común). Non obstante, escoller un proxy é só unha cuestión de implementación.
Que fan estes servidores proxy? Obviamente, proxy chamadas a e dende servizos (en rigor, actúan como proxies e proxies inversos, xestionando chamadas entrantes e saíntes). E implementan un conxunto de funcións que se centran nas chamadas entre Servizos. Este foco no tráfico entre servizos é o que distingue un proxy de malla de servizos de, por exemplo, pasarelas de API ou proxies de entrada (estes últimos céntranse nas chamadas que chegan ao clúster desde o mundo exterior). (Nota. transl.: Para unha comparación dos controladores Kubernetes Ingress existentes, moitos dos cales usan o xa mencionado Envoy, consulte .)
Entón, descubrimos o plano de datos. O plano de control é máis sinxelo: é un conxunto de compoñentes que proporcionan toda a mecánica que precisa o plano de datos para traballar de forma coordinada, incluíndo o descubrimento de servizos, a emisión de certificados TLS, a agregación de métricas, etc. O plano de datos informa ao plano de control sobre o seu comportamento; á súa vez, o plano de control proporciona unha API que lle permite cambiar e rastrexar o comportamento do plano de datos no seu conxunto.
A continuación móstrase un diagrama do plano de control e do plano de datos en Linkerd. Como podes ver, o plano de control inclúe varios compoñentes diferentes, incluíndo unha instancia de Prometheus que recolle métricas de servidores proxy, así como outros compoñentes como destination (descubrimento de servizos), identity (Autoridade de certificación, CA) e public-api (puntos finais para web e CLI). Pola contra, o plano de datos é un simple proxy linkerd xunto á instancia da aplicación. Este é só un diagrama lóxico; Nunha implantación no mundo real, pode ter tres réplicas de cada compoñente do plano de control e centos ou miles de proxies no plano de datos.
(Os rectángulos azuis deste diagrama simbolizan os límites dos pods de Kubernetes. Podes ver que os contedores con linkerd-proxy están no mesmo pod que os contedores da aplicación. Este esquema coñécese como contenedor sidecar.)
A arquitectura de malla de servizo ten varias implicacións importantes. En primeiro lugar, dado que a tarefa dun proxy é interceptar chamadas entre servizos, unha malla de servizos só ten sentido se a súa aplicación foi creada para un determinado conxunto de servizos. Malla unha lata úsase con monólitos, pero isto é claramente redundante por mor dun único proxy, e é improbable que a súa funcionalidade sexa demandada.
Outra consecuencia importante é que a rede de servizo require enorme número de apoderados. De feito, Linkerd encadea un proxy linkerd a cada instancia de cada servizo (outras implementacións engaden un proxy a cada nodo/host/VM. De todos os xeitos é moito). Un uso tan activo dun proxy en si mesmo conleva unha serie de complicacións adicionais:
- Os proxies no plano de datos deberían ser rápido, xa que para cada chamada hai un par de chamadas ao proxy: unha no lado do cliente, outra no lado do servidor.
- Ademais, os proxies deben ser pequena и lixeiro. Cada un consumirá memoria e recursos da CPU, e este consumo crecerá linealmente coa aplicación.
- Necesitará un mecanismo para implementar e actualizar un gran número de proxies. Facelo manualmente non é unha opción.
En xeral, a malla de servizo ten este aspecto (polo menos desde a vista de paxaro): despregas unha morea de proxies de espazo de usuario que "facen algo" co tráfico interno e entre servizos e usa o plano de control para supervisalos e xestionalos.
Chegou o momento da pregunta "Por que?"
Para que serve unha malla de servizo?
Os que atoparon por primeira vez a idea dunha malla de servizo poderían ser perdoados por sentirse un pouco inquietos. O deseño da malla de servizo significa que non só aumentará a latencia na aplicación, senón que tamén o fará consumir recursos e engadirá unha morea de novos mecanismos na infraestrutura. Primeiro configuras unha malla de servizo e, de súpeto, tes que dar servizo a centos (se non miles) de proxies. A pregunta é, quen fará isto voluntariamente?
A resposta a esta pregunta ten dúas partes. En primeiro lugar, os custos de transacción asociados á implantación destes proxies pódense reducir significativamente grazas a algúns cambios que se producen no ecosistema (máis sobre isto máis adiante).
En segundo lugar, tal dispositivo é realmente unha boa forma de introducir lóxica adicional no sistema. E non só porque se poden engadir moitas funcións novas usando a malla de servizo, senón tamén porque se pode facer sen interferir co ecosistema. De feito, todo o modelo de malla de servizos baséase neste postulado: nun sistema multiservizo, pase o que pase facer servizos individuais, tráfico entre eles é o punto ideal para engadir funcionalidade.
Por exemplo, en Linkerd (como na maioría das mallas) a funcionalidade céntrase principalmente nas chamadas HTTP, incluíndo HTTP/2 e gRPC*. A funcionalidade é bastante rica: pódese dividir en tres clases:
- Características relacionadas fiabilidade. Solicitudes de reintento, tempo de espera, enfoque canario (división/redirección de tráfico), etc.
- Características relacionadas vixilancia. Agregación de taxas de éxito, atrasos e volumes de solicitudes para cada servizo ou direccións individuais; construción de mapas topolóxicos de servizos, etc.
- Características relacionadas seguridade. TLS mutuo, control de acceso, etc.
* Desde o punto de vista de Linkerd, gRPC non é practicamente diferente de HTTP/2: só usa protobuf na carga útil. Desde o punto de vista dun desenvolvedor, as dúas cousas son, por suposto, diferentes.
Moitos destes mecanismos operan a nivel de solicitude (de aí o "proxy L7"). Por exemplo, se o servizo Foo fai unha chamada HTTP ao servizo Bar, o proxy linkerd do lado de Foo pode equilibrar a carga e dirixir de xeito intelixente as chamadas de instancias de Foo a Bar en función da latencia observada; pode repetir a solicitude se é necesario (e se é idempotente); pode gravar o código de resposta e o tempo de espera, etc. Do mesmo xeito, o linkerd-proxy do lado da barra pode rexeitar unha solicitude se non está permitida ou se se supera o límite de solicitudes; pode corrixir o atraso pola súa parte, etc.
Os proxies tamén poden "facer algo" a nivel de conexión. Por exemplo, linkerd-proxy do lado Foo pode iniciar unha conexión TLS, e linkerd-proxy do lado de Bar pode finalizala, e ambos os dous lados poden verificar mutuamente os certificados TLS*. Isto proporciona non só cifrado entre servizos, senón tamén un xeito criptograficamente seguro de identificar os servizos: Foo e Bar poden "probar" que son quen din ser.
* "Mutualidade dun amigo" significa que tamén se verifica o certificado do cliente (TLS mutuo). No TLS "clásico", por exemplo entre un navegador e un servidor, adoita verificarse o certificado dun só lado (o servidor).
Independentemente de se operan a nivel de solicitude ou de conexión, é importante subliñar que todas as funcións da malla de servizo son operativo personaxe. Linkerd non pode transformar a semántica da carga útil, como engadir campos a un fragmento JSON ou facer cambios nun protobuf. Desta característica importante falaremos máis adiante cando falemos de ESB e middleware.
Este é o conxunto de funcións que ofrece a malla de servizos. Xorde a pregunta: por que non implementalas directamente na aplicación? E por que meterse cun proxy?
Por que a malla de servizo é unha boa idea
Aínda que as capacidades da malla de servizo son cativadoras, o seu principal valor non reside realmente nas funcións. Ao final nós Pode implementalos directamente na aplicación (máis tarde veremos que esta foi a orixe da malla de servizo). Para poñelo nunha frase, o valor dunha malla de servizo é: ofrece unha funcionalidade crítica para executar o software de servidor moderno de forma consistente, en toda a pila e independente do código da aplicación..
Analizemos esta proposta.
«Funcións críticas para executar o software de servidor moderno" Se está a crear unha aplicación de servidor transaccional que está conectada á Internet pública, acepta solicitudes do mundo exterior e responde a elas nun curto período de tempo, por exemplo, unha aplicación web, un servidor API e a gran maioría doutras aplicacións modernas. - e se o implementa como un conxunto de servizos que interactúan de forma sincrónica entre si, e se está a actualizar constantemente este software, engadindo novas funcións e se ve obrigado a manter este sistema en condicións de funcionamento durante o proceso de modificación, neste caso, parabéns, estás creando un software de servidor moderno. E todas estas excelentes funcións enumeradas anteriormente resultan ser críticas para ti. A aplicación debe ser fiable, segura e debes poder observar o que está a facer. Estas son exactamente as preguntas que a malla de servizo axuda a resolver.
(Está ben, a miña convicción de que este enfoque é a forma moderna de construír software de servidor entrou no parágrafo anterior. Outros prefiren desenvolver monólitos, "microservizos reactivos" e outras cousas que non entran na definición dada anteriormente. Estas persoas probablemente teñan opinión que difire da miña e, á súa vez, creo que están "equivocados" -aínda que, en todo caso, a malla de servizo non lles é moi útil).
«Uniforme para toda a pila" A funcionalidade proporcionada por unha malla de servizo non só é fundamental para a misión. Aplícanse a todos os servizos dunha aplicación, independentemente do idioma en que estean escritos, que marco utilicen, quen os escribiu, como se implementaron e todas as outras sutilezas do seu desenvolvemento e uso.
«Independente do código da aplicación". Finalmente, a malla de servizo non só ofrece unha funcionalidade consistente en toda a pila, senón que o fai dun xeito que non require editar a aplicación. A base fundamental da funcionalidade dunha malla de servizo, incluíndo as tarefas de configuración, actualización, funcionamento, mantemento, etc., é puramente a nivel de plataforma e é independente da aplicación. A aplicación pode cambiar sen afectar a malla de servizo. Pola súa banda, a malla de servizo pode cambiar sen ningunha intervención da aplicación.
En resumo, unha malla de servizo non só proporciona unha funcionalidade vital, senón que tamén o fai de forma global, uniforme e independente da aplicación. E así, aínda que a funcionalidade da malla de servizo pode implementarse no código de servizo (por exemplo, como unha biblioteca incluída con cada servizo), este enfoque non proporcionará a uniformidade e independencia que son tan valiosas no caso dunha malla de servizo.
E todo o que tes que facer é engadir unha morea de proxies. Prometo que veremos os custos operativos asociados coa adición destes proxies moi pronto. Pero primeiro detémonos a ver esta idea de independencia desde diferentes perspectivas. persoas.
A quen axuda a malla de servizo?
Por inconveniente que poida resultar, para que unha tecnoloxía se converta nunha parte importante do ecosistema, debe ser aceptada pola xente. Entón, quen está interesado nunha malla de servizo? Quen se beneficia do seu uso?
Se desenvolves un software de servidor moderno, podes imaxinar aproximadamente o teu equipo como grupo propietarios de servizosque xuntos desenvolven e implementan a lóxica empresarial, e propietarios da plataformaimplicados no desenvolvemento da plataforma interna na que funcionan estes servizos. Nas organizacións pequenas, estas poden ser as mesmas persoas, pero a medida que a empresa crece, estes roles tenden a facerse máis pronunciados e mesmo a dividirse en subroles... (Hai moito que dicir aquí sobre a natureza cambiante dos devops, o impacto organizativo dos microservizos, etc.) n. Pero de momento tomemos estas descricións como dadas).
Desde este punto de vista, os claros beneficiarios da malla de servizo son os propietarios da plataforma. Despois de todo, en última instancia, o obxectivo do equipo da plataforma é crear unha plataforma interna na que os propietarios dos servizos poidan implementar a lóxica empresarial e facelo de forma que se asegure de que sexan o máis independentes posible dos turbios detalles do seu funcionamento. Unha malla de servizos non só ofrece capacidades fundamentais para acadar este obxectivo, senón que o fai dunha forma que á súa vez non impón dependencias aos propietarios do servizo.
Os propietarios dos servizos tamén se benefician, aínda que dun xeito máis indirecto. O obxectivo do propietario do servizo é ser o máis produtivo posible na implementación da lóxica do proceso empresarial, e canto menos teña que preocuparse polos problemas operativos, mellor. En lugar de ter que xestionar a implementación, por exemplo, de políticas de reintento ou TLS, poden centrarse unicamente en obxectivos comerciais e esperar que a plataforma se encargue do resto. Esta é unha gran vantaxe para eles.
Non se pode sobreestimar o valor organizativo desta división entre os propietarios de plataformas e servizos. Creo que ela contribúe o principal contribución ao valor da rede de servizo.
Aprendemos esta lección cando un dos primeiros fans de Linkerd díxonos por que elixiron a malla de servizo: porque lles permitía "manter a tenda que fala ao mínimo". Aquí tes algúns detalles: os mozos dunha gran empresa migraron a súa plataforma a Kubernetes. Dado que a aplicación manexaba información confidencial, querían cifrar todas as comunicacións entre os clústeres. Porén, a situación complicouse pola presenza de centos de servizos e centos de equipos de desenvolvemento. A perspectiva de poñerse en contacto con todos e convencelos de incluír soporte TLS nos seus plans non os fixo nada felices. Despois de instalar Linkerd, transferíronse responsabilidade desde desenvolvedores (desde o punto de vista do cal isto era un problema innecesario) ata plataformas, para os que esta era unha prioridade de primeiro nivel. Noutras palabras, Linkerd resolveu para eles non tanto un problema técnico como organizativo.
En resumo, a malla de servizo non é, máis ben, unha solución técnica, senón socio-técnico Problemas. (Grazas por introducir este termo).
Unha malla de servizo resolverá todos os meus problemas?
Si. Quero dicir, non!
Se observas as tres clases de funcións descritas anteriormente (fiabilidade, seguridade e observabilidade), queda claro que unha malla de servizo non é unha solución completa para ningún destes problemas. Aínda que Linkerd pode reemitir solicitudes (se sabe que son idempotentes), non pode tomar decisións sobre que devolver ao usuario se o servizo fallou permanentemente; esas decisións deben ser tomadas pola aplicación. Linkerd pode manter estatísticas de solicitudes exitosas, pero non é capaz de analizar o servizo e proporcionar as súas métricas internas; a aplicación debe ter tales ferramentas. E aínda que Linkerd é capaz de organizar mTLS, as solucións de seguridade completas requiren moito máis.
Un subconxunto das funcións destas áreas que ofrece a malla de servizo están relacionadas características da plataforma. Con isto quero dicir funcións que:
- Independente da lóxica empresarial. A forma en que se constrúen os histogramas de chamadas entre Foo e Bar é completamente independente por que Foo chama a Bar.
- Difícil de implementar correctamente. En Linkerd, os reintentos parametrizanse con todo tipo de cousas extravagantes, como orzamentos de reintento. (reintentar os orzamentos), xa que un enfoque pouco sofisticado e frontal para implementar tales cousas levará sen dúbida á aparición dunha chamada "avalancha de solicitudes" (reintento tempestade) e outros problemas específicos dos sistemas distribuídos.
- Máis eficaz cando se aplica de forma consistente. O mecanismo TLS só ten sentido se se aplica en todas partes.
Dado que estas funcións se implementan na capa de proxy (e non na capa de aplicación), a malla de servizo expónas no plataformas, non aplicacións. Así, non importa en que lingua están escritos os servizos, que marco utilizan, quen os escribiu e por que. Os proxys operan fóra de todos estes detalles, e a base fundamental desta funcionalidade, incluídas as tarefas de configuración, actualización, operación, mantemento, etc., reside unicamente a nivel de plataforma.
Exemplos de capacidades de malla de servizo
En resumo, unha malla de servizo non é unha solución completa de fiabilidade, observabilidade ou seguridade. O alcance destas áreas implica a participación obrigatoria dos propietarios do servizo, os equipos de Operacións/SRE e outras partes interesadas da empresa. A malla de servizo só proporciona unha "porción" a nivel de plataforma para cada unha destas áreas.
Por que se popularizou a malla de servizo agora mesmo?
A estas alturas probablemente esteas a preguntar: ok, se a malla de servizo é tan boa, por que non comezamos a implementar millóns de proxies na pila hai dez anos?
Hai unha resposta banal a esta pregunta: hai dez anos todo o mundo construíu monolitos e ninguén necesitaba unha malla de servizo. Isto é certo, pero na miña opinión, esta resposta perde o sentido. Incluso hai dez anos, o concepto de microservizos como unha forma prometedora de construír sistemas a gran escala foi moi discutido e aplicado en empresas como Twitter, Facebook, Google e Netflix. A visión xeral, polo menos nas partes da industria coas que entrei en contacto, era que os microservizos eran a "forma correcta" de construír sistemas grandes, aínda que fose moi difícil.
Por suposto, aínda que hai dez anos había empresas que explotaban microservizos, non pegaron proxies en todas partes para formar unha malla de servizos. Non obstante, se miras detidamente, fixeron algo semellante: moitas destas empresas obrigaron ao uso dunha biblioteca interna especial para a creación de redes (ás veces chamada biblioteca do cliente gordo, biblioteca fat cliente).
Netflix tiña Hysterix, Google tiña Stubby, Twitter tiña a biblioteca Finagle. Finagle, por exemplo, era obrigatorio para cada novo servizo en Twitter. Manexaba tanto o lado do cliente como do servidor das conexións, permitía solicitudes repetidas, enrutamento de solicitudes compatible, equilibrio de carga e medición. Proporcionou unha capa consistente de fiabilidade e observabilidade en toda a pila de Twitter, independentemente do que fixera o servizo. Por suposto, só funcionaba para linguaxes JVM e estaba baseado nun modelo de programación que tiña que ser usado para toda a aplicación. Non obstante, a súa funcionalidade era case a mesma que a da malla de servizo. (De feito, a primeira versión de Linkerd foi simplemente Finagle envolto en forma de proxy).
Así, hai dez anos non só existían microservizos, senón tamén bibliotecas especiais de proto-servizos-malla que resolvían os mesmos problemas que a malla de servizos resolve hoxe. Non obstante, a malla de servizo en si non existía entón. Tivo que haber outro cambio antes de que ela aparecese.
E aquí é onde reside a resposta máis profunda, oculta noutro cambio que ocorreu nos últimos 10 anos: o custo de implantación de microservizos baixou drasticamente. As empresas mencionadas anteriormente que usaban microservizos hai dez anos —Twitter, Netflix, Facebook, Google— eran empresas de enorme escala e enormes recursos. Non só tiñan a necesidade, senón tamén a capacidade de construír, implantar e operar grandes aplicacións baseadas en microservizos. A enerxía e o esforzo que os enxeñeiros de Twitter puxeron para pasar dun enfoque monolítico a un enfoque de microservizos é incrible. (Sinceramente, como foi o feito de que funcionou). Este tipo de manobras de infraestrutura eran entón imposibles para as empresas máis pequenas.
Avance rápido ata o presente. Hoxe en día hai startups onde a proporción de microservizos a desenvolvedores é de 5:1 (ou incluso ), e ademais, enfróntanse a eles con éxito! Se unha startup de 5 persoas pode operar facilmente 50 microservizos, entón algo reduciu claramente o custo da súa implementación.
1500 microservizos en Monzo; cada liña é unha regra de rede prescrita que permite o tráfico
A redución dramática do custo de funcionamento dos microservizos é o resultado dun único proceso: crecente popularidade dos envases и orquestradores. Esta é precisamente a resposta profunda á pregunta de que contribuíu á aparición da rede de servizos. A mesma tecnoloxía fixo atractivos tanto a malla de servizos como os microservizos: Kubernetes e Docker.
Por que? Ben, Docker resolve un gran problema: o problema do envasado. Ao empaquetar unha aplicación e as súas dependencias de tempo de execución (que non sexan da rede) nun contedor, Docker converte a aplicación nunha unidade intercambiable que se pode aloxar e executar en calquera lugar. Ao mesmo tempo, simplifica moito o funcionamento multilingüe Pila: porque un contedor é unha unidade atómica de execución, para fins operativos e de implantación, non importa o que hai dentro, xa sexa unha aplicación JVM, Node, Go, Python ou Ruby. Simplemente lanzalo e xa está.
Kubernetes leva todo ao seguinte nivel. Agora que hai unha morea de "cousas executables" e moitas máquinas para executalas, é necesario unha ferramenta que poida combinalas entre si. Nun sentido amplo, dás a Kubernetes moitos contedores e moitas máquinas, e fai coincidir uns cos outros (por suposto, este é un proceso dinámico e en constante cambio: os novos contedores móvense polo sistema, as máquinas comezan e paran, etc. Non obstante, Kubernetes ten todo isto en conta).
Unha vez que Kubernetes está configurado, o tempo que leva implementar e operar un servizo non é moi diferente do custo de implementar e operar dez servizos (de feito, é case o mesmo para 100 servizos). Engade a isto os contedores como un mecanismo de empaquetado que fomenta a implementación multilingüe e terás unha tonelada de novas aplicacións implementadas como microservizos escritos en varios idiomas, o tipo de ambiente para o que a malla de servizos se adapta tan ben.
Entón, chegamos á resposta á pregunta de por que a idea dunha malla de servizos se popularizou agora: a homoxeneidade que ofrece Kubernetes para os servizos aplícase directamente aos desafíos operativos aos que se enfronta unha malla de servizos. Empaquetas os proxies en contedores, dás a Kubernetes a tarefa de pegalos onde poida e listo! Como resultado, obtén unha malla de servizo, mentres que todas as mecánicas da súa implantación son xestionadas por Kubernetes. (Polo menos desde a vista de paxaro. Por suposto, hai moitos matices neste proceso.)
En resumo: a razón pola que as mallas de servizo se fan populares agora, e non hai dez anos, é que Kubernetes e Docker non só aumentaron significativamente. necesidade nel, tendo simplificado a implantación de aplicacións como conxuntos de microservizos multilingües, pero tamén reducido significativamente custos para o seu funcionamento proporcionando mecanismos para o despregamento e mantemento de parques proxy sidecar.
Por que se fala tanto da rede de servizos?
Atención: Neste apartado, recorreo a todo tipo de suposicións, conxecturas, fabricacións e información privilexiada.
A busca de "malla de servizo" atopará un montón de contido reciclado e baixo en calorías, proxectos estraños e un caleidoscopio de distorsión digno dunha cámara de eco. Calquera tecnoloxía nova de moda ten isto, pero no caso da malla de servizo, o problema é especialmente agudo. Por que?
Ben, parte é culpa miña. Estiven traballando duro para promocionar Linkerd e a rede de servizos cada vez que teño oportunidade a través de innumerables publicacións de blog e artigos coma este. Pero non son tan poderoso. Para responder realmente a esta pregunta, temos que falar un pouco sobre a situación xeral. E é imposible falar diso sen mencionar un proxecto: é unha malla de servizos de código aberto desenvolvida conxuntamente por Google, IBM e Lyft.
(Esas tres empresas teñen papeis moi diferentes: a participación de Lyft parece limitarse só ao nome; son autoras de Envoy pero non usan nin están implicadas no desenvolvemento de Istio. IBM está implicada no desenvolvemento de Istio e utilízao. Google é moi importante. implicado no desenvolvemento de Istio , pero polo que podo dicir, en realidade non o usa.)
O proxecto Istio destaca por dúas cousas. En primeiro lugar, está o enorme esforzo de marketing que Google, en particular, está a facer para promocionalo. Estimaría que a maioría das persoas que coñecen hoxe o concepto de malla de servizo aprendeu por primeira vez sobre iso a través de Istio. O segundo é o mal recibido que foi Istio. Neste asunto, obviamente son unha parte interesada, pero intentando ser o máis obxectivo posible, aínda non podo evitar , non moi específico (aínda que non único: systemd vén á mente, ...) para un proxecto de código aberto.
(Na práctica, Istio parece ter problemas non só de complexidade e UX, senón tamén de rendemento. Por exemplo, durante realizados por un terceiro, os expertos atoparon situacións nas que a latencia de cola de Istio era 100 veces superior á de Linkerd, así como situacións con falta de recursos, cando Linkerd seguía funcionando con éxito e Istio deixou de funcionar por completo.)
Deixando de lado as miñas teorías sobre por que pasou isto, creo que a gran emoción arredor da rede de servizos explícase pola participación de Google. É dicir, unha combinación dos seguintes tres factores:
- promoción obsesiva de Istio por parte de Google;
- unha correspondente actitude de desaprobación e crítica cara ao proxecto;
- a popularidade en aumento recente de Kubernetes, cuxo recordo aínda está fresco.
Xuntos, estes factores combínanse para crear un ambiente estupendo e sen osíxeno no que se debilita a capacidade de xuízo racional e só queda a variedade estraña. .
Desde o punto de vista de Linkerd, isto é... Eu describiríao como unha bendición mixta. Quero dicir, é xenial que a malla de servizo entrou na corrente principal dun xeito que non o fixo en 2016 cando comezou Linkerd e foi moi difícil conseguir que a xente prestase atención ao proxecto. Agora non hai tal problema! Pero a mala noticia é que a situación da malla de servizo é tan confusa hoxe que é case imposible descubrir cales son os proxectos que realmente pertencen á categoría de malla de servizo (e menos cal é o mellor para un caso de uso particular). Isto certamente se mete no camiño de todos (e definitivamente nalgúns casos Istio ou outro proxecto é mellor que Linkerd, xa que este último non é unha solución única).
Desde o lado de Linkerd, a nosa estratexia foi ignorar o ruído, seguir centrándonos en resolver os problemas reais da comunidade e, esencialmente, esperar a que se apague o bombo. Ao final o bombo desaparecerá e podemos seguir traballando en paz.
Ata entón, todos teremos que ter paciencia.
Será útil a malla de servizo para min, un modesto enxeñeiro de software?
O seguinte cuestionario axudarache a responder a esta pregunta:
Estás implicado exclusivamente na implementación da lóxica empresarial? Neste caso, a malla de servizo non che será útil. É dicir, por suposto, pode estar interesado nel, pero o ideal é que a malla de servizo non afecte directamente a nada da súa contorna. Continúa traballando no que se lle paga.
Mantén unha plataforma nunha empresa que utiliza Kubernetes? Si, neste caso necesitas unha malla de servizo (a menos que, por suposto, esteas a usar K8 só para executar un procesamento monolito ou por lotes, pero entón gustaríame preguntar por que necesitas K8s). É probable que acabes con moitos microservizos escritos por diferentes persoas. Todos interactúan entre si e están ligados a unha maraña de dependencias en tempo de execución, e cómpre atopar un xeito de tratar con todo. O uso de Kubernetes permítelle escoller unha malla de servizo "por si mesmo". Para iso, familiarízase coas súas capacidades e características e responde á pregunta de se algún dos proxectos dispoñibles é axeitado para ti (recomendo que comece a investigación con Linkerd).
Estás executando unha plataforma para unha empresa que NON usa Kubernetes pero usa microservizos? Neste caso, unha malla de servizo será útil para ti, pero o seu uso non será trivial. Por suposto que podes imitar malla de servizo ao hospedar unha morea de proxies, pero unha vantaxe importante de Kubernetes é precisamente o modelo de implantación: manter estes proxies manualmente requirirá moito máis tempo, esforzo e custo.
Vostede é o responsable da plataforma nunha empresa que traballa con monólitos? Neste caso, probablemente non necesites unha malla de servizo. Se estás traballando con monólitos (ou incluso con coleccións de monólitos) que teñen patróns de interacción ben definidos e raramente cambiantes, entón unha malla de servizo terá pouco que ofrecerche. Así que pode simplemente ignoralo e esperar que desapareza como un mal soño...
Conclusión
Probablemente, a malla de servizo aínda non debería chamarse "a tecnoloxía máis publicitada do mundo": este dubidoso honor probablemente pertenza a bitcoin ou AI. Quizais estea entre os cinco primeiros. Pero se rompes as capas de ruído e ruído, queda claro que a malla de servizo trae beneficios reais para quen crea aplicacións en Kubernetes.
Gustaríame que probes Linkerd, instalándoo nun clúster de Kubernetes (ou incluso Minikube nun portátil) , e podes ver por ti mesmo do que estou a falar.
FAQ
- Se ignoro a malla de servizo, desaparecerá?
— Debo decepcionarte: a malla de servizo leva moito tempo connosco.
- Pero NON QUERO usar a malla de servizo!
- Pois non é necesario! Só tes que ler o meu cuestionario anterior para entender se deberías polo menos familiarizarte cos seus conceptos básicos.
— Non é un bo ESB/middleware vello cunha salsa nova?
— A rede de servizos trata a lóxica operativa, non a semántica. autobús de servizo empresarial (). Manter esta separación axuda á malla de servizo a evitar o mesmo destino.
- En que se diferencia unha malla de servizo das pasarelas de API?
— Hai un millón de artigos sobre este tema. Só google.
Envoy é unha malla de servizo?
- Non, Envoy non é unha malla de servizo, é un servidor proxy. Pódese usar para organizar unha malla de servizo (e moito máis: é un proxy de propósito xeral). Pero por si só, non é unha malla de servizo.
- Network Service Mesh: é unha malla de servizo?
- Non. A pesar do nome, esta non é unha malla de servizo (como che gustan as marabillas do marketing?).
— Axudará unha malla de servizo co meu sistema asíncrono reactivo baseado na fila de mensaxes?
- Non, a malla de servizo non che axudará.
— Que malla de servizo debo usar?
- , sen dúbida.
- O artigo é unha merda! / O autor é benvido!
— Por favor, comparte a ligazón con todos os teus amigos para que se convenzan diso!
Agradecementos
Como poderías adiviñar polo título, este artigo inspirouse no fantástico tratado de Jay Kreps "". Coñecín a Jay hai dez anos mentres facía unha entrevista en Linked In e desde entón foi unha inspiración para min.
Aínda que me gusta chamarme "desenvolvedor de Linkerd", a realidade é que son máis un mantedor do ficheiro README.md nun proxecto. Hoxe estase a traballar en Linkerd , , persoas, e este proxecto non tería feito sen a participación dunha marabillosa comunidade de colaboradores e usuarios.
E, por último, un agradecemento especial ao creador de Linkerd, (primus inter pares), que, xunto comigo hai moitos anos, mergullouse de cabeza en todo este balbordo coa malla de servizo.
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com