Per què estem fent Enterprise Service Mesh?

Service Mesh és un patró arquitectònic conegut per integrar microserveis i migrar a la infraestructura del núvol. Avui al món dels contenidors en núvols és bastant difícil prescindir-ne. Diverses implementacions de malla de serveis de codi obert ja estan disponibles al mercat, però la seva funcionalitat, fiabilitat i seguretat no sempre són suficients, especialment quan es tracta dels requisits de les grans empreses financeres d'arreu del país. És per això que a Sbertech hem decidit personalitzar Service Mesh i volem parlar del que és interessant de Service Mesh, del que no ho és i del que farem al respecte.

Per què estem fent Enterprise Service Mesh?

La popularitat del patró Service Mesh està creixent amb la popularitat de les tecnologies al núvol. És una capa d'infraestructura dedicada que simplifica la interacció entre diferents serveis de xarxa. Les aplicacions modernes al núvol consisteixen en centenars o fins i tot milers d'aquests serveis, cadascun dels quals pot tenir milers de còpies.

Per què estem fent Enterprise Service Mesh?

La interacció i la gestió d'aquests serveis és una tasca clau del Service Mesh. De fet, es tracta d'un model de xarxa de molts servidors intermediaris, gestionat de manera centralitzada i que realitza un conjunt de funcions molt útils.

A nivell de proxy (pla de dades):

  • Assignació i distribució de polítiques d'encaminament i equilibri de trànsit
  • Distribució de claus, certificats, fitxes
  • Recollida de telemetria, generació de mètriques de seguiment
  • Integració amb la infraestructura de seguretat i monitorització

A nivell del pla de control:

  • Aplicació de polítiques d'encaminament i equilibri de trànsit
  • Gestió de reintents i temps d'espera, detecció de nodes "morts" (taltura de circuit), gestió de fallades d'injecció i garantia de la resiliència del servei mitjançant altres mecanismes
  • Autenticació/autorització de trucades
  • Eliminació de mètriques (observabilitat)

El ventall d'usuaris interessats en el desenvolupament d'aquesta tecnologia és molt ampli: des de petites startups fins a grans corporacions d'Internet, per exemple, PayPal.

Per què es necessita Service Mesh al sector corporatiu?

Hi ha molts avantatges clars d'utilitzar una malla de servei. En primer lloc, és senzillament convenient per als desenvolupadors: per escriure codi apareix una plataforma tecnològica, que simplifica significativament la integració a la infraestructura del núvol a causa del fet que la capa de transport està completament aïllada de la lògica de l'aplicació.

A més, Service Mesh simplifica la relació entre proveïdors i consumidors. Avui en dia, és molt més fàcil per als proveïdors i consumidors d'API acordar interfícies i contractes pel seu compte, sense implicar un intermediari i àrbitre d'integració especial: el bus de serveis empresarials. Aquest enfocament afecta de manera significativa dos indicadors. La velocitat de portar noves funcionalitats al mercat (time-to-market) augmenta, però al mateix temps augmenta el cost de la solució, ja que la integració s'ha de fer de manera independent. L'ús de Service Mesh per part dels equips de desenvolupament de funcionalitats empresarials ajuda a mantenir un equilibri aquí. Com a resultat, els proveïdors d'API poden centrar-se exclusivament en el component d'aplicació del seu servei i, simplement, publicar-lo a Service Mesh; l'API estarà immediatament disponible per a tots els clients i la qualitat de la integració estarà preparada per a la producció i no requerirà ni una sola. línia de codi addicional.

El següent avantatge és això el desenvolupador, utilitzant Service Mesh, se centra únicament en la funcionalitat empresarial — sobre el producte més que el component tecnològic del seu servei. Per exemple, ja no haureu de pensar en el fet que en una situació en què es crida un servei a través de la xarxa, es pot produir un error de connexió en algun lloc. A més, Service Mesh ajuda a equilibrar el trànsit entre còpies del mateix servei: si una de les còpies "mor", el sistema canviarà tot el trànsit a les còpies en directe restants.

Malla de servei - aquesta és una bona base per crear aplicacions distribuïdes, que amaga al client les dades de la prestació de trucades als seus serveis tant internament com externament. Totes les aplicacions que utilitzen Service Mesh estan aïllades a nivell de transport tant de la xarxa com entre elles: no hi ha comunicació entre elles. En aquest cas, el desenvolupador rep el control total dels seus serveis.

