🥇Casos d'ús de malla de servei

Nota. transl.: L'autor d'aquest article (Luc Perkins) és un defensor dels desenvolupadors de l'organització CNCF, que acull projectes de codi obert com Linkerd, SMI (Service Mesh Interface) i Kuma (per cert, també us heu preguntat per què Istio és? no està en aquesta llista? .). Una vegada més, intentant que la comunitat DevOps entengui millor el bombo de moda anomenat "malla de servei", enumera 16 capacitats característiques que ofereixen aquestes solucions.

Avui malla de servei ― un dels temes més candents en el camp de l'enginyeria de programari (i amb raó!). Crec que aquesta tecnologia és increïblement prometedora i m'agradaria que s'adoptés àmpliament (quan tingui sentit, és clar). No obstant això, encara està envoltat d'una aura de misteri per a la majoria de la gent. Al mateix temps, fins i tot aquells que ben conegut amb ell, sovint és difícil formular els seus avantatges i què és exactament (incloent-hi el vostre). En aquest article intentaré corregir la situació enumerant diversos casos d'ús "malles de servei"*.

* Nota transl.: aquí i més enllà de l'article s'utilitzarà exactament aquesta traducció (“malla de servei”) per al terme encara nou de malla de servei.

Però abans vull fer uns quants comentaris:

Mai he treballat amb malles de servei ni les he fet servir fora de projectes iniciats per a la meva pròpia educació. D'altra banda, vaig ser jo qui va escriure un munt de documentació per a la malla de servei intern de Twitter l'any 2015 (ni tan sols s'anomenava "malla de servei") i vaig participar en el desenvolupament del lloc web i la documentació per a Linkerd, així que això vol dir alguna cosa.
La meva llista és aproximada i incompleta. És possible que hi hagi casos d'ús desconeguts per a mi, i probablement sorgiran noves opcions amb el temps a mesura que la tecnologia es desenvolupi i la seva popularitat creixi.
Al mateix temps, no totes les implementacions de malla de servei existents admeten tots els casos d'ús enumerats. Per tant, les meves declaracions com "la malla de servei pot..." s'han de llegir com a "individual, i potser totes les implementacions de malla de servei populars poden...".
L'ordre dels exemples no fa cap diferència.

Llista curta:

descobriment de serveis;
xifratge;
autenticació i autorització;
equilibri de càrrega;
interrupció del circuit;
autoescala;
desplegaments canaris;
desplegaments blau-verd;
revisió de salut;
despreniment de càrrega;
duplicació del trànsit;
aïllament;
limitació de velocitat de sol·licitud, reintents i temps d'espera;
telemetria;
auditoria;
visualització.

1. Descobriment de serveis

TL;DR: Connecteu-vos a altres serveis de la xarxa amb noms senzills.

Els serveis haurien de poder "trobar-se" automàticament entre ells utilitzant noms adequats, per exemple, service.api.production, pets/staging o cassandra. Els entorns al núvol són elàstics i un sol nom pot amagar moltes instàncies d'un servei. Està clar que en aquesta situació és físicament impossible codificar totes les adreces IP.

A més, quan un servei en troba un altre, hauria de poder enviar sol·licituds a aquest servei sense por que acabin a l'entrada de la seva instància trencada. En altres paraules, la malla de servei ha de supervisar la salut de totes les instàncies de servei i mantenir la llista d'amfitrions el més actualitzada possible.

Cada malla de servei implementa el mecanisme de descoberta de serveis de manera diferent. De moment, la forma més habitual és delegar en processos externs com el DNS de Kubernetes. En el passat a Twitter vam utilitzar un sistema de denominació per a aquesta finalitat Finagle. A més, la tecnologia de malla de servei fa possible que sorgeixin mecanismes de denominació personalitzats (tot i que encara no he vist cap implementació de SM amb aquesta funcionalitat).

2. Xifratge

TL;DR: desfer-se del trànsit no xifrat entre serveis i fer que aquest procés sigui automatitzat i escalable.

És bo saber que els atacants no poden penetrar a la vostra xarxa interna. Els tallafocs fan un gran treball en això. Però què passa si un pirata informàtic entra? Podrà fer el que vulgui amb el trànsit intraservei? Esperem que això no passi després de tot. Per evitar aquest escenari, hauríeu d'implementar una xarxa de confiança zero en què tot el trànsit entre serveis estigui xifrat. La majoria de les malles de servei modernes ho aconsegueixen a través de la mútua TLS (TLS mutu, mTLS). En alguns casos, mTLS funciona en núvols i clústers sencers (crec que les comunicacions interplanetàries algun dia s'organitzaran de manera similar).

