Service Mesh is 'n bekende argitektoniese patroon vir die integrasie van mikrodienste en migreer na wolkinfrastruktuur. Vandag in die wolkhouerwêreld is dit nogal moeilik om daarsonder klaar te kom. Verskeie oopbron-diensnetwerkimplementerings is reeds op die mark beskikbaar, maar hul funksionaliteit, betroubaarheid en sekuriteit is nie altyd voldoende nie, veral as dit kom by die vereistes van groot finansiële maatskappye regoor die land. Dit is hoekom ons by Sbertech besluit het om Service Mesh aan te pas en wil praat oor wat cool is van Service Mesh, wat nie so cool is nie, en wat ons daaromtrent gaan doen.
Die gewildheid van die Service Mesh-patroon neem toe met die gewildheid van wolktegnologieë. Dit is 'n toegewyde infrastruktuurlaag wat die interaksie tussen verskillende netwerkdienste vereenvoudig. Moderne wolktoepassings bestaan uit honderde of selfs duisende sulke dienste, waarvan elkeen duisende kopieë kan hê.
Die interaksie tussen en bestuur van hierdie dienste is 'n sleuteltaak van die Service Mesh. Trouens, dit is 'n netwerkmodel van baie gevolmagtigdes, wat sentraal bestuur word en 'n stel baie nuttige funksies verrig.
Op die instaanbedienervlak (datavlak):
- Toewysing en verspreiding van roete- en verkeersbalanseringsbeleide
- Verspreiding van sleutels, sertifikate, tokens
- Versameling van telemetrie, generering van moniteringsmetrieke
- Integrasie met sekuriteit en monitering infrastruktuur
Op die beheervlakvlak:
- Toepassing van roete- en verkeersbalanseringsbeleide
- Bestuur herproberings en uitteltyd, opsporing van "dooie" nodusse (kringbreek), bestuur inspuitfoute en verseker diensveerkragtigheid deur ander meganismes
- Oproepstawing/magtiging
- Verlaag maatstawwe (waarneembaarheid)
Die reeks gebruikers wat belangstel in die ontwikkeling van hierdie tegnologie is baie wyd - van klein beginondernemings tot groot internetkorporasies, byvoorbeeld PayPal.
Hoekom is Service Mesh nodig in die korporatiewe sektor?
Daar is baie duidelike voordele verbonde aan die gebruik van 'n Service Mesh. Eerstens is dit eenvoudig gerieflik vir ontwikkelaars: om kode te skryf 'n tegnologieplatform verskyn, wat integrasie in die wolkinfrastruktuur aansienlik vergemaklik as gevolg van die feit dat die vervoerlaag heeltemal geïsoleer is van toepassingslogika.
Daarbenewens, Service Mesh vereenvoudig die verhouding tussen verskaffers en verbruikers. Vandag is dit baie makliker vir API-verskaffers en verbruikers om op hul eie oor koppelvlakke en kontrakte ooreen te kom, sonder om 'n spesiale integrasie-tussenganger en arbiter - die ondernemingsdiensbus - te betrek. Hierdie benadering beïnvloed twee aanwysers aansienlik. Die spoed om nuwe funksionaliteit na die mark te bring (tyd-tot-mark) neem toe, maar terselfdertyd neem die koste van die oplossing toe, aangesien integrasie onafhanklik gedoen moet word. Die gebruik van Service Mesh deur besigheidsfunksionaliteitontwikkelingspanne help om 'n balans hier te handhaaf. As gevolg hiervan kan API-verskaffers uitsluitlik op die toepassingskomponent van hul diens fokus en dit bloot in die Service Mesh publiseer - die API sal onmiddellik vir alle kliënte beskikbaar word, en die kwaliteit van integrasie sal produksiegereed wees en sal nie 'n enkele reël addisionele kode.
Die volgende voordeel is dit die ontwikkelaar, wat Service Mesh gebruik, fokus uitsluitlik op besigheidsfunksionaliteit — op die produk eerder as die tegnologiese komponent van sy diens. U hoef byvoorbeeld nie meer daaraan te dink dat in 'n situasie waar 'n diens oor die netwerk geroep word, iewers 'n verbindingsfout kan voorkom nie. Boonop help Service Mesh om die verkeer tussen kopieë van dieselfde diens te balanseer: as een van die kopieë "sterf", sal die stelsel alle verkeer na die oorblywende lewendige kopieë oorskakel.
Diens Mesh - dit is 'n goeie basis vir die skep van verspreide toepassings, wat die besonderhede van die verskaffing van oproepe na sy dienste beide intern en ekstern vir die kliënt verberg. Alle toepassings wat Service Mesh gebruik, word op vervoervlak sowel van die netwerk as van mekaar geïsoleer: daar is geen kommunikasie tussen hulle nie. In hierdie geval kry die ontwikkelaar volle beheer oor sy dienste.
Daar moet kennis geneem word dat Die opdatering van verspreide toepassings in 'n diensnetwerkomgewing word makliker. Byvoorbeeld, 'n blou/groen ontplooiing, waarin twee toepassingsomgewings beskikbaar is vir installasie, waarvan een nie opgedateer is nie en in bystandmodus is. Terugrol na die vorige weergawe in die geval van 'n onsuksesvolle vrystelling word uitgevoer deur 'n spesiale router, die rol waarvan Service Mesh goed hanteer. Om die nuwe weergawe te toets, kan jy gebruik kanarie vrylating - skakel slegs 10% van die verkeer of versoeke van 'n loodsgroep kliënte oor na die nuwe weergawe. Die hoofverkeer gaan na die ou weergawe, niks breek nie.
Ook Service Mesh gee ons intydse SLA-beheer. Die verspreide volmagstelsel sal nie toelaat dat die diens misluk wanneer een van die kliënte die kwota wat daaraan toegeken is, oorskry nie. As API-deurset beperk is, sal niemand dit met 'n groot aantal transaksies kan oorweldig nie: die Service Mesh staan voor die diens en laat nie onnodige verkeer toe nie. Dit sal eenvoudig terugveg in die integrasielaag, en die dienste self sal aanhou werk sonder om dit raak te sien.
As 'n maatskappy koste vir die ontwikkeling van integrasie-oplossings wil verminder, help Service Mesh ook: U kan van kommersiële produkte na die oopbronweergawe daarvan oorskakel. Ons Enterprise Service Mesh is gebaseer op die oopbron weergawe van Service Mesh.
Nog 'n voordeel - beskikbaarheid van 'n enkele volwaardige stel integrasiedienste. Omdat alle integrasie deur hierdie middelware gebou word, kan ons al die integrasieverkeer en verbindings tussen toepassings bestuur wat die sakekern van die maatskappy vorm. Dit is baie gemaklik.
En uiteindelik Service Mesh moedig 'n maatskappy aan om na 'n dinamiese infrastruktuur te beweeg. Nou kyk baie na containerisering. Om 'n monoliet in mikrodienste te sny, dit alles pragtig te implementeer - die onderwerp is aan die toeneem. Maar wanneer jy probeer om 'n stelsel wat vir baie jare in produksie is na 'n nuwe platform oor te dra, kom jy dadelik op 'n aantal probleme teë: om dit alles in houers te druk en dit op die platform te ontplooi is nie maklik nie. En die implementering, sinchronisasie en interaksie van hierdie verspreide komponente is nog 'n baie komplekse onderwerp. Hoe sal hulle met mekaar kommunikeer? Sal daar deurlopende mislukkings wees? Service Mesh laat jou toe om sommige van hierdie probleme op te los en migrasie van die ou argitektuur na die nuwe een te vergemaklik as gevolg van die feit dat jy van die netwerkuitruillogika kan vergeet.
Hoekom het jy Service Mesh-aanpassing nodig?
In ons maatskappy bestaan honderde stelsels en modules saam, en die looptyd is baie gelaai. Dus is 'n eenvoudige patroon van een stelsel wat 'n ander oproep en 'n reaksie ontvang nie genoeg nie, want in produksie wil ons meer hê. Wat het jy nog nodig van 'n ondernemingsdiensnetwerk?
Gebeurtenisverwerkingsdiens
Kom ons verbeel ons dat ons intydse gebeurtenisverwerking moet maak – 'n stelsel wat die kliënt se optrede intyds ontleed en dadelik vir hom 'n relevante aanbod kan maak. Om soortgelyke funksionaliteit te implementeer, gebruik argitektoniese patroon genoem gebeurtenis-gedrewe argitektuur (EDA). Nie een van die huidige Diensnetwerke ondersteun inheems sulke patrone nie, maar dit is baie belangrik, veral vir 'n bank!
Dit is nogal vreemd dat Remote Procedure Call (RPC) deur alle weergawes van Service Mesh ondersteun word, maar hulle is nie vriendelik met EDA nie. Omdat Service Mesh 'n soort moderne verspreide integrasie is, en EDA 'n baie relevante argitektoniese patroon is wat jou toelaat om unieke dinge te doen in terme van kliëntervaring.
Ons Enterprise Service Mesh behoort hierdie probleem op te los. Daarbenewens wil ons daarin die implementering van gewaarborgde aflewering, streaming en komplekse gebeurtenisverwerking met behulp van 'n verskeidenheid filters en sjablone sien.
Lêeroordragdiens
Benewens EDA, sal dit lekker wees om lêers te kan oordra: op 'n Enterprise-skaal is baie dikwels slegs lêerintegrasie moontlik. In die besonder word die ETL (Extract, Transform, Load) argitektoniese patroon gebruik. Daarin ruil almal as 'n reël uitsluitlik lêers uit: groot data word gebruik, wat onprakties is om afsonderlike versoeke in te stoot. Die vermoë om lêeroordragte in die Enterprise Service Mesh te ondersteun, gee jou die buigsaamheid wat jou besigheid benodig.
Orkestrasie diens
Groot organisasies het byna altyd verskillende spanne wat verskillende produkte maak. Byvoorbeeld, in 'n bank werk sommige spanne met deposito's, terwyl ander met leningsprodukte werk, en daar is nogal baie sulke gevalle. Dit is verskillende mense, verskillende spanne wat hul produkte maak, hul API's ontwikkel en dit aan ander verskaf. En baie dikwels is daar 'n behoefte om hierdie dienste saam te stel, sowel as om komplekse logika te implementeer om 'n stel API's opeenvolgend op te roep. Om hierdie probleem op te los, benodig jy 'n oplossing in die integrasielaag wat al hierdie saamgestelde logika sal vereenvoudig (verskeie API's roep, die versoekroete beskryf, ens.). Dit is die orkestrasiediens in die Enterprise Service Mesh.
KI en ML
Wanneer mikrodienste deur 'n enkele integrasielaag kommunikeer, weet die Service Mesh natuurlik alles van elke diens se oproepe. Ons versamel telemetrie: wie het vir wie gebel, wanneer, hoe lank, hoeveel keer, ensovoorts. Wanneer daar honderdduisende van hierdie dienste is, en biljoene oproepe, dan versamel dit alles en vorm Big Data. Hierdie data kan ontleed word deur gebruik te maak van KI, masjienleer, ens., en dan kan 'n paar nuttige dinge gedoen word op grond van die ontledingsresultate. Dit sal gepas wees om ten minste gedeeltelik die beheer van al hierdie netwerkverkeer en toepassingsoproepe wat in die Service Mesh geïntegreer is, aan kunsmatige intelligensie oor te dra.
API-poortdiens
Tipies het 'n Service Mesh gevolmagtigdes en dienste wat binne 'n vertroude omtrek met mekaar praat. Maar daar is ook eksterne teenpartye. Die vereistes vir API's wat aan hierdie groep verbruikers blootgestel word, is baie strenger. Ons verdeel hierdie taak in twee hoofdele.
- sekuriteit. Kwessies wat verband hou met ddos, kwesbaarheid van protokolle, toepassings, bedryfstelsels, ensovoorts.
- Skaal. Wanneer die aantal API's wat aan kliënte bedien moet word, duisende of selfs honderdduisende beloop, is daar 'n behoefte aan 'n soort bestuursinstrument vir hierdie stel API's. U moet die API voortdurend monitor: of hulle werk of nie, wat hul status is, watter verkeer vloei, watter statistieke, ens. 'n API-poort moet hierdie taak hanteer terwyl die hele proses hanteerbaar en veilig is. Danksy hierdie komponent leer Enterprise Service Mesh om beide interne en eksterne API's maklik te publiseer.
Ondersteuningsdiens vir spesifieke protokolle en dataformate (AS-poort)
Tans kan die meeste Service Mesh-oplossings slegs inheems werk met HTTP- en HTTP2-verkeer of in 'n verminderde modus op die TCP/IP-vlak. Die Enterprise Service Mesh kom na vore met baie ander baie spesifieke data-oordragprotokolle. Sommige stelsels kan boodskapmakelaars gebruik, ander is op die databasisvlak geïntegreer. As die maatskappy SAP het, kan dit ook sy eie integrasiestelsel gebruik. Boonop werk dit alles en is dit 'n belangrike deel van die besigheid.
Jy kan nie net sê: "Kom ons laat vaar nalatenskap en maak nuwe stelsels wat Service Mesh kan gebruik nie." Om al die ou stelsels met die nuwes te verbind (op 'n mikrodiensargitektuur), sal stelsels wat Service Mesh kan gebruik 'n soort adapter, tussenganger, poort nodig hê. Stem saam, dit sal lekker wees as dit saam met die diens in 'n boks kom. Die AC-poort kan enige integrasie-opsie ondersteun. Stel jou net voor, jy installeer net Enterprise Service Mesh en dit is gereed om met al die protokolle te kommunikeer wat jy nodig het. Hierdie benadering is vir ons baie belangrik.
Dit is ongeveer hoe ons die korporatiewe weergawe van Service Mesh (Enterprise Service Mesh) voorstel. Die beskryfde aanpassing los die meeste van die probleme op wat ontstaan wanneer jy probeer om klaargemaakte oopbronweergawes van die integrasieplatform te gebruik. Service Mesh-argitektuur, wat net 'n paar jaar gelede bekendgestel is, gaan voort om te ontwikkel, en ons is opgewonde om te kan bydra tot die ontwikkeling daarvan. Ons hoop dat ons ervaring vir jou nuttig sal wees.
Bron: will.com