Hei, olen Stanislav Yablonskiy, johtava palvelinkehittäjä Pixonicissa (MY.GAMES). Microservices on lähestymistapa ohjelmistokehitykseen (pääasiassa backend-kehitykseen), jossa toiminnallisuus on jaettu pienimpiin mahdollisiin komponentteihin, joista kukin toimii itsenäisesti. Microservices ovat hyvin suosittuja nykyään, mutta niiden käyttö tuo merkittävää ylijäämää suhteessa verkkoon, muistiin ja CPU. Jokainen puhelu muuttuu tarpeeseen sarjoittaa, lähettää ja vastaanottaa tietoja verkon kautta. Lisäksi ei ole enää mahdollista käyttää klassisia tietokantatransaktioita, mikä johtaa joko hajautettuihin transaktioihin tai lopulliseen johdonmukaisuuteen. Jakautuneet transaktiot ovat hitaita ja kalliita, kun taas mahdollinen johdonmukaisuus tarkoittaa, että operaatioiden tulokset eivät välttämättä näy välittömästi, ja tiedot voivat olla tilapäisesti epäjohdonmukaisia. Mikropalvelujen käyttäminen pakottaa kehittäjät kirjoittamaan enemmän koodia jokaiseen yksittäiseen palveluun, koska on vaikea käyttää jo kirjoitettua logiikkaa muista palveluista.Joskus on vaikea käyttää olemassa olevaa koodia uudelleen tai et ehkä edes tiedä, että se on olemassa - koska muut ihmiset voivat työskennellä eri projektissa. Microservices’ Ylhäältä Debug ylipäätä Debugging muuttuu paljon vaikeammaksi mikropalvelujen kanssa. Säännöllinen debugger on melkein hyödytön tällaisissa olosuhteissa, koska et voi debuggaa kaikkia palveluita kerralla. Ilman asianmukaisesti määritettyä lokalisointi-, seuranta- ja metrologian järjestelmää, debugging on lähes mahdotonta, kunnes ongelma on paikallistettu. Tämä tarkoittaa sitä, että tarvitset erityisen ympäristön, jossa paitsi vianmääritetty palvelu toimii myös kaikki sen riippuvuudet (muut palvelut, tietokannat, jonot jne.). HTTP Ylhäältä HTTP-protokolla on runsaasti sisäänrakennettuja toimintoja. Se tukee erilaisia reittejä, parametrien siirtämismenetelmiä, vastauskoodeja ja sitä tukevat monet valmiit palvelut (mukaan lukien välityspalvelut). Protobuf Ylhäältä Verkkoliikennettä varten tarvitaan serialisointi ja deserialisointi viestien vastaanottamisen yhteydessä. Kun käytät protobufia viestien vaihtoon, sinun on: luoda esineitä, Käännä ne muutoksiin, Poista ne välittömästi käytön jälkeen. Tämä luo paljon ylimääräistä työtä roskapostin keräilijälle tai dynaamiselle muistinhallinnalle. Verkkopalvelut Overhead Tietojen lähettäminen verkon kautta lisää palvelun vastausaikaa.Se lisää muistin ja prosessorin kulutusta, vaikka mikrosivustot toimisivat samalla isännällä. Muisti Overhead Viestien lähettäminen ja vastaanottaminen edellyttää ylimääräisten tietorakenteiden ylläpitoa, erillisten säikeiden käyttöä ja niiden synkronointia.Jokainen erillinen prosessi, erityisesti säiliössä suoritettava, kuluttaa huomattavan määrän muistia vain olemassa olevien. CPU Ylhäältä Luonnollisesti kaikki tämä prosessien ja konttien välinen viestintä vaatii laskennallisia resursseja. Tietokanta Overhead Normaalit transaktiot ovat mahdottomia, kun operaatiot kattavat useita mikropalveluja. Jakautuneet transaktiot ovat paljon hitaampia ja vaativat monimutkaista – usein manuaalista – koordinointia. Verkkokaapeli Overhead Microservice-säiliöt toimivat usein verkkoon asennetuilla levyillä, mikä lisää latenssia, vähentää suorituskykyä (IOPS) ja tekee siitä arvaamattoman. Hankkeen rajat ylittävät Mikropalvelujen suunnittelu ja kehittäminen aiheuttaa vaikeuksia projektin kehittämisessä ja uudistamisessa. Palvelun vastuualueen muuttaminen ei ole helppoa. Et voi vain siirtää koodia palvelusta toiseen. Tämä vaatii yleensä: paljon aikaa ja vaivaa, useita eri versioita, ja monimutkaiset siirtymät ennen kuin toiminnallisuus voidaan jakaa uudelleen palveluiden välillä. Lisäksi, jos haluat päivittää tai korvata kirjaston, sinun on tehtävä se kaikissa projekteissa, ei vain yhdessä. Infrastruktuuri ylivoimaisesti Et voi vain "tehdä mikropalveluita." Tarvitset infrastruktuuria - ei, INFRASTRUCTURE: säiliöt (jokainen sisältää kopioita jaetuista kirjastoista), Kuubalaisten kanssa, pilvipalveluiden tarjoaminen, Jäsenet (RabbitMQ ja Kafka) Konfiguraation synkronointityökalut (Zookeeper, Etcd, Consul) ja niin edelleen. Kaikki tämä vaatii valtavia resursseja sekä koneilta että ihmisiltä. Itsenäinen käyttöönotto Overhead Riippumattomien käyttöönottojen tukeminen tarkoittaa: Jokaisen palvelun on oltava käytettävissä erikseen, Jokaisella on oltava oma CI/CD-putki. ja vaikein osa - API versiointi. Jokaisen palvelun on tuettava useita API-versioita samanaikaisesti, ja soittajan on seurattava näitä versioita ja päivitettävä puhelut ajoissa. Jakautettu Ball of Mud Puhtaiden mikropalvelujen sijaan päädyt hajautettuun savenpalloon - jossa toiminnallisuus on huonosti jaettu, ulkoiset puhelut laukaisevat kokonaisia sisäisten palvelukutsujen ketjuja, ja kaikki on hirveän hidasta. Onko monoliitti todella niin pelottava? Modulaarinen monoliitti Modulaaristen monoliittien avulla voit välttää suurimman osan mikropalveluista, mutta silti tarjota erottelua, jota voidaan käyttää myöhemmin tarvittaessa. Tämä lähestymistapa käsittää sovelluksen kirjoittamisen (ensisijaisesti taustaosa) yhtenä palveluna, joka on jaettu yksittäisiin moduuleihin seuraavasti: selkeästi määritellyt rajat ja Minimaaliset keskinäiset riippuvuudet Tämä mahdollistaa niiden jakamisen palveluihin, jos skaalaaminen todella vaatii sitä. Odota, voitko tehdä sen? Monia etuja, jotka johtuvat mikropalveluarkkitehtuurista, voidaan saavuttaa monoliitissa: Modulaarisuus voidaan toteuttaa kieliominaisuuksilla: luokat, nimipaikat, projektit ja kokoelmat; Useita tietokantoja – mahdollista, jos sitä todella tarvitaan Useita kieliä – myös mahdollista, esimerkiksi yhdistämällä C/C++/C#/Java käsikirjoituskieliä kuten JavaScript, Python tai Erlang korkeamman tason kehittämiseen; Interop – monet alustat tukevat C/C++: n soittamista Java, C#, Python, JavaScript tai Erlang; Viestien jonoja – käytä vain asianmukaista datarakennetta. Ja kun haluat poistaa - yksi näppäimistö, ja koko sovellus on käsilläsi. Näyttelijä Frameworks Actor-kehysten avulla voit rakentaa mikrosivustoja – ilman mikrosivustoja. Kaikki logiikka on jaettu luokkiin (toimijat), jotka kommunikoivat vain viestibussin (seurat) kautta. Nämä toimijat voivat: on olemassa yhden prosessin sisällä, tai jaetaan useisiin prosesseihin. Tällä tavoin saat mikropalvelun ohjelmointimallin, mutta suurin osa infrastruktuurista käsitellään itse kehyksessä. Conclusion Johtopäätös Arkkitehtuurin valinta perustuu: hankkeen vaatimukset, käytettävissä olevat resurssit, ja tiimin asiantuntemusta. Ne ovat hyödyllisiä suurille projekteille ja tiimille – mutta monoliitti ei ole vanhentunut eikä ole tekninen velka oletusarvoisesti. Tärkeintä on tasapaino joustavuuden ja monimutkaisuuden, skaalautuvuuden ja ylläpitävyyden välillä, jotta rakentamasi järjestelmä on tehokas ja kestävä.