Per descomptat, per a la malla de servei mTLS opcional. Cada servei pot tenir cura del seu propi TLS, però això vol dir que haureu de trobar una manera de generar certificats, distribuir-los entre els amfitrions del servei i incloure codi a l'aplicació que carregarà aquests certificats dels fitxers. Sí, no oblideu renovar aquests certificats a intervals regulars. Les malles de servei automatitzen mTLS amb sistemes com SPIFFE, que, al seu torn, automatitzen el procés d'emissió i rotació de certificats.

3. Autenticació i Autorització

TL;DR: estableix qui és el sol·licitant i defineix què pot fer abans que la sol·licitud arribi fins i tot al servei.

Els serveis sovint volen saber qui? realitza la sol·licitud (autenticació), i utilitzant aquesta informació, decideix que una entitat determinada pot fer (autorització). En aquest cas, el pronom "qui" pot amagar:

Altres serveis. Això s'anomena "autenticació" company" Per exemple, servei web vol accedir al servei db. Les malles de servei solen resoldre aquests problemes mitjançant mTLS: els certificats en aquest cas actuen com a identificador necessari.
Alguns usuaris humans. Això s'anomena "autenticació" petició" Per exemple, usuari haxor69 vol comprar un llum nou. Les malles de servei proporcionen diversos mecanismes, p. Fitxes web JSON.
Molts de nosaltres ho hem fet al codi de l'aplicació. Arriba una petició, mirem la taula users, cerqueu l'usuari i compareu la contrasenya i, a continuació, comproveu la columna permissions etc. En el cas d'una malla de servei, això passa abans que la sol·licitud arribi fins i tot al servei.

Un cop hem establert de qui prové la sol·licitud, hem de determinar què pot fer aquesta entitat. Algunes malles de servei us permeten establir polítiques bàsiques (sobre qui pot fer què) com a fitxers YAML o a la línia d'ordres, mentre que altres ofereixen integració amb marcs com ara Obriu l'agent de polítiques. L'objectiu final és que els vostres serveis acceptin qualsevol sol·licitud, assumint amb seguretat que prové d'una font de confiança и aquesta acció està permesa.

4. Equilibri de càrrega

TL;DR: distribueix la càrrega entre instàncies de servei segons un patró específic.

Un "Servei" dins d'una secció de servei sovint consta de moltes instàncies idèntiques. Per exemple, avui el servei cache consta de 5 exemplars, i demà el seu nombre pot augmentar fins a 11. Sol·licituds enviades a cache, s'han de distribuir d'acord amb una finalitat concreta. Per exemple, minimitzeu la latència o maximitzeu la probabilitat d'arribar a una instància de treball. L'algorisme més utilitzat és Round-robin, però n'hi ha molts altres, per exemple, el mètode ponderat (ponderada) consultes (podeu seleccionar els objectius preferits), sonar (anell) hashing (utilitzant hash coherent entre els hosts aigües amunt) o el mètode de menys sol·licitud (es dóna preferència a la instància amb menys sol·licituds).

