Mikor melyik? Az architektúrák összevetése és a választás szempontjai

Célok

A lecke végére a hét szempont mentén össze tudod hasonlítani az eddig tárgyalt stílusokat, ki tudod mondani a választás döntési kérdéseit, és meg tudod indokolni, miért nincs egyetlen legjobb architektúra.

Miért kell külön lecke?

Az egyes stílusok önmagukban megismerhetők, de a gyakorlati kérdés mindig az: melyiket mikor? A válasz nem a stílusok rangsorában, hanem a követelmények, a csapat és az üzemeltetési képesség illeszkedésében rejlik.

Az összevetés

A táblázat a tipikus következményeket mutatja, nem abszolút szabályokat. Egy rosszul működtetett monolit sem feltétlenül olcsó, és két egyszerű szolgáltatás sem szükségképpen bonyolultabb egy óriási alkalmazásnál.

Szempont	Monolit	Modulit	Service-based	Mikroszervizek	Serverless
Csatolás	Fegyelem tartja	Ellenőrzött modulfelület	Szolgáltatásszerződés, gyakran közös adat	Szolgáltatásszerződés, saját adat	Eseményeken és szolgáltatásokon át
Deployolhatóság	Egy egység	Egy egység	Kevés egység	Sok önálló egység	Függvényenként
Skálázás	Egészében	Egészében	Szolgáltatásonként (durva)	Szolgáltatásonként (finom)	Platform által, automatikus
Adatkezelés	Közös	Közös, modulgazdákkal	Gyakran közös	Szolgáltatásonként	Külső tárban
Konzisztencia	Helyi tranzakció	Helyi tranzakció	Helyi tranzakció lehetséges	Többnyire végső konzisztencia	Külső tártól függ
Hibakezelés	Egy folyamat	Egy folyamat	Néhány hálózati hívás	Sok hálózati hívás, részleges hiba	Platform + hálózati hívások
Csapat- és üzemeltetési költség	Alacsony	Alacsony	Közepes	Magas	Alacsony üzemeltetés, szolgáltatófüggés

Döntési kérdések

1. Mennyire változnak együtt a részek? Ha általában együtt, a közös egység (monolit/modulit) egyszerűbb.
2. Kell-e külön kiadás vagy külön skálázás? Csak akkor érdemes hálózati határt húzni, ha a határ valós függetlenséget ad.
3. Kell-e közös tranzakció? Ha igen, és nem lehet lazítani, a közös adat fontos.
4. Hány csapat dolgozik, mekkora a szervezet? Conway szerint a szerkezet követi a szervezetet (1.2).
5. Van-e automatizálás, megfigyelés, üzemeltetési képesség? Fowler a mikroszerviz felárának részeként említi az automatizált kiadást, a megfigyelést és a hibakezelést.
6. Mennyire biztosak a határok? Bizonytalan határnál a monolit/modulit olcsóbb tévedést enged.

flowchart TD
  A{"Együtt változnak<br/>a részek?"} -->|"Igen"| B["Monolit vagy modulit"]
  A -->|"Nem"| C{"Van üzemeltetési<br/>és automatizálási képesség?"}
  C -->|"Nem"| D["Modulit vagy<br/>service-based"]
  C -->|"Igen"| E{"Külön skálázás,<br/>külön életciklus, több csapat?"}
  E -->|"Igen"| F["Mikroszervizek<br/>(vagy serverless)"]
  E -->|"Nem"| D

Az ábra szemléltető döntési segéd, nem algoritmus: a valós döntéshez a követelményeket kell mérlegelni, és az eredményt dokumentálni (1.5).

Egy időben több stílus

A stílusok keverhetők. Egy rendszernek lehet moduláris magja, mellette néhány külön szolgáltatással (például egy erősen terhelt feldolgozó), vagy a háttérben serverless függvényekkel. A mérce mindig a konkrét határ költsége és haszna, nem a „tisztaság”.

Space-based architektúra röviden

A space-based stílus extrém skálázási és párhuzamossági problémákra készült. A jellemző leírások szerint a rendszer feldolgozó egységekből és virtualizált köztes rétegből áll, a központi adatbázis szűk keresztmetszetét replikált, memóriabeli adatrácsok (data grid) váltják ki, a feldolgozó egységeket pedig a terheléshez igazodva lehet indítani és leállítani. A „tér” (space) elnevezés a tuple space modellből ered, amelyben az összetevők egy megosztott térben tárolt bejegyzéseken keresztül működnek együtt, nem üzenetközvetítőn át. Mivel speciális, ritka igényre való, a tananyag nem tárgyalja részletesen; itt azért szerepel, hogy a szélsőséges skálázási igénynek is van önálló stílusa, és hogy a központi adatbázis kiváltása komoly konzisztencia- és bonyolultsági költséggel jár.

Gyakori tévhitek

Állítás	Pontosítás
„Van egy mindig legjobb architektúra.”	Minden stílus kompromisszum; a követelmények döntenek.
„A fejlettebb stílus mindig drágább, tehát jobb.”	A költség nem minőségi mutató; felesleges költség is lehet.
„A választás végleges.”	A rendszerek fejlődnek; a döntés felülvizsgálható (1.5, 3.7).
„Egy rendszerben csak egy stílus lehet.”	A stílusok keverhetők.

Röviden

• A stílusok ugyanazon hét szempont mentén hasonlíthatók össze.
• A döntési kérdések: együtt változás, külön kiadás/skálázás igénye, tranzakciók, szervezeti méret, üzemeltetési képesség, határbizonytalanság.
• A stílusok kombinálhatók.
• A space-based speciális stílus szélsőséges skálázási igényre.

Ellenőrző kérdések

1. Mikor választanád a modulitot a service-based helyett, és mikor fordítva?
2. Hogyan változik a választás, ha a csapat kicsi, és nincs üzemeltetési automatizálás?
3. Mit jelent az, hogy a stílus nem cél?

Források

• Architecture styles (Azure Architecture Center) — stílusok kényszerként; a választás szempontjai és kihívásai.
• Microservice Premium (Martin Fowler) — mikor éri meg a mikroszerviz.
• Space-based architecture (Wikipedia) — a tuple space-eredetű stílus áttekintése.