Vaikuttaa siltä, että mikropalvelujen hype-huippu on takanapäin. Emme enää lue useita kertoja viikossa viestejä "Kuinka siirsin monoliittini 150 palveluun". Nyt kuulen enemmän maalaisjärkeä ajatuksia: "En vihaa monoliittia, välitän vain tehokkuudesta." Havaitsimme jopa useita muuttoja . Kun siirryt yhdestä suuresta sovelluksesta useisiin pienempiin palveluihin, joudut ratkaisemaan useita uusia ongelmia. Listataan ne mahdollisimman lyhyesti.
Asetus: peruskemiasta kvanttimekaniikkaan
Perustietokannan ja sovelluksen määrittäminen taustaprosessilla oli melko yksinkertainen prosessi. Julkaisen readme:n Githubissa - ja usein tunnin, korkeintaan muutaman tunnin kuluttua kaikki toimii, ja aloitan uuden projektin. Koodin lisääminen ja suorittaminen, ainakin alkuperäiselle ympäristölle, tehdään ensimmäisenä päivänä. Mutta jos ryhdymme mikropalveluihin, ensimmäinen käynnistysaika nousee pilviin. Kyllä, nyt meillä on Docker orkestraatiolla ja K8-koneiden klusteri, mutta aloittelevalle ohjelmoijalle tämä kaikki on paljon monimutkaisempaa. Monille junioreille tämä on taakka, joka on todella tarpeeton komplikaatio.
Järjestelmää ei ole helppo ymmärtää
Keskitytään hetkeksi junioriimme. Monoliittinen sovellus, jos virhe tapahtui, se oli helppo jäljittää ja siirtyä välittömästi virheenkorjaukseen. Nyt meillä on palvelu, joka puhuu toiselle palvelulle, joka jonottaa jotain viestiväylään, joka käsittelee toista palvelua - ja sitten tapahtuu virhe. Meidän on koottava kaikki nämä osat yhteen saadaksemme lopulta selville, että palvelu A käyttää versiota 11 ja palvelu E odottaa jo versiota 12. Tämä eroaa hyvin tavallisesta konsolidoidusta lokistani: joudun käyttämään interaktiivista päätettä/debuggeria kävelemään. prosessin läpi vaihe vaiheelta. Virheenkorjaus ja ymmärtäminen ovat luonnostaan muuttuneet vaikeammiksi.
Jos virheenkorjaus ei onnistu, voimme ehkä testata niitä
Jatkuva integraatio ja jatkuva kehittäminen ovat nykyään arkipäivää. Useimmat näkemäni uudet sovellukset luovat ja suorittavat automaattisesti testejä jokaisen uuden julkaisun yhteydessä ja vaativat testien suorittamista ja tarkistamista ennen rekisteröintiä. Nämä ovat hienoja prosesseja, joista ei pidä luopua, ja ne ovat olleet suuri muutos monille yrityksille. Mutta nyt, jotta voin todella testata palvelua, minun on hankittava sovelluksestani täysi toimiva versio. Muistatko sen uuden insinöörin, jolla on 8 palvelun K150-klusteri? No, nyt opetamme CI-järjestelmällemme kuinka tuoda esiin kaikki nämä järjestelmät varmistaaksemme, että kaikki todella toimii. Tämä on luultavasti liikaa vaivaa, joten testaamme vain jokaisen osan erikseen: olen varma, että tekniset tiedot ovat riittävän hyvät, API:t ovat puhtaita ja palveluvirhe on eristetty eikä se vaikuta muihin.
Kaikilla kompromisseilla on hyvä syy. Eikö?
Mikropalveluihin siirtymiseen on monia syitä. Olen nähnyt tämän tehtävän suuremman joustavuuden, ryhmien skaalauksen, suorituskyvyn ja paremman kestävyyden vuoksi. Mutta todellisuudessa olemme investoineet vuosikymmeniä työkaluihin ja käytäntöihin kehittääksemme jatkuvasti kehittyviä monoliitteja. Työskentelen eri teknologioiden ammattilaisten kanssa. Puhumme yleensä skaalauksesta, koska ne törmäävät yhden Postgres-tietokantasolmun rajoihin. Suurin osa keskusteluista koskee .
Mutta olen aina kiinnostunut oppimaan heidän arkkitehtuuristaan. Missä vaiheessa mikropalveluihin siirtymistä ne ovat? On mielenkiintoista nähdä useampia insinöörejä sanovan olevansa tyytyväisiä monoliittiseen sovellukseensa. Monet ihmiset hyötyvät mikropalveluista, ja hyödyt ovat suurempia kuin muuttopolun kolhut. Mutta henkilökohtaisesti, anna minulle monoliittinen sovellukseni, paikka rannalla - ja olen täysin onnellinen.
Lähde: will.com