Els equilibradors clàssics tenen altres funcions, com ara la memòria cau HTTP i la protecció DDoS, però no són gaire rellevants per al trànsit est-oest (és a dir, per al trànsit que flueix dins d'un centre de dades, aprox. traducció) (abast típic de la malla de servei). Per descomptat, no és necessari utilitzar una malla de servei per a l'equilibri de càrrega, però us permet establir i controlar polítiques d'equilibri per a cada servei des d'una capa de control centralitzada, eliminant així la necessitat d'executar i configurar equilibradors de càrrega separats a la pila de xarxa. .

5. Tall de circuit

TL;DR: Atureu el trànsit al servei problemàtic i controleu els danys en el pitjor dels casos.

Si per algun motiu el servei no pot fer front al trànsit, la malla de servei ofereix diverses opcions per resoldre aquest problema (d'altres se'n discutiran a les seccions corresponents). L'interrupció del circuit és l'opció més severa per desconnectar un servei del trànsit. Tanmateix, per si mateix no té sentit: cal un pla de còpia de seguretat. Es pot proporcionar contrapressió (contrapressió) als serveis que fan sol·licituds (no us oblideu de configurar la vostra malla de servei per a això!), o, per exemple, pintar la pàgina d'estat de vermell i redirigir els usuaris a una altra versió de la pàgina amb una "balena que cau" ("Twitter és avall”).

Les malles de servei no només us permeten definir on seguirà l'aturada i que això seguirà. En aquest cas, "quan" pot incloure qualsevol combinació de paràmetres especificats: el nombre total de sol·licituds durant un període determinat, el nombre de connexions paral·leles, sol·licituds pendents, reintents actius, etc.

Probablement no vulgueu abusar de l'interrupció del circuit, però és bo saber que teniu un pla de seguretat en cas d'emergència.

6. Autoescala

TL;DR: augmenta o disminueix el nombre d'instàncies de servei en funció dels criteris especificats.

Les malles de servei no són programadors, de manera que no ho fan dur a terme escalant-se. Tanmateix, poden proporcionar informació sobre quins planificadors basaran les seves decisions. Atès que les malles de servei tenen accés a tot el trànsit entre serveis, disposen d'una àmplia informació sobre el que està passant: quins serveis tenen problemes, quins serveis tenen una càrrega molt lleugera (es desaprofita la capacitat que s'hi assigna), etc.

Per exemple, Kubernetes escala els serveis en funció de l'ús de la memòria i la CPU dels pods (vegeu el nostre informe "Autoscaling i gestió de recursos a Kubernetes"- aprox. trad.), però si decidiu escalar en funció de qualsevol altra mètrica (en el nostre cas, relacionada amb el trànsit), necessitareu una mètrica especial. Gestió com això mostra com fer-ho amb Enviat, Istio и Prometeu, però el procés en si és força complicat. Ens agradaria que la malla de servei simplifiqui això permetent-nos simplement establir condicions com "augmentar el nombre d'instàncies de servei". auth, si el nombre de sol·licituds pendents supera el llindar en un minut."

7. Desplegaments canaris

TL;DR: prova noves funcions o versions de serveis en un subconjunt d'usuaris.

Suposem que esteu desenvolupant un producte SaaS i teniu la intenció de llançar-ne una nova versió fantàstica. Ho vas provar a la posada en escena i va funcionar molt bé. Però encara hi ha certes preocupacions sobre el seu comportament en condicions reals. En altres paraules, cal provar la nova versió amb problemes reals sense arriscar la confiança dels usuaris. Els desplegaments de Canary són excel·lents per a això. Us permeten demostrar una funció nova a un subconjunt d'usuaris. Aquest subconjunt pot estar format pels usuaris més fidels o els que treballen amb la versió gratuïta del producte, o els usuaris que han expressat el desig de ser "conillets d'índies".