Cal tenir en compte que L'actualització d'aplicacions distribuïdes en un entorn de malla de servei es fa més fàcil. Per exemple, un desplegament blau/verd, en el qual hi ha dos entorns d'aplicació disponibles per a la instal·lació, un dels quals no està actualitzat i està en mode d'espera. El retorn a la versió anterior en cas d'un llançament sense èxit es realitza mitjançant un encaminador especial, el paper del qual Service Mesh s'enfronta bé.. Per provar la nova versió, podeu utilitzar llançament canari — Canvieu a la nova versió només el 10% del trànsit o de les sol·licituds d'un grup pilot de clients. El trànsit principal va a la versió antiga, no es trenca res.

També Service Mesh ens ofereix un control de SLA en temps real. El sistema de proxy distribuït no permetrà que el servei falli quan un dels clients superi la quota assignada. Si el rendiment de l'API és limitat, ningú no podrà aclaparar-lo amb un gran nombre de transaccions: el Service Mesh es troba davant del servei i no permet trànsit innecessari. Simplement lluitarà a la capa d'integració i els mateixos serveis continuaran funcionant sense adonar-se'n.

Si una empresa vol reduir costos per al desenvolupament de solucions d'integració, Service Mesh també ajuda a: Podeu canviar a la seva versió de codi obert des de productes comercials. La nostra Enterprise Service Mesh es basa en la versió de codi obert de Service Mesh.

Un altre avantatge - disponibilitat d'un únic conjunt complet de serveis d'integració. Com que tota la integració es construeix a través d'aquest programari intermedi, podem gestionar tot el trànsit d'integració i les connexions entre les aplicacions que formen el nucli de negoci de l'empresa. És molt còmode.

I finalment Service Mesh anima una empresa a passar a una infraestructura dinàmica. Ara molts estan mirant cap a la contenidorització. Tallar un monòlit en microserveis, implementar tot això de manera meravellosa: el tema va en augment. Però quan intenteu transferir un sistema que porta molts anys en producció a una plataforma nova, immediatament et trobes amb una sèrie de problemes: empènyer-ho tot als contenidors i desplegar-lo a la plataforma no és fàcil. I la implementació, sincronització i interacció d'aquests components distribuïts és un altre tema molt complex. Com es comunicaran entre ells? Hi haurà fallades en cascada? Service Mesh us permet resoldre alguns d'aquests problemes i facilitar la migració de l'arquitectura antiga a la nova a causa del fet que us podeu oblidar de la lògica d'intercanvi de xarxa.

Per què necessiteu la personalització de Service Mesh?

A la nostra empresa conviuen centenars de sistemes i mòduls, i el temps d'execució està molt carregat. Per tant, un simple patró d'un sistema trucant a un altre i rebent una resposta no és suficient, perquè en producció en volem més. Què més necessiteu d'una xarxa de serveis empresarials?

Per què estem fent Enterprise Service Mesh?

Servei de processament d'esdeveniments

Imaginem que hem de fer un processament d'esdeveniments en temps real: un sistema que analitza les accions del client en temps real i li pugui fer immediatament una oferta rellevant. Per implementar una funcionalitat similar, utilitzeu patró arquitectònic anomenat arquitectura impulsada per esdeveniments (EDA). Cap de les malles de servei actuals admet de forma nativa aquests patrons, però això és molt important, especialment per a un banc.

És força estrany que la trucada de procediment remot (RPC) sigui compatible amb totes les versions de Service Mesh, però no són amigables amb EDA. Perquè Service Mesh és una mena d'integració distribuïda moderna i EDA és un patró arquitectònic molt rellevant que permet fer coses úniques pel que fa a l'experiència del client.

La nostra Enterprise Service Mesh hauria de resoldre aquest problema. A més, volem veure en ell la implementació de lliurament garantit, streaming i processament d'esdeveniments complexos mitjançant una varietat de filtres i plantilles.

Servei de transferència d'arxius

A més d'EDA, estaria bé poder transferir fitxers: a escala empresarial, molt sovint només és possible la integració de fitxers. En particular, s'utilitza el patró arquitectònic ETL (Extract, Transform, Load). En ell, per regla general, tothom intercanvia fitxers exclusivament: s'utilitzen grans dades, cosa que no és pràctic per enviar sol·licituds separades. La capacitat de donar suport natiu a les transferències de fitxers a Enterprise Service Mesh us ofereix la flexibilitat que necessita el vostre negoci.

