Service Mesh on tunnettu arkkitehtuurimalli mikropalvelujen integroimiseen ja pilviinfrastruktuuriin siirtymiseen. Nykyään pilvikonttimaailmassa on melko vaikeaa olla ilman sitä. Markkinoilla on jo saatavilla useita avoimen lähdekoodin palveluverkkototeutuksia, mutta niiden toimivuus, luotettavuus ja turvallisuus eivät aina ole riittävät, etenkään kun on kyse suurten finanssiyritysten vaatimuksista eri puolilla maata. Siksi me Sbertechillä päätimme mukauttaa Service Meshiä ja haluamme keskustella siitä, mikä Service Meshissä on siistiä, mikä ei ole niin siistiä ja mitä aiomme tehdä asialle.
Service Mesh -mallin suosio kasvaa pilviteknologioiden suosion myötä. Se on omistettu infrastruktuurikerros, joka yksinkertaistaa eri verkkopalvelujen välistä vuorovaikutusta. Nykyaikaiset pilvisovellukset koostuvat sadoista tai jopa tuhansista tällaisista palveluista, joista jokaisella voi olla tuhansia kopioita.
Näiden palveluiden välinen vuorovaikutus ja hallinta on Service Meshin keskeinen tehtävä. Itse asiassa tämä on monien välityspalvelinten verkkomalli, jota hallitaan keskitetysti ja joka suorittaa joukon erittäin hyödyllisiä toimintoja.
Välityspalvelintasolla (tietotaso):
- Reititys- ja liikenteen tasapainotuskäytäntöjen määrittäminen ja jakaminen
- Avainten, todistusten, rahakkeiden jakelu
- Telemetrian kerääminen, seurantamittareiden generointi
- Integrointi turvallisuus- ja valvontainfrastruktuuriin
Ohjaustason tasolla:
- Reititys- ja liikenteen tasapainotuskäytäntöjen soveltaminen
- Uudelleenyritysten ja aikakatkaisujen hallinta, "kuolleiden" solmujen havaitseminen (piirikatko), vikojen lisääminen ja palvelun kestävyyden varmistaminen muiden mekanismien avulla
- Puhelun todennus/valtuutus
- Mittareiden pudottaminen (havaittavuus)
Tämän tekniikan kehityksestä kiinnostuneiden käyttäjien joukko on erittäin laaja - pienistä startupeista suuriin Internet-yrityksiin, esimerkiksi PayPaliin.
Miksi Service Meshiä tarvitaan yrityssektorilla?
Service Meshin käyttämisessä on monia selkeitä etuja. Ensinnäkin se on yksinkertaisesti kätevä kehittäjille: koodin kirjoittamiseen teknologia-alusta tulee näkyviin, mikä yksinkertaistaa merkittävästi integrointia pilviinfrastruktuuriin, koska kuljetuskerros on täysin eristetty sovelluslogiikasta.
Lisäksi, Service Mesh yksinkertaistaa toimittajien ja kuluttajien välistä suhdetta. Nykyään API-palveluntarjoajien ja kuluttajien on paljon helpompaa sopia rajapinnoista ja sopimuksista itse ilman erityistä integraatiovälittäjää ja -välittäjää - yrityksen palveluväylää. Tämä lähestymistapa vaikuttaa merkittävästi kahteen indikaattoriin. Uuden toiminnallisuuden markkinoille tuomisen nopeus (time-to-market) kasvaa, mutta samalla ratkaisun hinta nousee, koska integrointi on tehtävä itsenäisesti. Liiketoiminnan toiminnallisuuden kehitystiimien Service Meshin käyttö auttaa säilyttämään tasapainon tässä. Tämän seurauksena API-palveluntarjoajat voivat keskittyä yksinomaan palvelunsa sovelluskomponenttiin ja yksinkertaisesti julkaista sen Service Meshissä - API tulee välittömästi kaikkien asiakkaiden saataville, ja integroinnin laatu on tuotantovalmiina eikä vaadi yhtäkään rivi lisäkoodia.
Seuraava etu on se Palveluverkkoa käyttävä kehittäjä keskittyy yksinomaan liiketoiminnan toimivuuteen — tuotteesta eikä sen palvelun teknologisesta osasta. Enää ei esimerkiksi tarvitse ajatella sitä, että tilanteessa, jossa palvelua kutsutaan verkon kautta, voi jossain ilmetä yhteyshäiriö. Lisäksi Service Mesh auttaa tasapainottamaan liikennettä saman palvelun kopioiden välillä: jos yksi kopioista "kuolee", järjestelmä siirtää kaiken liikenteen jäljellä oleviin live-kopioihin.
Palveluverkko - tämä on hyvä perusta hajautettujen sovellusten luomiselle, joka piilottaa asiakkaalta yksityiskohdat puheluiden soittamisesta palveluihinsa sekä sisäisesti että ulkoisesti. Kaikki Service Meshiä käyttävät sovellukset on eristetty siirtotasolla sekä verkosta että toisistaan: niiden välillä ei ole yhteyttä. Tässä tapauksessa kehittäjä saa täyden hallinnan palveluistaan.
On huomattava, että Hajautettujen sovellusten päivittäminen palveluverkkoympäristössä helpottuu. Esimerkiksi sininen/vihreä käyttöönotto, jossa asennettavissa on kaksi sovellusympäristöä, joista toinen ei ole päivitetty ja on valmiustilassa. Epäonnistuneen julkaisun tapauksessa paluu edelliseen versioon suorittaa erityinen reititin, jonka rooli Service Mesh selviää hyvin. Voit testata uutta versiota käyttämällä kanarian vapauttaminen — Vaihda uuteen versioon vain 10 % liikenteestä tai pilottiasiakasryhmän pyynnöistä. Pääliikenne menee vanhaan versioon, mikään ei katkea.
Myös Service Mesh antaa meille reaaliaikaisen SLA-hallinnan. Hajautettu välityspalvelinjärjestelmä ei anna palvelun epäonnistua, jos yksi asiakkaista ylittää sille määritetyn kiintiön. Jos API-läpäisykyky on rajoitettu, kukaan ei voi ylittää sitä suurella määrällä tapahtumia: Service Mesh seisoo palvelun edessä eikä salli tarpeetonta liikennettä. Se yksinkertaisesti taistelee takaisin integraatiokerroksessa, ja itse palvelut jatkavat toimintaansa huomaamattaan.
Jos yritys haluaa alentaa integraatioratkaisujen kehittämiskustannuksia, Service Mesh auttaa myös: Voit vaihtaa sen avoimeen lähdekoodiin kaupallisista tuotteista. Enterprise Service Mesh -palvelumme perustuu Service Meshin avoimen lähdekoodin versioon.
Toinen etu - yhden täysimittaisen integraatiopalvelujen saatavuuden. Koska kaikki integraatio on rakennettu tämän väliohjelmiston kautta, voimme hallita kaikkea integraatioliikennettä ja yhteyksiä sovellusten välillä, jotka muodostavat yrityksen liiketoimintaytimen. Se on erittäin mukava.
Ja lopuksi Service Mesh kannustaa yritystä siirtymään dynaamiseen infrastruktuuriin. Nyt monet etsivät konttikuljetusta. Monoliitin leikkaaminen mikropalveluiksi, toteuttaa kaikki tämä kauniisti - aihe on nousussa. Mutta kun yrität siirtää monta vuotta tuotannossa olleen järjestelmän uudelle alustalle, kohtaat välittömästi useita ongelmia: kaiken työntäminen kontteihin ja käyttöönotto alustalle ei ole helppoa. Ja näiden hajautettujen komponenttien toteutus, synkronointi ja vuorovaikutus on toinen hyvin monimutkainen aihe. Miten he kommunikoivat keskenään? Tuleeko peräkkäisiä vikoja? Service Meshin avulla voit ratkaista osan näistä ongelmista ja helpottaa siirtymistä vanhasta arkkitehtuurista uuteen, koska voit unohtaa verkon vaihtologiikan.
Miksi tarvitset Service Mesh -räätälöintiä?
Yrityksessämme on satoja järjestelmiä ja moduuleja rinnakkain, ja ajonaika on erittäin kuormitettu. Joten pelkkä malli, jossa järjestelmä soittaa toiselle ja saa vastauksen, ei riitä, koska tuotannossa haluamme enemmän. Mitä muuta tarvitset yrityspalveluverkosta?
Tapahtumakäsittelypalvelu
Kuvitellaan, että meidän on tehtävä reaaliaikainen tapahtumien käsittely - järjestelmä, joka analysoi asiakkaan toimet reaaliajassa ja voi tehdä hänelle välittömästi relevantin tarjouksen. Käytä vastaavia toimintoja toteuttaaksesi arkkitehtoninen malli, jota kutsutaan tapahtumalähtöiseksi arkkitehtuuriksi (EDA). Mikään nykyisistä palveluverkoista ei tue tällaisia malleja, mutta tämä on erittäin tärkeää varsinkin pankille!
On melko outoa, että kaikki Service Meshin versiot tukevat Remote Procedure Call (RPC) -ohjelmaa, mutta ne eivät ole ystävällisiä EDA: n kanssa. Koska Service Mesh on eräänlainen moderni hajautettu integraatio, ja EDA on erittäin relevantti arkkitehtoninen malli, jonka avulla voit tehdä ainutlaatuisia asioita asiakaskokemuksen kannalta.
Enterprise Service Meshin pitäisi ratkaista tämä ongelma. Lisäksi haluamme nähdä siinä taatun toimituksen, suoratoiston ja monimutkaisen tapahtumakäsittelyn toteutuksen käyttämällä erilaisia suodattimia ja malleja.
Tiedostonsiirtopalvelu
EDA:n lisäksi olisi mukavaa pystyä siirtämään tiedostoja: Enterprise-mittakaavassa usein vain tiedostojen integrointi on mahdollista. Erityisesti käytetään ETL-arkkitehtuurimallia (Extract, Transform, Load). Siinä pääsääntöisesti kaikki vaihtavat tiedostoja yksinomaan: käytetään big dataa, mikä on epäkäytännöllistä työntää erillisiä pyyntöjä. Mahdollisuus natiivisti tukea tiedostojen siirtoa Enterprise Service Meshissä antaa sinulle yrityksesi tarvitsemaa joustavuutta.
Orkesteripalvelu
Suurissa organisaatioissa on lähes aina eri tiimit, jotka tekevät erilaisia tuotteita. Esimerkiksi pankissa jotkut tiimit työskentelevät talletusten kanssa, kun taas toiset työskentelevät lainatuotteiden kanssa, ja tällaisia tapauksia on melko paljon. Nämä ovat erilaisia ihmisiä, erilaisia tiimejä, jotka valmistavat tuotteitaan, kehittävät API:aan ja tarjoavat niitä muille. Ja hyvin usein on tarve muodostaa nämä palvelut sekä toteuttaa monimutkainen logiikka API-joukon kutsumiseksi peräkkäin. Tämän ongelman ratkaisemiseksi tarvitset integrointikerroksen ratkaisun, joka yksinkertaistaa kaikkea tätä yhdistelmälogiikkaa (kutsuu useita API:ita, kuvailee pyyntöreitin jne.). Tämä on Enterprise Service Meshin orkestrointipalvelu.
AI ja ML
Kun mikropalvelut kommunikoivat yhden integraatiokerroksen kautta, Service Mesh luonnollisesti tietää kaiken kunkin palvelun puheluista. Keräämme telemetriaa: kuka soitti kenelle, milloin, kuinka kauan, kuinka monta kertaa ja niin edelleen. Kun näitä palveluita on satoja tuhansia ja puheluita miljardeja, kaikki tämä kerääntyy ja muodostaa Big Dataa. Tätä dataa voidaan analysoida tekoälyn, koneoppimisen jne. avulla, ja sitten analyysitulosten perusteella voidaan tehdä hyödyllisiä asioita. Kaiken tämän Service Meshiin integroidun verkkoliikenteen ja sovelluskutsujen hallinta olisi ainakin osittain tarkoituksenmukaista luovuttaa tekoälylle.
API-yhdyskäytäväpalvelu
Tyypillisesti Service Meshillä on välityspalvelimia ja palveluita, jotka keskustelevat keskenään luotetulla alueella. Mutta on myös ulkopuolisia vastapuolia. Vaatimukset tälle kuluttajaryhmälle altistuville API:ille ovat paljon ankarammat. Jaamme tämän tehtävän kahteen pääosaan.
- Безопасность. Ongelmia, jotka liittyvät ddos-toimintoihin, protokollien, sovellusten, käyttöjärjestelmien ja niin edelleen haavoittuvuuksiin.
- asteikko. Kun asiakkaille tarjottavien API-liittymien määrä nousee tuhansiin tai jopa satoihin tuhansiin, tarvitaan jonkinlainen hallintatyökalu tälle API-joukolle. Sinun on seurattava jatkuvasti API:ta: toimivatko ne vai eivät, mikä niiden tila on, mikä liikenne virtaa, mitkä tilastot jne. API-yhdyskäytävän pitäisi hoitaa tämä tehtävä ja tehdä koko prosessista hallittavissa ja suojattu. Tämän komponentin ansiosta Enterprise Service Mesh oppii julkaisemaan helposti sekä sisäisiä että ulkoisia sovellusliittymiä.
Tukipalvelu tietyille protokollille ja tietomuodoille (AS-yhdyskäytävä)
Tällä hetkellä useimmat Service Mesh -ratkaisut voivat toimia natiivisti vain HTTP- ja HTTP2-liikenteen kanssa tai supistetussa tilassa TCP/IP-tasolla. Enterprise Service Mesh on syntymässä monien muiden hyvin erityisten tiedonsiirtoprotokollien kanssa. Jotkut järjestelmät voivat käyttää viestivälittäjiä, toiset on integroitu tietokantatasolla. Jos yrityksellä on SAP, se voi käyttää myös omaa integrointijärjestelmää. Lisäksi kaikki tämä toimii ja on tärkeä osa liiketoimintaa.
Et voi vain sanoa: "Hylkäämme vanhaan ja tehdään uusia järjestelmiä, jotka voivat käyttää Service Meshiä." Kaikkien vanhojen järjestelmien yhdistämiseksi uusiin (mikropalveluarkkitehtuurilla) Service Meshiä käyttävät järjestelmät tarvitsevat jonkinlaisen sovittimen, välittäjän, yhdyskäytävän. Samaa mieltä, olisi mukavaa, jos se tulisi laatikossa palvelun mukana. AC-yhdyskäytävä voi tukea mitä tahansa integrointivaihtoehtoa. Kuvittele vain, että asennat vain Enterprise Service Meshin ja se on valmis vuorovaikutukseen kaikkien tarvitsemiesi protokollien kanssa. Tämä lähestymistapa on meille erittäin tärkeä.
Suunnilleen näin kuvittelemme Service Meshin (Enterprise Service Mesh) yritysversion. Kuvattu räätälöinti ratkaisee suurimman osan ongelmista, joita syntyy käytettäessä integraatioalustan valmiita avoimen lähdekoodin versioita. Vain pari vuotta sitten esitelty Service Mesh -arkkitehtuuri kehittyy edelleen, ja olemme innoissamme voidessamme osallistua sen kehittämiseen. Toivomme, että kokemuksestamme on sinulle hyötyä.
Lähde: will.com