Les malles de servei ho implementen ja que us permeten especificar criteris que determinen qui veurà quina versió de l'aplicació i encaminar el trànsit en conseqüència. Tanmateix, res canvia per als propis serveis. La versió 1.0 del servei creu que totes les sol·licituds provenen d'usuaris que haurien de veure'l, i la versió 1.1 creu el mateix per als seus usuaris. Mentrestant, podeu canviar el percentatge de trànsit entre la versió antiga i la nova, redirigint un nombre creixent d'usuaris a la nova si funciona de manera estable i els vostres "conillets d'índies" donen el vistiplau.

8. Desplegaments blau-verd

TL;DR: Desplegueu una funció nova fantàstica, però estigueu preparats per recuperar-ho tot immediatament.

Significat desplegaments blau-verd és desplegar un nou servei "blau", llançant-lo paral·lelament a l'antic, "verd". Si tot va bé i el nou servei funciona bé, l'antic es pot desactivar gradualment. (Ai, algun dia aquest nou servei “blau” repetirà el destí del “verd” i desapareixerà...) Els desplegaments blau-verd es diferencien dels canaris perquè la nova funció cobreix tots alhora usuaris (no part); El punt aquí és tenir un "port segur" preparat per si alguna cosa va malament.

Les malles de servei ofereixen una manera molt còmoda de provar un servei "blau" i canviar de manera instantània a un de "verd" que funcioni en cas de problemes. Sense oblidar el fet que al llarg del camí proporcionen molta informació (vegeu "Telemetria" a continuació) sobre el treball del "blau", que ajuda a entendre si està llest per al funcionament complet.