Servei d'orquestració

Les grans organitzacions gairebé sempre tenen equips diferents que fan productes diferents. Per exemple, en un banc, alguns equips treballen amb dipòsits, mentre que altres treballen amb productes de préstec, i n'hi ha bastants. Es tracta de persones diferents, equips diferents que fabriquen els seus productes, desenvolupen les seves API i els proporcionen als altres. I molt sovint hi ha la necessitat de compondre aquests serveis, així com d'implementar una lògica complexa per trucar seqüencialment a un conjunt d'API. Per resoldre aquest problema, necessiteu una solució a la capa d'integració que simplifiqui tota aquesta lògica composta (cridant a diverses API, descrivint la ruta de la sol·licitud, etc.). Aquest és el servei d'orquestració a Enterprise Service Mesh.

IA i ML

Quan els microserveis es comuniquen mitjançant una única capa d'integració, el Service Mesh ho sap tot sobre les trucades de cada servei. Recollim la telemetria: qui va trucar a qui, quan, quant de temps, quantes vegades, etc. Quan hi ha centenars de milers d'aquests serveis i milers de milions de trucades, tot això s'acumula i forma Big Data. Aquestes dades es poden analitzar mitjançant IA, aprenentatge automàtic, etc., i després es poden fer algunes coses útils en funció dels resultats de l'anàlisi. Seria adequat cedir almenys parcialment el control de tot aquest trànsit de xarxa i les trucades d'aplicacions integrades al Service Mesh a la intel·ligència artificial.

Servei de passarel·la API

Normalment, una malla de servei té servidors intermediaris i serveis que es comuniquen entre ells dins d'un perímetre de confiança. Però també hi ha contraparts externes. Els requisits per a les API exposades a aquest grup de consumidors són molt més severs. Dividim aquesta tasca en dues parts principals.

  • Безопасность. Problemes relacionats amb ddos, vulnerabilitat de protocols, aplicacions, sistemes operatius, etc.
  • Escala. Quan el nombre d'API que s'han de servir als clients arriba als milers o fins i tot centenars de milers, hi ha una necessitat d'algun tipus d'eina de gestió per a aquest conjunt d'API. Cal controlar constantment l'API: si estan funcionant o no, quin és el seu estat, quin trànsit flueix, quines estadístiques, etc. Una passarel·la API hauria de gestionar aquesta tasca alhora que fa que tot el procés sigui manejable i segur. Gràcies a aquest component, Enterprise Service Mesh aprèn a publicar fàcilment API tant internes com externes.

Servei de suport per a protocols i formats de dades específics (passarela AS)

Actualment, la majoria de solucions de Service Mesh només poden funcionar de manera nativa amb trànsit HTTP i HTTP2 o en mode reduït a nivell TCP/IP. El Enterprise Service Mesh està sorgint amb molts altres protocols de transferència de dades molt específics. Alguns sistemes poden utilitzar intermediaris de missatges, d'altres estan integrats a nivell de base de dades. Si l'empresa té SAP, també pot utilitzar el seu propi sistema d'integració. A més, tot això funciona i és una part important del negoci.

No podeu dir simplement: "Abandonem el llegat i creem sistemes nous que puguin utilitzar Service Mesh". Per connectar tots els sistemes antics amb els nous (en una arquitectura de microservei), els sistemes que puguin utilitzar Service Mesh necessitaran algun tipus d'adaptador, intermediari, passarel·la. D'acord, estaria bé que vingués en una caixa juntament amb el servei. La passarel·la AC pot suportar qualsevol opció d'integració. Imagineu-vos que només instal·leu Enterprise Service Mesh i ja està llest per interactuar amb tots els protocols que necessiteu. Aquest enfocament és molt important per a nosaltres.

Així és aproximadament com imaginem la versió corporativa de Service Mesh (Enterprise Service Mesh). La personalització descrita resol la majoria dels problemes que sorgeixen quan s'intenta utilitzar versions ja fetes de codi obert de la plataforma d'integració. Presentada fa només un parell d'anys, l'arquitectura Service Mesh continua evolucionant i estem encantats de poder contribuir al seu desenvolupament. Esperem que la nostra experiència us sigui útil.

Font: www.habr.com

Afegeix comentari