Hei, Habr. Tänään jatkan julkaisusarjaa, jonka kirjoitin nimenomaan uuden kurssin virran aloittamiseksi. .
Esittely
Arkkitehtonisen tyylin valinta on yksi keskeisistä teknisistä päätöksistä tietojärjestelmää rakennettaessa. Tässä artikkelisarjassa ehdotan analysoimaan suosituimpia arkkitehtonisia tyylejä rakennussovelluksissa ja vastaamaan kysymykseen, milloin mikä arkkitehtoninen tyyli on edullisin. Esityksen yhteydessä yritän piirtää loogisen ketjun, joka selittää arkkitehtonisten tyylien kehittymisen monoliiteista mikropalveluihin.
Viime kerralla puhuimme erityyppisistä monoliitteista ja komponenttien käytöstä niiden rakentamiseen, sekä rakennuskomponentteihin että käyttöönottokomponentteihin. Ymmärrämme palvelukeskeisen arkkitehtuurin.
Nyt lopuksi määritellään mikropalveluarkkitehtuurin pääominaisuudet.
Arkkitehtuurien suhde
On ymmärrettävä, että aiemmissa artikkeleissa annettujen määritelmien perusteella mikä tahansa palvelu on komponentti, mutta jokainen palvelu ei ole mikropalvelu.
Mikropalveluarkkitehtuurin ominaisuudet
Mikropalveluarkkitehtuurin tärkeimmät ominaisuudet ovat:
- Organisoitunut liiketoimintaominaisuuksien ympärille
- Tuotteet eivät projekteja
- Älykkäät päätepisteet ja tyhmät putket
- Hajautettu hallinto
- Hajautettu tiedonhallinta
- Infrastruktuurin automaatio
- Suunnittelu epäonnistumiseen
- Arkkitehtuuri evolutionaarisen kehityksen kanssa (Evolutionary Design)
Ensimmäinen kohta tulee palvelukeskeisestä arkkitehtuurista, koska mikropalvelut ovat palveluiden erikoistapaus. Muut kohdat ansaitsevat erillisen tarkastelun.
Organisoitunut liiketoimintaominaisuuksien ympärille
Nyt on muistettava Conwayn laki: järjestelmiä luovat organisaatiot organisoivat sen arkkitehtuuria, kopioiden vuorovaikutuksen rakennetta näiden organisaatioiden sisällä. Esimerkkinä voidaan muistaa kääntäjän luominen: seitsemän hengen ryhmä kehitti seitsemän vaiheen kääntäjän ja viiden hengen ryhmä viisikierroksen kääntäjän.
Jos puhumme monoliitteistä ja mikropalveluista, niin jos kehitys järjestetään toiminnallisten osastojen (backend, frontend, tietokantajärjestelmänvalvojat) mukaan, saamme klassisen monoliitin.
Mikropalvelujen saamiseksi tiimit on organisoitava liiketoimintakyvyn mukaan (tilaukset, toimitukset, luettelointitiimi). Tämä organisaatio antaa ryhmille mahdollisuuden keskittyä sovelluksen tiettyjen osien rakentamiseen.
Tuotteet eivät projekteja
Projektilähestymistapa, jossa tiimi siirtää kehitetyn toiminnallisuuden muille tiimeille, on täysin sopimaton mikropalveluarkkitehtuuriin. Tiimin tulee tukea järjestelmää koko sen elinkaaren ajan. Amazon, yksi mikropalvelujen toteuttamisen johtajista, totesi: "sinä rakennat, sinä käytät sitä." Tuotelähestymistapa antaa tiimille mahdollisuuden tuntea yrityksen tarpeet.
Älykkäät päätepisteet ja tyhmät putket
SOA-arkkitehtuuri kiinnitti suurta huomiota viestintäkanaviin, erityisesti Enterprise Service Busiin. Mikä usein johtaa virheelliseen spagettilaatikkoon, eli monoliitin monimutkaisuus muuttuu palveluiden välisten yhteyksien monimutkaiseksi. Mikropalveluarkkitehtuuri käyttää vain yksinkertaisia viestintämenetelmiä.
Hajautettu hallinto
Mikropalveluita koskevat keskeiset päätökset tulee tehdä niiden ihmisten, jotka todella kehittävät mikropalveluita. Tässä keskeiset päätökset tarkoittavat valintoja
ohjelmointikielet, käyttöönottomenetelmät, julkiset käyttöliittymäsopimukset jne.
Hajautettu tiedonhallinta
Vakiolähestymistapa, jossa sovellus luottaa yhteen tietokantaan, ei voi ottaa huomioon kunkin palvelun erityispiirteitä. MSA sisältää hajautetun tiedonhallinnan, joka sisältää erilaisten teknologioiden käytön.
Infrastruktuurin automaatio
MSA tukee jatkuvaa käyttöönotto- ja toimitusprosesseja. Tämä voidaan saavuttaa vain automatisoimalla prosesseja. Samaan aikaan useiden palveluiden käyttöönotto ei enää näytä pelottavalta. Käyttöönottoprosessin pitäisi tulla tylsäksi. Toinen näkökohta liittyy palvelunhallintaan tuoteympäristössä. Ilman automaatiota eri toimintaympäristöissä käynnissä olevien prosessien hallinta on mahdotonta.
Suunnittelu epäonnistumiseen
Monet MSA-palvelut ovat alttiita epäonnistumiselle. Samaan aikaan virheiden käsittely hajautetussa järjestelmässä ei ole vähäpätöinen tehtävä. Sovellusarkkitehtuurin on oltava kestävä tällaisia vikoja vastaan. Rebecca Parsons pitää erittäin tärkeänä, että emme enää käytä edes prosessin sisäistä viestintää palveluiden välillä, vaan turvaudumme kommunikaatioon HTTP:hen, joka ei ole läheskään yhtä luotettavaa.
Arkkitehtuuri evolutionaarisen kehityksen kanssa (Evolutionary Design)
MSA-järjestelmän arkkitehtuurin tulisi kehittyä evolutionaarisesti. Tarvittavat muutokset on suositeltavaa rajoittaa yksittäisen palvelun rajoihin. Myös vaikutukset muihin palveluihin on otettava huomioon. Perinteinen lähestymistapa on yrittää ratkaista tämä ongelma versioinnilla, mutta MSA suosittelee versioinnin käyttöä
viimeisenä keinona.
Johtopäätös
Kaiken edellä mainitun jälkeen voimme muotoilla mitä mikropalvelut ovat. Mikropalveluarkkitehtuuri on tapa kehittää yksi sovellus kokoelmana pieniä palveluita, joista jokainen toimii omassa prosessissaan ja vuorovaikutuksessa kevyiden mekanismien, usein HTTP-resurssisovellusliittymien, kautta. Nämä palvelut perustuvat liiketoimintaominaisuuksiin, ja ne voidaan ottaa käyttöön itsenäisesti
automaattinen käyttöönottomekanismi. Näiden palveluiden keskitetty hallinta on vähimmäistasoa, ja ne voidaan kirjoittaa eri ohjelmointikielillä ja käyttää erilaisia tiedontallennustekniikoita.
Lähde: will.com