Nota. transl.: Podeu obtenir més informació sobre diferents estratègies de desplegament a Kubernetes (incloent-hi l'esmentat canari, blau/verd i altres) a aquest article.

9. Control de salut

TL;DR: feu un seguiment de quines instàncies de servei funcionen i responeu a les que ja no funcionen.

Revisió de salut (revisió de salut) ajuda a decidir si les instàncies de servei estan preparades per acceptar i processar trànsit. Per exemple, en el cas dels serveis HTTP, una comprovació de salut pot semblar una sol·licitud GET al punt final /health... Resposta 200 OK significarà que la instància és sana, qualsevol altra - que no està preparada per rebre trànsit. Les malles de servei permeten especificar tant la forma en què es comprovarà la funcionalitat com la freqüència amb què es realitzarà aquesta comprovació. Aquesta informació es pot utilitzar per a altres propòsits, per exemple, per equilibrar la càrrega i tallar circuits.

Per tant, la comprovació de salut no és un cas d'ús autònom, sinó que s'acostuma a utilitzar per aconseguir altres objectius. A més, depenent dels resultats de les comprovacions de salut, es poden requerir accions externes a altres objectius de malla de servei: per exemple, actualitzar la pàgina d'estat, crear un problema a GitHub o omplir un bitllet JIRA. I la malla de servei ofereix un mecanisme convenient per automatitzar tot això.

10. Descàrrega

TL;DR: redirigeix el trànsit en resposta a un augment temporal d'ús.

Si un determinat servei està sobrecarregat de trànsit, podeu redirigir temporalment part d'aquest trànsit a una altra ubicació (és a dir, "bocament", "transferència" (cabana) ell allà). Per exemple, a un servei de còpia de seguretat o centre de dades, o a un permanent prémer tema. Com a resultat, el servei continuarà processant algunes sol·licituds en lloc de bloquejar-se i deixar de processar-ho tot. El despreniment de càrrega és preferible a trencar el circuit, però encara no és aconsellable abusar-ne. Ajuda a prevenir errors en cascada que provoquen que els serveis aigües avall es bloquegin.

11. Paral·lelització/reglament del trànsit

TL;DR: Envieu una sol·licitud a diversos llocs alhora.

De vegades cal enviar una sol·licitud (o una selecció determinada de peticions) a diversos serveis alhora. Un exemple típic és enviar part del trànsit de producció a un servei de preparació. El servidor web de producció principal envia una sol·licitud al servei posterior products.production i només a ell. I la malla de servei copia intel·ligentment aquesta sol·licitud i l'envia a products.staging, que el servidor web ni tan sols és conscient.

Un altre cas d'ús relacionat amb la malla de serveis que es pot implementar a més de la paral·lelització del trànsit és proves de regressió. Implica enviar les mateixes peticions a diferents versions del servei i comprovar si totes les versions es comporten igual. Encara no m'he trobat amb una implementació de malla de servei amb un sistema de proves de regressió integrat com Diffy, però la idea en si sembla prometedora.

12. Aïllament

TL;DR: Trenqueu la vostra malla de servei en minixarxes.

També conegut com segmentacióL'aïllament és l'art de dividir una malla de servei en segments lògicament diferents que no saben res els uns dels altres. L'aïllament és una mica com crear xarxes privades virtuals. La diferència fonamental és que encara podeu gaudir de tots els avantatges d'una malla de servei (com el descobriment de serveis), però amb seguretat addicional. Per exemple, si un atacant és capaç de penetrar en un servei d'una subxarxa, no podrà veure quins serveis s'estan executant en altres subxarxes ni interceptar-ne el trànsit.

A més, els beneficis també poden ser organitzatius. És possible que vulgueu subxarmar els vostres serveis en funció de l'estructura de la vostra empresa i alleujar els desenvolupadors de la càrrega cognitiva d'haver de tenir en compte tota la malla del servei.

13. Sol·licitud de limitació de velocitat, reintents i temps d'espera

TL;DR: Ja no cal que inclogueu les tasques de gestió de sol·licituds més importants a la vostra base de codi.

Totes aquestes coses es podrien considerar casos d'ús separats, però vaig decidir combinar-les a causa d'una característica comuna: es fan càrrec de les tasques de gestió del cicle de vida de la sol·licitud que normalment gestionen les biblioteques d'aplicacions. Si esteu desenvolupant un servidor web a Ruby on Rails (no integrat amb una malla de servei) que fa sol·licituds als serveis de backend mitjançant gRPC, l'aplicació haurà de decidir què fer si fallen N sol·licituds. També haureu d'esbrinar la quantitat de trànsit que aquests serveis podran processar i codificar aquests paràmetres mitjançant una biblioteca especial. A més, l'aplicació haurà de decidir quan és el moment de renunciar i deixar que la sol·licitud s'esgoti (en funció del temps d'espera). I per canviar qualsevol dels paràmetres anteriors, caldrà aturar, reconfigurar i tornar a iniciar el servidor web.

Descarregar aquestes tasques a una xarxa de serveis no només significa que els desenvolupadors de serveis no hauran de pensar-hi, sinó que també es poden veure d'una manera més global. Si s'utilitza una cadena de serveis complexa, per exemple A -> B -> C -> D -> E, s'ha de tenir en compte tot el cicle de vida de la sol·licitud. Si la tasca és ampliar els temps d'espera al servei C, és lògic fer-ho tot alhora, i no en parts: actualitzant el codi de servei i esperant fins que s'accepta la sol·licitud d'extracció i el sistema CI desplega el servei actualitzat.

14. Telemetria

TL;DR: Recolliu tota la informació necessària (i no del tot) dels serveis.

La telemetria és un terme general que inclou mètriques, traça distribuïda i registres. Les malles de servei ofereixen mecanismes per recollir i processar els tres tipus de dades. Aquí és on les coses es tornen una mica borroses perquè el nombre d'opcions possibles és massa gran. Per recollir mètriques hi ha Prometeu i altres eines que es poden utilitzar per recollir registres fluentd, Loki, Vector etcètera (per exemple, ClickHouse amb el nostre casa de troncs per a K8s - aprox. trad.), per al traçat distribuït hi ha Jaeger etcètera. Cada malla de servei pot ser compatible amb algunes eines i no altres. Serà interessant veure si el projecte pot Obriu Telemetria proporcionar una certa convergència.

