Helló, Habr. Ma folytatom a bejegyzések sorozatát, amelyet kifejezetten az új kurzus indulására írtam. .
Bevezetés
Az architekturális stílus megválasztása az egyik alapvető műszaki döntés az informatikai rendszer felépítésekor. Ebben a cikk sorozatban a legnépszerűbb alkalmazásarchitekturális stílusokat szeretném bemutatni, és válaszolni a kérdésre, hogy mikor melyik architekturális stílus a legkedvezőbb. Az előadás során megpróbálom bemutatni a logikai kapcsolatot, amely elmagyarázza az architekturális stílusok fejlődését a monolitoktól a mikroszolgáltatásokig.
Legutóbb különféle monolit típusokról és a komponensek használatáról beszéltünk a felépítésükhöz, beleértve mind az összeszerelési, mind a telepítési komponenseket. Megértettük a szolgáltatásorientált architektúrát.
Most végre meghatározzuk a mikroszolgáltatás architektúra alapvető jellemzőit.
Architektúrák kapcsolata
Fontos megérteni, hogy a korábbi cikkekben meghatározottak alapján bármely szolgáltatás komponens, de nem minden szolgáltatás mikroszolgáltatás.
A mikroszolgáltatás architektúra jellemzői
A mikroszolgáltatás architektúra fő jellemzői a következők:
- Szervezés az üzleti lehetőségek köré (Organized around Business Capabilities)
- Termékek, nem projektek (Products not Projects)
- Intelligens belépési pontok és buta csövek (Smart endpoints and dumb pipes)
- Decentralizált irányítás (Decentralized Governance)
- Decentralizált adatok kezelése (Decentralized Data Management)
- Infrastruktúra automatizálás (Infrastructure Automation)
- Hibák ellen biztosítás (Design for failure)
- Evolúciós fejlődésű architektúra (Evolutionary Design)
Az első pont a szolgáltatásorientált architektúrából származik, mert a mikroszolgáltatások a szolgáltatások speciális esetei. A többi pont külön részletesebben foglalkozik.
Szervezés az üzleti lehetőségek köré (Organized around Business Capabilities)
Most fontos megemlíteni Conway törvényét: azok a szervezetek, amelyek rendszereket hoznak létre, az architektúrájukat azokon a struktúrákon szervezik meg, amelyek belül ezekben a szervezetekben kölcsönhatásban állnak. Példaként említhetjük a compiler elkészítésének esetét: egy hét fős csapat fejlesztett ki egy hétszereplős fordítót, míg egy öt fős csapat egy ötszereplős fordítót.
Ha a monolitokról és mikroszolgáltatásokról beszélünk, abban az esetben, ha a fejlesztést funkcionális osztályok szerint szervezik (háttér, frontend, adatbázis-adminisztrátorok), klasszikus monolit alakul ki.
Mikroszolgáltatások létrehozásához a csapatokat üzleti lehetőségek szerint kell szervezni (megrendelő csapat, szállítások, katalógus). Ez a szervezés lehetővé teszi, hogy a csapatok a alkalmazás konkrét részeinek létrehozására összpontosítsanak.
Termékek, nem projektek (Products not Projects)
A projektalapú megközelítés, amelyben a csapat átadja a kifejlesztett funkciót más csapatoknak mikroszolgáltatás-architektúra esetén, teljesen alkalmatlan. A csapatnak fenntartania kell a rendszert annak teljes életciklusa alatt. Az Amazon, a mikroszolgáltatások bevezetésének éllovasa, azt nyilatkozta: „terméket fejlesztesz, és te magad indítod el” („you build, you run it”). A termékmegközelítés lehetővé teszi a csapat számára, hogy érezze az üzlet szükségleteit.
Intelligens belépési pontok és buta csövek (Smart endpoints and dumb pipes)
Az SOA architektúra nagy figyelmet fordított a kapcsolatokra, különösen az Enterprise Service Busra (vállalati szolgáltatásbusz). Ez gyakran az Erroneous Spaghetti Boxhoz vezet, azaz a monolit bonyolultsága átszáll a szolgáltatások közötti kapcsolatok bonyolultságára. A mikroszolgáltatás-architektúrában csak egyszerű interakciós módokat alkalmaznak.
Decentralizált irányítás (Decentralized Governance)
A mikroszolgáltatásokkal kapcsolatos kulcsfontosságú döntéseket azoknak az embereknek kell meghozniuk, akik valóban mikroszolgáltatásokat fejlesztenek. Itt a kulcsfontosságú döntések alatt értjük a
programozási nyelvek, telepítési módszerek, nyilvános interfészek szerződései stb.
Decentralizált adatok kezelése (Decentralized Data Management)
A hagyományos megközelítés, amely úgy kezel egy alkalmazást, hogy az egy adatbázisra támaszkodik, nem tudja figyelembe venni minden egyes szolgáltatás sajátos igényeit. Az MSA decentralizált adatkezelést feltételez, egészen a különböző technológiák alkalmazásáig.
Infrastruktúra automatizálás (Infrastructure Automation)
Az MSA támogatja a folyamatos telepítési és szállítási folyamatokat. Ezt csak a folyamatok automatizálásával lehet megvalósítani. Ezen túlmenően, számos szolgáltatás telepítése már nem tűnik ijesztő feladatnak. A telepítési folyamatnak unalmasnak kell lennie. A másik aspektus a szolgáltatások kezelése a termékkörnyezetben. Automatizálás nélkül lehetetlenné válik a különböző operációs környezetekben futó folyamatok kezelése.
Hibák ellen biztosítás (Design for failure)
A sok MSA-szolgáltatás hajlamos a hibákra. Ezenkívül a hibatűrés a elosztott rendszerekben nem trivialis feladat. Az alkalmazások architektúrájának ellenállónak kell lennie az ilyen hibákkal szemben. Rebecca Parsons rendkívül fontosnak tartja, hogy többé ne használjunk még belső folyamatok közötti kommunikációt a szolgáltatások között, helyette HTTP-t használunk kapcsolatra, ami közel sem olyan megbízható.
Evolúciós fejlődésű architektúra (Evolutionary Design)
Az MSA rendszer architektúrájának evolúciós fejlődésen kell átmennie. Ideális esetben a szükséges változtatásokat egyetlen szolgáltatás határain belül kell korlátozni. A más szolgáltatásokra gyakorolt hatást is figyelembe kell venni. A hagyományos megközelítés az, hogy megpróbálják ezt a problémát verziókezeléssel megoldani, de az MSA verziókezelés használatát
csak végső megoldásként javasolja.
Zárás
A fentiek alapján megfogalmazható, mit is jelent a mikroszolgáltatás. A mikroszolgáltatás architektúra egy megközelítés a különböző alkalmazások fejlesztésében, amely egy kis szolgáltatásokból álló készlet formájában valósul meg, amelyek mindegyike a saját folyamatában működik, és könnyített mechanizmusok révén kommunikál, gyakran HTTP API interfészen keresztül. Ezek a szolgáltatások üzleti lehetőségekre épülnek, és függetlenül telepíthetők egy teljesen
automatikus telepítési mechanizmus segítségével. Minimális központosított irányítás létezik ezek felett a szolgáltatások felett, amelyek különböző programozási nyelveken íródhatnak és különböző adatkezelési technológiákat használhatnak.
Forrás: habr.com
