Hello, Habr. Ma folytatom a kiadványok sorozatát, amelyeket kifejezetten a kurzus új folyamának elindításához írtam. .
Bevezetés
Az építészeti stílus megválasztása az egyik alapvető technikai döntés az információs rendszer felépítésénél. Ebben a cikksorozatban azt javaslom, hogy elemezzem a legnépszerűbb építészeti stílusokat az építési alkalmazásokhoz, és válaszoljak arra a kérdésre, hogy mikor melyik építészeti stílus a legelőnyösebb. A bemutatás során megpróbálok egy logikai láncot felrajzolni, amely megmagyarázza az építészeti stílusok fejlődését a monolitoktól a mikroszolgáltatásokig.
Legutóbb a monolitok különböző típusairól és a komponensek használatáról beszéltünk az összeállításukhoz, mind az összeállításhoz, mind a telepítési összetevőkhöz. Értjük a szolgáltatás-orientált architektúrát.
Most végre meghatározzuk a mikroszolgáltatási architektúra fő jellemzőit.
Az építészetek kapcsolata
Meg kell érteni, hogy a korábbi cikkekben megadott definíciók alapján minden szolgáltatás komponens, de nem minden szolgáltatás mikroszolgáltatás.
A mikroszolgáltatási architektúra jellemzői
A mikroszolgáltatási architektúra főbb jellemzői:
- Az üzleti lehetőségek köré szerveződik
- Termékek, nem projektek
- Intelligens végpontok és buta csövek
- Decentralizált kormányzás
- Decentralizált adatkezelés
- Infrastruktúra automatizálás
- Tervezés kudarcra
- Építészet evolúciós fejlődéssel (Evolutionary Design)
Az 1. pont a szolgáltatás-orientált architektúrából származik, mivel a mikroszolgáltatások a szolgáltatások speciális esetei. A többi pont külön figyelmet érdemel.
Az üzleti lehetőségek köré szerveződik
Most meg kell emlékeznünk Conway törvényéről: a rendszereket létrehozó szervezetek megszervezik annak architektúráját, lemásolva a szervezeteken belüli interakció struktúráját. Példaként felidézhetjük a fordító létrehozásának esetét: egy héttagú csapat hétmenetes fordítót, egy ötfős csapat pedig ötmenetes fordítót fejlesztett ki.
Ha monolitokról és mikroszolgáltatásokról beszélünk, akkor ha a fejlesztést funkcionális részlegek (backend, frontend, adatbázis-adminisztrátorok) szervezik, akkor klasszikus monolitot kapunk.
A mikroszolgáltatások igénybevételéhez a csapatokat üzleti képességek szerint kell megszervezni (megrendelések, szállítmányok, katalóguscsapat). Ez a szervezet lehetővé teszi a csapatok számára, hogy az alkalmazás meghatározott részeinek felépítésére összpontosítsanak.
Termékek, nem projektek
Mikroszolgáltatási architektúra esetén teljesen alkalmatlan az a projektszemlélet, amelyben egy csapat átadja a kifejlesztett funkcionalitást más csapatoknak. A csapatnak támogatnia kell a rendszert az életciklusa során. Az Amazon, a mikroszolgáltatások megvalósításának egyik vezetője kijelentette: „Te építed, te futtatod.” A termékszemlélet lehetővé teszi a csapat számára, hogy átérezze a vállalkozás igényeit.
Intelligens végpontok és buta csövek
A SOA architektúra nagy figyelmet fordított a kommunikációs csatornákra, különösen az Enterprise Service Busra. Ami gyakran Erroneous Spaghetti Box-hoz vezet, vagyis a monolit összetettsége a szolgáltatások közötti kapcsolatok bonyolultságává válik. A mikroszolgáltatási architektúra csak egyszerű kommunikációs módszereket használ.
Decentralizált kormányzás
A mikroszolgáltatásokkal kapcsolatos kulcsfontosságú döntéseket azoknak kell meghozniuk, akik ténylegesen fejlesztik a mikroszolgáltatásokat. Itt a kulcsfontosságú döntések választásokat jelentenek
programozási nyelvek, telepítési módszertan, nyilvános interfész szerződések stb.
Decentralizált adatkezelés
A standard megközelítés, amelyben az alkalmazás egyetlen adatbázisra támaszkodik, nem tudja figyelembe venni az egyes szolgáltatások sajátosságait. Az MSA decentralizált adatkezelést foglal magában, beleértve a különféle technológiák használatát.
Infrastruktúra automatizálás
Az MSA támogatja a folyamatos telepítési és szállítási folyamatokat. Ez csak a folyamatok automatizálásával érhető el. Ugyanakkor a nagyszámú szolgáltatás telepítése már nem tűnik ijesztőnek. A telepítési folyamatnak unalmassá kell válnia. A második szempont a termékkörnyezet szolgáltatásmenedzsmentjéhez kapcsolódik. Automatizálás nélkül a különböző működési környezetekben futó folyamatok menedzselése lehetetlenné válik.
Tervezés kudarcra
Számos MSA-szolgáltatás hajlamos meghibásodásra. Ugyanakkor a hibakezelés egy elosztott rendszerben nem triviális feladat. Az alkalmazás architektúrának ellenállónak kell lennie az ilyen hibákkal szemben. Rebecca Parsons nagyon fontosnak tartja, hogy a továbbiakban ne használjunk folyamat közbeni kommunikációt a szolgáltatások között, ehelyett HTTP-t használunk kommunikációhoz, ami közel sem olyan megbízható.
Építészet evolúciós fejlődéssel (Evolutionary Design)
Az MSA rendszer architektúrájának evolúciósan kell fejlődnie. Célszerű a szükséges változtatásokat egyetlen szolgáltatás határaira korlátozni. A többi szolgáltatásra gyakorolt hatást is figyelembe kell venni. A hagyományos megközelítés szerint ezt a problémát verziózással próbálják megoldani, de az MSA azt javasolja, hogy használja a verziószámítást
utolsó lehetőségként.
Következtetés
A fentiek után megfogalmazhatjuk, hogy mik is azok a mikroszolgáltatások. A mikroszolgáltatás-architektúra egy olyan megközelítés, amely egyetlen alkalmazást kis szolgáltatások gyűjteményeként fejleszt, amelyek mindegyike a saját folyamatában fut, és könnyű mechanizmusokon, gyakran HTTP-erőforrás API-n keresztül kommunikál egymással. Ezek a szolgáltatások az üzleti képességekre épülnek, és teljesen önállóan telepíthetők
automatizált telepítési mechanizmus. Ezeknek a szolgáltatásoknak van egy minimális szintje a központosított kezelésnek, amelyek különböző programozási nyelveken írhatók, és különböző adattárolási technológiákat használhatnak.
Forrás: will.com