Nota. transl.: La malla de servei és un fenomen que encara no té una traducció estable al rus (fa més de 2 anys vam proposar l'opció "malla per a serveis", i una mica més tard alguns companys van començar a promoure activament la combinació "tamís de servei"). Parlar constantment d'aquesta tecnologia ha portat a una situació en què els components tècnics i de màrqueting estan massa entrellaçats. Aquest meravellós material d'un dels autors del terme original pretén proporcionar claredat als enginyers i altres.
Còmic de
Introducció
Si sou un enginyer de programari que treballa en algun lloc de l'espai dels sistemes de fons, probablement el terme "malla de servei" ja s'hagi arrelat fermament a la vostra ment durant els darrers dos anys. Gràcies a una estranya coincidència, aquesta frase s'apodera de la indústria cada cop més, i l'exageració i les ofertes promocionals associades a ella creixen com una bola de neu que vola cap avall i no mostra signes d'alentiment.
La malla de servei va néixer a les aigües tèrboles i esbiaixades de l'ecosistema natiu del núvol. Malauradament, això vol dir que gran part de la controvèrsia que l'envolta va des de "parlades baixes en calories" fins a, per utilitzar un terme tècnic, absurdes. Però si talleu tot el soroll, trobareu que la malla de servei té una funció molt real, definida i important.
En aquesta publicació, intentaré fer exactament això: proporcionar una guia honesta, profunda i centrada en l'enginyer per a la malla de servei. No només respondré la pregunta: "Què és això?", - però també "Per què?"I "Per què ara?". Finalment, intentaré esbossar per què (al meu entendre) aquesta tecnologia en particular ha provocat un enrenou tan boig, que és una història interessant en si mateixa.
Qui sóc
Hola a tots! El meu nom és . Sóc un dels creadors — el primer projecte de malla de servei i el projecte culpable de l'aparició del terme malla de servei com a tal (ho sento nois!). (Nota transl.: Per cert, a l'alba de l'aparició d'aquest terme, fa més de 2,5 anys, ja vam traduir el material primerenc del mateix autor titulat “".) Jo també el cap és una startup que crea coses interessants de malla de servei com Linkerd i .
Probablement podeu endevinar que tinc una opinió molt esbiaixada i subjectiva sobre aquest tema. Tanmateix, intentaré mantenir el biaix al mínim (a excepció d'una secció: "Per què es parla tant de la malla de servei?", - en què encara compartiré les meves idees preconcebudes). També faré tot el possible perquè aquesta guia sigui el més objectiva possible. Per a exemples específics, em basaré principalment en l'experiència de Linkerd, tot assenyalant les diferències (si n'hi ha) que conec en la implementació d'altres tipus de malla de servei.
D'acord, és hora de passar a les llaminadures.
Què és una malla de servei?
Malgrat tot el bombo, l'estructura de la malla de servei és bastant simple. Es tracta només d'un munt de servidors intermediaris d'espai d'usuari situats "al costat" dels serveis (parlarem una mica sobre què és el "següent" més endavant), a més d'un conjunt de processos de control. Els proxies s'anomenen col·lectivament pla de dades, i els processos de control s'anomenen avió de control. El pla de dades intercepta trucades entre serveis i fa "tot tipus de coses diferents" amb elles; El pla de control, en conseqüència, coordina el comportament del proxy i us proporciona accés, és a dir. operador, a l'API, permetent manipular i mesurar la xarxa en el seu conjunt.
Quin tipus de proxy és aquest? Aquest és un servidor intermediari TCP conscient de la capa 7 (és a dir, "tenint en compte" la capa 7 del model OSI) com HAProxy i NGINX. Podeu triar un proxy al vostre gust; Linkerd utilitza un proxy Rust, anomenat simplement . Ho vam muntar específicament per a la malla de servei. Altres malles prefereixen altres proxies (Envoy és una opció habitual). Tanmateix, triar un proxy és només una qüestió d'implementació.
Què fan aquests servidors proxy? Òbviament, fan trucades intermediaris cap a i des dels serveis (en sentit estricte, actuen com a intermediaris i proxies inversos, gestionant tant les trucades entrants com les sortints). I implementen un conjunt de funcions que se centra en les trucades между serveis. Aquest enfocament en el trànsit entre serveis és el que distingeix un servidor intermediari de malla de serveis de, per exemple, passarel·les d'API o servidors intermediaris d'entrada (aquests últims se centren en les trucades que arriben al clúster des del món exterior). (Nota. transl.: Per a una comparació dels controladors Ingress existents per a Kubernetes, molts dels quals utilitzen l'Envoy ja esmentat, vegeu .)
Per tant, hem resolt el pla de dades. El pla de control és més senzill: és un conjunt de components que proporcionen tota la mecànica que el pla de dades necessita per operar de manera coordinada, inclosa la descoberta de serveis, l'emissió de certificats TLS, l'agregació de mètriques, etc. El pla de dades informa al pla de control de el seu comportament; al seu torn, el pla de control proporciona una API que us permet canviar i supervisar el comportament del pla de dades en conjunt.
A continuació es mostra un diagrama del pla de control i el pla de dades a Linkerd. Com podeu veure, el pla de control inclou diversos components diferents, inclosa una instància de Prometheus que recull mètriques dels servidors intermediaris, així com altres components com ara destination (descobriment de serveis), identity (autoritat de certificació, CA) i public-api (punts finals per a web i CLI). En canvi, el pla de dades és un simple linkerd-proxy al costat de la instància de l'aplicació. Això és només un diagrama lògic; En un desplegament real, és possible que tingueu tres rèpliques de cada component del pla de control i centenars o milers de servidors intermediaris al pla de dades.
(Els rectangles blaus d'aquest diagrama simbolitzen els límits dels pods de Kubernetes. Podeu veure que els contenidors amb linkerd-proxy es troben al mateix pod que els contenidors de l'aplicació. Aquest esquema es coneix com contenidor sidecar.)
L'arquitectura de malla de servei té diverses implicacions importants. En primer lloc, com que la tasca d'un servidor intermediari és interceptar trucades entre serveis, una malla de serveis només té sentit si la vostra aplicació es va crear per a un determinat conjunt de serveis. Malla un pot s'utilitza amb monòlits, però això és clarament redundant pel bé d'un sol intermediari, i és poc probable que la seva funcionalitat sigui demandada.
Una altra conseqüència important és que la malla de servei requereix enorme nombre de proxys. De fet, Linkerd adjunta un proxy linkerd a cada instància de cada servei (altres implementacions afegeixen un proxy a cada node/amfitrió/màquina virtual. Això és molt de totes maneres). Aquest ús actiu de proxies en si mateix comporta una sèrie de complicacions addicionals:
- Els servidors intermediaris al pla de dades han de ser ràpid, ja que per a cada trucada hi ha un parell de trucades al proxy: una al costat del client, una al costat del servidor.
- També haurien de ser proxies petit и lleuger. Cadascun consumirà memòria i recursos de CPU, i aquest consum creixerà de manera lineal amb l'aplicació.
- Necessitareu un mecanisme per desplegar i actualitzar un gran nombre de servidors intermediaris. Fer-ho manualment no és una opció.
En general, una malla de servei té aquest aspecte (almenys des d'una vista d'ocell): desplegueu un munt de servidors intermediaris d'espai d'usuari que "fer alguna cosa" amb el trànsit intern, entre serveis i utilitzeu un pla de control per supervisar-los i gestionar-los.
Ara és el moment de fer la pregunta "Per què?"
Per a què serveix una malla de servei?
Els que van trobar per primera vegada la idea d'una malla de servei podrien ser perdonats per sentir-se una mica trepidants. El disseny de malla de servei significa que no només augmentarà la latència a l'aplicació, sinó que també ho farà consumir recursos i afegirà un munt de nous mecanismes en la infraestructura. Primer configureu una malla de servei i, de sobte, us trobeu amb la necessitat de donar servei a centenars (si no milers) de servidors intermediaris. La pregunta és, qui ho farà voluntàriament?
La resposta a aquesta pregunta té dues parts. En primer lloc, els costos de transacció associats amb el desplegament d'aquests servidors intermediaris es poden reduir significativament gràcies a alguns canvis que es produeixen a l'ecosistema (més sobre això més endavant).
En segon lloc, un dispositiu com aquest és en realitat una bona manera d'introduir lògica addicional al sistema. No només perquè una malla de servei pot afegir moltes funcionalitats noves, sinó també perquè es pot fer sense interferir amb l'ecosistema. De fet, tot el model de malla de servei es basa en aquesta premissa: en un sistema multiservei, sigui el que passi fer serveis individuals, trànsit entre ells és el punt ideal per afegir funcionalitat.
Per exemple, a Linkerd (com en la majoria de malles) la funcionalitat se centra principalment en les trucades HTTP, incloses HTTP/2 i gRPC*. La funcionalitat és bastant rica: es pot dividir en tres classes:
- Característiques relacionades amb fiabilitat. Sol·licituds repetides, temps d'espera, enfocament canari (divisió/redirecció del trànsit), etc.
- Característiques relacionades amb seguiment. Agregació de taxes d'èxit, retards i volums de sol·licituds per a cada servei o direccions individuals; construcció de mapes topològics de serveis, etc.
- Característiques relacionades amb seguretat. TLS mutu, control d'accés, etc.
* Des del punt de vista de Linkerd, gRPC pràcticament no és diferent d'HTTP/2: només utilitza protobuf a la càrrega útil. Des del punt de vista d'un desenvolupador, les dues coses són, per descomptat, diferents.
Molts d'aquests mecanismes operen a nivell de sol·licitud (d'aquí el "proxy L7"). Per exemple, si el servei Foo fa una trucada HTTP al servei Bar, el linkerd-proxy del costat Foo pot realitzar un equilibri de càrrega intel·ligent i encaminar trucades des de les instàncies de Foo a Bar en funció de la latència observada; pot repetir la petició si cal (i si és idempotent); pot gravar el codi de resposta i el temps d'espera, etc. De la mateixa manera, linkerd-proxy al costat de la barra pot rebutjar una sol·licitud si no està permesa o si es supera el límit de sol·licitud; pot registrar un retard per part seva, etc.
Els servidors intermediaris també poden "fer alguna cosa" a nivell de connexió. Per exemple, el linkerd-proxy del costat Foo pot iniciar una connexió TLS, i el linkerd-proxy del costat de la barra la pot finalitzar, i ambdues parts poden verificar els certificats TLS de l'altre*. Això proporciona no només xifratge entre serveis, sinó també una forma criptogràfica segura d'identificar els serveis: Foo i Bar poden "provar" que són qui diuen ser.
* "Mútua d'un amic" significa que el certificat del client també està verificat (TLS mutu). En el TLS "clàssic", per exemple entre un navegador i un servidor, normalment es verifica el certificat d'un sol costat (el servidor).
Independentment de si operen a nivell de sol·licitud o de connexió, és important destacar que totes les funcions de malla de servei són operatiu personatge. Linkerd no és capaç de transformar la semàntica de la càrrega útil, per exemple, afegint camps a un fragment JSON o fent canvis a protobuf. Més endavant parlarem d'aquesta característica important quan parlem d'ESB i middleware.
Aquest és el conjunt de funcions que ofereix una xarxa de serveis. Sorgeix la pregunta: per què no implementar-los directament a l'aplicació? I per què molestar-se amb un proxy?
Per què la malla de servei és una bona idea
Tot i que les capacitats d'una malla de servei són emocionants, el seu valor fonamental no rau en les seves característiques. Al final nosaltres Llauna implementar-los directament a l'aplicació (més endavant veurem que aquest va ser l'origen de la malla de servei). Per intentar resumir-ho en una frase, el valor d'una malla de servei és: proporciona funcions crítiques per executar el programari de servidor modern de manera coherent a tota la pila i independentment del codi de l'aplicació.
Analitzem aquesta proposta.
«Funcions crítiques per executar el programari de servidor modern" Si esteu creant una aplicació de servidor transaccional connectada a Internet pública, acceptant sol·licituds del món exterior i responent-hi en poc temps, per exemple, una aplicació web, un servidor API i la gran majoria d'altres aplicacions modernes. - i si ho implementeu com un conjunt de serveis que interactuen de manera sincrònica entre ells, i si esteu actualitzant constantment aquest programari, afegint noves funcions i si us oblideu a mantenir aquest sistema en estat de funcionament durant el procés de modificació, en aquest cas, enhorabona, esteu creant un programari de servidor modern. I totes aquestes excel·lents característiques enumerades anteriorment resulten ser crítiques per a vostè. L'aplicació ha de ser fiable, segura i has de poder observar què està fent. Aquestes són exactament les preguntes que la malla de servei ajuda a resoldre.
(D'acord, el paràgraf anterior encara inclou la meva creença que aquest enfocament és la forma moderna de crear programari de servidor. Altres prefereixen desenvolupar monòlits, "microserveis reactius" i altres coses que no entren dins de la definició donada anteriorment. Probablement aquestes persones tinguin el seu l'opinió és diferent de la meva. Al seu torn, crec que estan "equivocats", encara que en tot cas la malla de servei no els és molt útil).
«Uniforme per a tota la pila" La funcionalitat proporcionada per una malla de servei no només és crítica per a la missió. S'apliquen a tots els serveis de l'aplicació, independentment de l'idioma en què estiguin escrits, quin marc utilitzen, qui els va escriure, com s'han desplegat i qualsevol altra subtilesa del seu desenvolupament i ús.
«Independent del codi de l'aplicació" Finalment, una malla de servei no només proporciona una funcionalitat coherent a tota la pila, sinó que ho fa d'una manera que no requereix que l'aplicació s'editi. La base fonamental de la funcionalitat de la malla de servei, incloses les tasques de configuració, actualització, operació, manteniment, etc., resideix completament a nivell de plataforma i és independent de l'aplicació. L'aplicació pot canviar sense afectar la malla de servei. Al seu torn, la malla del servei pot canviar sense cap participació de l'aplicació.
En resum, una malla de servei no només proporciona una funcionalitat vital, sinó que també ho fa de manera global, uniforme i independent de l'aplicació. Així, tot i que la funcionalitat de la malla de servei es pot implementar en el codi de servei (per exemple, com a biblioteca inclosa a cada servei), aquest enfocament no proporcionarà la uniformitat i la independència que són tan valuoses en el cas d'una malla de servei.
I tot el que heu de fer és afegir un munt de proxies! Prometo que mirarem molt aviat els costos operatius associats a afegir aquests proxys. Però primer aturem-nos i mirem aquesta idea d'independència des de diferents perspectives. persones.
A qui ajuda la malla de servei?
Per inconvenient que sigui, perquè una tecnologia esdevingui una part important de l'ecosistema, ha de ser acceptada per la gent. Aleshores, qui està interessat en la malla de servei? Qui es beneficia del seu ús?
Si esteu desenvolupant un programari de servidor modern, podeu pensar aproximadament en el vostre equip com a grup propietaris de serveisque conjuntament desenvolupen i implementen la lògica empresarial, i propietaris de la plataforma, desenvolupant la plataforma interna en la qual operen aquests serveis. A les organitzacions petites, poden ser les mateixes persones, però a mesura que l'empresa creix, aquests rols tendeixen a ser més pronunciats i fins i tot dividir-se en subrols... (Hi ha molt a dir aquí sobre la naturalesa canviant dels devops, l'impacte organitzatiu dels microserveis, etc.) n. Però, de moment, prenem aquestes descripcions com a donades).
Des d'aquest punt de vista, els clars beneficiaris de la malla de servei són els propietaris de la plataforma. Després de tot, en última instància, l'objectiu de l'equip de la plataforma és crear una plataforma interna en la qual els propietaris del servei puguin implementar la lògica empresarial i fer-ho d'una manera que garanteixi que siguin el més independents possible dels detalls tèrbols del seu funcionament. Una xarxa de serveis no només ofereix capacitats crítiques per assolir aquest objectiu, sinó que ho fa d'una manera que al seu torn no imposa dependències als propietaris del servei.
Els propietaris de serveis també es beneficien, encara que d'una manera més indirecta. L'objectiu del propietari del servei és ser el més productiu possible en la implementació de la lògica del procés de negoci, i com menys s'hagi de preocupar per problemes operatius, millor. En lloc d'haver de fer front a la implementació, per exemple, de polítiques de reintentar o TLS, poden centrar-se únicament en els objectius empresarials i esperar que la plataforma s'ocupi de la resta. Això és un gran avantatge per a ells.
El valor organitzatiu d'aquesta divisió entre els propietaris de plataformes i serveis no es pot sobreestimar. Crec que ella contribueix principal contribució al valor de la malla de servei.
Vam aprendre aquesta lliçó quan un dels primers fans de Linkerd ens va dir per què van triar la malla de servei: perquè els va permetre "mantenir la botiga parlant al mínim". Aquí hi ha alguns detalls: els nois d'una gran empresa van migrar la seva plataforma a Kubernetes. Com que l'aplicació gestionava informació sensible, volien xifrar totes les comunicacions dels clústers. Tanmateix, la situació es va complicar per la presència de centenars de serveis i centenars d'equips de desenvolupament. La perspectiva de posar-se en contacte amb tothom i convèncer-los perquè incloguessin el suport TLS als seus plans no els va fer gens feliços. Després d'instal·lar Linkerd, es van transferir responsabilitat des de desenvolupadors (des del punt de vista dels quals això era un problema innecessari) fins a plataformes, per als quals això era una prioritat de primer nivell. En altres paraules, Linkerd els va resoldre no tant un problema tècnic com organitzatiu.
En resum, una malla de servei és més una solució, no tècnica, però sociotècnics Problemes. (Gràcies per introduir aquest terme.)
Una malla de servei resoldrà tots els meus problemes?
Sí. Vull dir, no!
Si observeu les tres classes de funcions descrites anteriorment (fiabilitat, seguretat i observabilitat), queda clar que una malla de servei no és una solució completa a cap d'aquests problemes. Tot i que Linkerd pot tornar a emetre sol·licituds (si sap que són idempotents), no pot prendre decisions sobre què retornar a l'usuari si el servei ha fallat permanentment; aquestes decisions les ha de prendre l'aplicació. Linkerd pot mantenir estadístiques de sol·licituds reeixides, però no pot examinar el servei i proporcionar les seves mètriques internes: l'aplicació ha de tenir aquestes eines. I encara que Linkerd és capaç d'organitzar mTLS, les solucions de seguretat completes requereixen molt més.
Es refereix a un subconjunt de les funcions d'aquestes àrees que ofereix la malla de servei característiques de la plataforma. Amb això vull dir funcions que:
- Independent de la lògica empresarial. La manera com es construeixen els histogrames de trucada entre Foo i Bar és completament independent per què Foo truca a Bar.
- Difícil d'implementar correctament. A Linkerd, els reintents es parametritzen amb tot tipus de coses elegants, com ara pressupostos de reintents (reprova els pressupostos), ja que un enfocament poc sofisticat i frontal per implementar aquestes coses, sens dubte, conduirà a l'aparició de l'anomenada "allau de peticions" (torna a provar la tempesta) i altres problemes característics dels sistemes distribuïts.
- Més eficaç quan s'aplica de manera uniforme. El mecanisme TLS només té sentit si s'aplica a tot arreu.
Com que aquestes funcions s'implementen a nivell de proxy (i no a nivell d'aplicació), la malla de servei les proporciona a la plataformes, no aplicacions. Així, no importa en quina llengua estan escrits els serveis, en quin marc utilitzen, qui els va escriure i per què. Els proxies operen fora de tots aquests detalls, i la base fonamental d'aquesta funcionalitat, incloses les tasques de configuració, actualització, operació, manteniment, etc., es troba únicament a nivell de plataforma.
Exemples de capacitats de malla de servei
En resum, una malla de servei no és una solució completa de fiabilitat, observabilitat o seguretat. L'abast d'aquestes àrees requereix la participació dels propietaris de serveis, equips d'Ops/SRE i altres entitats de l'empresa. La malla de servei només proporciona una "part" a nivell de plataforma per a cadascuna d'aquestes àrees.
Per què s'ha fet popular la malla de servei ara mateix?
A hores d'ara probablement us preguntareu: d'acord, si la malla de servei és tan bona, per què no vam començar a desplegar milions de servidors intermediaris a la pila fa deu anys?
Hi ha una resposta banal a aquesta pregunta: fa deu anys tothom va construir monòlits i ningú necessitava una malla de servei. Això és cert, però al meu entendre aquesta resposta no té sentit. Fins i tot fa deu anys, el concepte de microserveis com una forma prometedora de construir sistemes a gran escala va ser àmpliament discutit i aplicat a empreses com Twitter, Facebook, Google i Netflix. La visió general, almenys a les parts de la indústria amb què vaig entrar en contacte, era que els microserveis eren la "manera correcta" de construir sistemes grans, encara que fos molt difícil.
Per descomptat, tot i que fa deu anys hi havia empreses que operaven microserveis, no van enganxar proxies a tot arreu per formar una malla de serveis. Tanmateix, si us fixeu bé, van fer una cosa semblant: moltes d'aquestes empreses requerien l'ús d'una biblioteca interna especial per a la comunicació en xarxa (de vegades anomenada biblioteca de client gruixut, biblioteca fat client).
Netflix tenia Hysterix, Google tenia Stubby, Twitter tenia la biblioteca Finagle. Finagle, per exemple, era obligatori per a cada servei nou a Twitter. Va gestionar tant el costat del client com el del servidor de les connexions, permetia sol·licituds repetides, encaminament de sol·licituds compatibles, equilibri de càrrega i mesura. Va proporcionar una capa consistent de fiabilitat i observabilitat a tota la pila de Twitter, independentment del que fes el servei. Per descomptat, només funcionava per a llenguatges JVM i es basava en un model de programació que s'havia d'utilitzar per a tota l'aplicació. Tanmateix, la seva funcionalitat era gairebé la mateixa que la de la malla de servei. (De fet, la primera versió de Linkerd era simplement Finagle embolicat en forma de proxy.)
Així, fa deu anys no només hi havia microserveis, sinó també biblioteques especials de malla de protoservei que resolien els mateixos problemes que soluciona avui la malla de servei. Tanmateix, la malla de servei en si no existia aleshores. Hi havia d'haver un torn més abans que aparegués.
I aquí és on rau la resposta més profunda, amagada en un altre canvi que s'ha produït durant els últims 10 anys: el cost del desplegament de microserveis ha baixat dràsticament. Les empreses esmentades anteriorment que utilitzaven microserveis fa deu anys —Twitter, Netflix, Facebook, Google— eren empreses d'una escala enorme i de recursos enormes. No només tenien la necessitat, sinó també la capacitat de crear, desplegar i operar grans aplicacions basades en microserveis. L'energia i l'esforç que els enginyers de Twitter dediquen a passar d'un enfocament monolític a un enfocament de microserveis és sorprenent. (Per ser justos, també ho és el fet que va tenir èxit.) Aleshores, aquest tipus de maniobres d'infraestructura eren impossibles per a les empreses més petites.
Avancem ràpid fins al present. Actualment hi ha startups on la proporció de microserveis a desenvolupadors és de 5:1 (o fins i tot ), i a més, s'hi enfronten amb èxit! Si una startup de 5 persones pot operar fàcilment 50 microserveis, llavors alguna cosa ha reduït clarament el cost de la seva implementació.
1500 microserveis a Monzo; cada línia és una regla de xarxa prescrita que permet el trànsit
La dramàtica reducció del cost d'operar els microserveis és el resultat d'un procés: creixent popularitat dels contenidors и orquestradors. Aquesta és precisament la resposta profunda a la pregunta de què va contribuir a l'aparició de la xarxa de serveis. La mateixa tecnologia va fer atractius tant les malles de servei com els microserveis: Kubernetes i Docker.
Per què? Bé, Docker resol un gran problema: el problema de l'embalatge. En empaquetar una aplicació i les seves dependències en temps d'execució (que no són de xarxa) en un contenidor, Docker converteix l'aplicació en una unitat intercanviable que es pot allotjar i executar a qualsevol lloc. Al mateix temps, simplifica molt el funcionament multilingüe Pila: com que un contenidor és una unitat atòmica d'execució, amb finalitats operatives i de desplegament, no importa el que hi hagi dins, ja sigui una aplicació JVM, Node, Go, Python o Ruby. L'acabes de llançar i ja està.
Kubernetes ho porta tot al següent nivell. Ara que hi ha tones de "coses per executar" i tones de màquines per executar-les, cal una eina que les pugui correlacionar entre elles. En un sentit ampli, doneu a Kubernetes molts contenidors i moltes màquines, i els mapeja els uns amb els altres (per descomptat, aquest és un procés dinàmic i en constant canvi: els nous contenidors es mouen pel sistema, les màquines s'inicien i s'aturen). , etc. Tanmateix, Kubernetes té tot això en compte).
Un cop configurat Kubernetes, el cost de temps per implementar i operar un servei és poc diferent del cost de desplegar i operar deu serveis (de fet, és gairebé el mateix per a 100 serveis). Afegiu-hi contenidors com a mecanisme d'embalatge que fomenta la implementació multilingüe i teniu una gran quantitat d'aplicacions noves implementades en forma de microserveis escrits en diferents idiomes, exactament el tipus d'entorn per al qual una malla de serveis és tan adequada.
Així doncs, arribem a la resposta a la pregunta de per què la idea d'una malla de servei s'ha popularitzat ara: l'homogeneïtat que Kubernetes ofereix als serveis s'aplica directament als reptes operatius que afronta una malla de serveis. Envaseu els servidors intermediaris en contenidors, doneu a Kubernetes la tasca d'enganxar-los allà on pugui i voilà! Com a resultat, obteniu una malla de servei, mentre que totes les mecàniques del seu desplegament són gestionades per Kubernetes. (Almenys a vista d'ocell. Per descomptat, hi ha molts matisos en aquest procés.)
En resum: la raó per la qual les malles de servei s'han popularitzat ara, i no fa deu anys, és que Kubernetes i Docker no només han augmentat significativament. necessitat en ell, havent simplificat la implementació d'aplicacions com a conjunts de microserveis multilingües, però també reduït notablement costos per al seu funcionament, proporcionant mecanismes per desplegar i donar suport a flotes de proxy sidecar.
Per què es parla tant de la malla de servei?
Advertència: En aquesta secció faig ús de tot tipus de suposicions, conjectures, fabricacions i informació privilegiada.
Feu una cerca de "malla de servei" i trobareu un munt de contingut reciclat baix en calories, projectes estranys i un calidoscopi de distorsió digne d'una cambra d'eco. Qualsevol nova tecnologia fantàstica ho fa, però en el cas d'una malla de servei el problema és especialment greu. Per què?
Bé, part d'això és culpa meva. He estat treballant dur per promocionar Linkerd i la xarxa de serveis cada vegada que tinc l'oportunitat d'aconseguir innombrables publicacions de bloc i articles com aquest. Però no sóc tan poderós. Per respondre realment aquesta pregunta, hem de parlar una mica de la situació general. I és impossible parlar-ne sense esmentar un projecte: és una malla de serveis de codi obert desenvolupada conjuntament per Google, IBM i Lyft.
(Les tres empreses tenen rols molt diferents: la participació de Lyft sembla ser només de nom; són els autors d'Envoy, però no utilitzen ni participen en el desenvolupament d'Istio. IBM participa i utilitza el desenvolupament d'Istio. Google participa activament en el desenvolupament d'Istio. desenvolupament, però en realitat no l'utilitza pel que puc dir.)
El projecte Istio destaca per dues coses. En primer lloc, hi ha l'enorme esforç de màrqueting que Google, en particular, està fent per promocionar-lo. Estimaria que la majoria de les persones conscients del concepte de malla de servei avui ho van conèixer per primera vegada a través d'Istio. La segona cosa és la mala acollida que va tenir Istio. En aquest assumpte, òbviament sóc una part interessada, però intentant ser el més objectiu possible, encara no puc evitar , no gaire distintiu (encara que no és únic: em ve al cap systemd, ...) per a un projecte de codi obert.
(A la pràctica, Istio sembla tenir problemes no només amb la complexitat i la UX, sinó també amb el rendiment. Per exemple, durant En un estudi de tercers, els investigadors van trobar situacions en què la latència de la cua d'Istio era 100 vegades més gran que la de Linkerd, així com situacions sense recursos on Linkerd continuava funcionant amb èxit mentre Istio deixava de funcionar completament.)
Deixant de banda les meves teories sobre per què va passar això, crec que l'emoció aclaparadora al voltant de la malla del servei s'explica per la participació de Google. És a dir, una combinació dels tres factors següents:
- la promoció intrusiva de Google d'Istio;
- una actitud crítica i de reprovació corresponent envers el projecte;
- el recent augment meteòric de la popularitat de Kubernetes, els records del qual encara són frescos.
Junts, aquests factors es combinen per crear un entorn estupefador i lliure d'oxigen en el qual la capacitat de judici racional es debilita i només queda la varietat estranya. .
Des de la perspectiva de Linkerd, això és... el que descriuria com una benedicció mixta. Vull dir, és fantàstic que la malla de servei hagi entrat al corrent principal d'una manera que no ho va fer el 2016 quan va començar Linkerd i va ser molt difícil que la gent prestés atenció al projecte. Ara no hi ha aquest problema! Però la mala notícia és que el panorama de la malla de servei és tan confús avui en dia que és gairebé impossible entendre quins projectes pertanyen realment a la categoria de malla de servei (i molt menys entendre quin és el més adequat per a un cas d'ús particular). Definitivament, això és un dealbreaker per a tothom (i sens dubte hi ha alguns casos en què Istio o un altre projecte és més adequat que Linkerd, ja que aquest últim encara no és una solució universal).
Per part de Linkerd, la nostra estratègia ha estat ignorar el soroll, continuar centrant-nos en resoldre problemes reals de la comunitat i esperar, bàsicament, que s'apagui el bombo. Al final, el bombo s'apagarà i podem continuar treballant amb calma.
Mentrestant, tots haurem de tenir una mica de paciència.
Em serà útil una malla de servei, un humil enginyer de programari?
El següent qüestionari us ajudarà a respondre aquesta pregunta:
Esteu implicat únicament en la implementació de la lògica empresarial? En aquest cas, la malla de servei no us serà útil. És a dir, per descomptat, us pot interessar, però idealment la malla de servei no hauria d'afectar directament res del vostre entorn. Segueix treballant en allò que et paguen.
Doneu suport a la plataforma en una empresa que utilitza Kubernetes? Sí, en aquest cas necessiteu una malla de servei (tret que, per descomptat, utilitzeu K8s només per executar un processament monòlit o per lots, però m'agradaria preguntar per què necessiteu K8s). És probable que acabeu amb molts microserveis escrits per diferents persones. Tots interactuen entre ells i estan lligats a un embolcall de dependències en temps d'execució, i cal que trobeu una manera de tractar-ho tot. L'ús de Kubernetes us permet triar una malla de servei "per a vosaltres mateixos". Per fer-ho, familiaritzeu-vos amb les seves capacitats i característiques i responeu a la pregunta de si algun dels projectes disponibles és adequat per a vosaltres (recomano que comenceu la vostra recerca amb Linkerd).
Sou una empresa de plataformes en una empresa que NO utilitza Kubernetes però utilitza microserveis? En aquest cas, una malla de servei us serà útil, però el seu ús no serà trivial. Per descomptat que pot imitar malla de servei de treball col·locant un munt de servidors intermediaris, però un avantatge important de Kubernetes és el model de desplegament: mantenir aquests servidors intermediaris manualment requerirà molt més temps, esforç i despeses.
Sou responsable de la plataforma en una empresa que treballa amb monòlits? En aquest cas, probablement no necessiteu una malla de servei. Si esteu treballant amb monòlits (o fins i tot col·leccions de monòlits) que tenen patrons d'interacció ben definits i rarament canviants, aleshores una malla de servei no tindrà molt a oferir-vos. Així que simplement podeu ignorar-lo i esperar que desaparegui com un mal somni...
Conclusió
Probablement, la malla de servei encara no s'hauria d'anomenar "la tecnologia més promocionada del món": aquest honor dubtós probablement pertany a Bitcoin o AI. Segurament està entre els cinc primers. Però si talleu les capes de soroll, queda clar que la malla de servei aporta avantatges reals a aquells que creen aplicacions a Kubernetes.
M'agradaria que proveu Linkerd: instal·lar-lo en un clúster de Kubernetes (o fins i tot Minikube en un ordinador portàtil) , i podeu veure per vosaltres mateixos de què parlo.
FAQ
— Si ignoro la malla de servei, desapareixerà?
— Us he de decebre: la malla de servei està amb nosaltres des de fa molt de temps.
- Però NO VULL utilitzar la malla de servei!
- Bé, no cal! Només cal que llegiu el meu qüestionari anterior per entendre si almenys us hauríeu de familiaritzar amb els conceptes bàsics.
— No és aquest bon vell ESB/intermediari amb una salsa nova?
— La malla de servei tracta la lògica operativa, no la semàntica. bus de servei empresarial (). Mantenir aquesta separació ajuda a la malla de servei a evitar la mateixa sort.
— En què es diferencia una malla de servei de les passarel·les API?
— Hi ha un milió d'articles sobre aquest tema. Només el Google.
— Envoy és una malla de servei?
- No, Envoy no és una malla de servei, és un servidor intermediari. Es pot utilitzar per organitzar una malla de servei (i molt més: és un proxy de propòsit general). Però en si mateix no és una malla de servei.
— Network Service Mesh és una malla de servei?
- No. Malgrat el nom, això no és una malla de servei (com us agraden els miracles de màrqueting?).
— Una malla de servei m'ajudarà amb el meu sistema asíncron reactiu basat en la cua de missatges?
- No, la malla de servei no us ajudarà.
— Quina malla de servei he d'utilitzar?
- , sense ganes.
- L'article és una merda! / L'autor és benvingut!
— Si us plau, compartiu l'enllaç amb tots els vostres amics perquè el vegin!
Agraïments
Com haureu endevinat pel títol, aquest article es va inspirar en el fantàstic tractat de Jay Kreps "" Vaig conèixer en Jay fa deu anys quan el vaig entrevistar a Linked In i des de llavors ha estat una inspiració per a mi.
Tot i que m'agrada anomenar-me "desenvolupador de Linkerd", la realitat és que sóc més un responsable del fitxer README.md d'un projecte. Avui s'està treballant en Linkerd , , persones, i aquest projecte no hauria succeït sense la participació d'una meravellosa comunitat de col·laboradors i usuaris.
I, finalment, un agraïment especial al creador de Linkerd, (primus entre pares), que, juntament amb mi fa molts anys, es va capbussar de cap en tot aquest enrenou amb la malla de servei.
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «»;
- «».
Font: www.habr.com