En aquest cas, l'avantatge de la tecnologia de malla de servei és que els contenidors sidecar poden, en principi, recollir totes les dades anteriors dels seus serveis. És a dir, tens a la teva disposició un únic sistema de recollida de telemetria i la xarxa de serveis pot processar tota aquesta informació de diverses maneres. Per exemple:

registres de cua d'un determinat servei a la CLI;
supervisar el volum de sol·licituds des del tauler de control de malla de servei;
recollir rastres distribuïts i enviar-los a un sistema com Jaeger.

Atenció, judici subjectiu: En termes generals, la telemetria és una àrea en la qual no és desitjable una forta interferència de la malla de servei. Recollir informació bàsica i fer un seguiment sobre la marxa d'algunes mètriques d'or com la taxa d'èxit de la sol·licitud i la latència està bé, però esperem que no veiem que sorgeixen piles de Frankenstein que intenten substituir sistemes especialitzats, alguns dels quals ja s'han demostrat i estan ben estudiats. .

15. Auditoria

TL;DR: Els que obliden les lliçons de la història estan condemnats a repetir-les.

L'auditoria és l'art d'observar esdeveniments importants en un sistema. En el cas d'una malla de servei, això podria significar fer un seguiment de qui va fer sol·licituds a punts finals específics per a serveis específics o quantes vegades s'ha produït algun esdeveniment relacionat amb la seguretat durant l'últim mes.

És evident que l'auditoria està molt relacionada amb la telemetria. La diferència és que la telemetria sol associar-se a coses com la productivitat i la integritat tècnica, mentre que l'auditoria pot relacionar-se amb qüestions legals i altres que van més enllà de l'esfera estrictament tècnica (per exemple, el compliment del GDPR, el Reglament general de la UE sobre protecció de dades).

16. Visualització

TL;DR: Visca React.js: una font inesgotable d'interfícies de luxe.

Potser hi ha un terme millor, però no el conec. Simplement em refereixo a una representació gràfica d'una malla de servei o d'alguns dels seus components. Aquestes visualitzacions poden incloure indicadors com ara latències mitjanes, informació de configuració de sidecar, resultats de control de salut i alertes.

Treballar en un entorn orientat al servei implica una càrrega cognitiva molt més elevada en comparació amb Sa Majestat el Monòlit. Per tant, la pressió cognitiva s'hauria de reduir a tota costa. Una interfície gràfica senzilla per a una malla de servei amb la possibilitat de fer clic en un botó i obtenir el resultat desitjat podria ser determinant per al creixement de la popularitat d'aquesta tecnologia.

No estaven inclosos a la llista

Originalment tenia la intenció d'incloure alguns casos d'ús més a la llista, però després vaig decidir no fer-ho. Aquí tens, juntament amb els motius de la meva decisió:

Centre de dades múltiples. Al meu entendre, no es tracta tant d'un cas d'ús com d'una àrea estreta i específica d'aplicació de malles de servei o d'algun conjunt de funcions com el descobriment de serveis.
Entrada i sortida. Aquesta és una àrea relacionada, però m'he limitat (potser artificialment) al cas d'ús del "trànsit est-oest". L'entrada i la sortida mereixen un article a part.

Conclusió

Això és tot per ara! De nou, aquesta llista és molt arbitrària i probablement incompleta. Si creieu que m'he perdut alguna cosa o m'he trobat malament, poseu-vos en contacte amb mi a Twitter (@luckerkins). Si us plau, respecteu les normes de decència.

PS del traductor

La il·lustració del títol de l'article es basa en una imatge de l'article "Què és una malla de servei (i quan utilitzar-la)?"(per Gregory MacKinnon). Mostra com algunes funcionalitats de les aplicacions (en verd) s'han mogut a una malla de servei que proporciona interconnexions entre elles (en blau).

Llegeix també al nostre blog:

Font: www.habr.com