Service-based architektúra: kevés, durva szolgáltatás

Célok

A lecke végére el tudod magyarázni, mi a service-based architektúra, miben tér el a mikroszervizektől, és miért tekintik gyakran a monolit és a mikroszervizek közti pragmatikus köztes lépésnek.

Miért kell?

A mikroszervizek erős önállóságot adnak, de nagy költséggel (3.3). A monolit olcsó, de egy egységben él (2.1). A két véglet között van egy gyakorlati kategória: néhány, nagy felelősségi körű szolgáltatás, amelyek külön kiadhatók, de nem aprózódnak túl.

Mi ez?

A service-based architektúra elosztott stílus, amelyben egy külön telepített felhasználói felület néhány, külön telepített, durva szemcsézettségű domainszolgáltatás előtt áll, és a szolgáltatások jellemzően közös adatbázist használnak. Mark Richards és Neal Ford könyvének (Fundamentals of Software Architecture, 13. fejezet) összefoglalása szerint ez a stílus a mikroszervizek hibridje, kevesebb komplexitással és költséggel, mint a mikroszervizek vagy az eseményvezérelt megoldások; a szolgáltatások száma jellemzően 4 és 12 között van, átlagosan kb. 7.

flowchart TB
  UI["Felhasználói felület"] --> S1["Domainszolgáltatás 1"]
  UI --> S2["Domainszolgáltatás 2"]
  UI --> S3["Domainszolgáltatás 3"]
  S1 --> DB[("Közös adatbázis")]
  S2 --> DB
  S3 --> DB

Miben tér el a mikroszervizektől?

Szempont	Service-based	Mikroszervizek
Szolgáltatások száma	Kevés (néhány)	Sok
Szemcsézettség	Durva, domain szintű	Egy üzleti képesség
Adat	Gyakran közös adatbázis	Szolgáltatásonkénti adat
Tranzakció	Közös adatbázisban helyi tranzakció is lehet	Elosztott tranzakció vagy saga
Üzemeltetés	Kevesebb mozgó rész	Sok szolgáltatás, sok kiadás

A közös adatbázis kulcsfontosságú különbség: Ford megfogalmazásában egy nagy adatbázissémát szétbontani a mikroszervizekre való átállás egyik legnehezebb lépése. A service-based stílus ezt elkerüli.

Szempontok szerint

Szempont	Service-based
Csatolás	Szolgáltatások között kisebb, de a közös adat adatmodell-szintű csatolást hoz
Deployolhatóság	Szolgáltatásonként külön, kevés egységgel
Skálázás	Szolgáltatásonként, durva szemcsével
Adatkezelés	Közös adatbázis: egyszerű, de összekapcsol
Konzisztencia	Helyi tranzakció lehetséges a közös adaton
Hibakezelés	Hálózati hívások vannak, de kevés
Költség	Közepes: több a monolitnál, kevesebb a mikroszervizeknél

A közös adatbázis ára az adatcsatolás és a gyengébb tesztelhetőség: a séma módosítása több szolgáltatást érint.

Gyakori tévhitek

Állítás	Pontosítás
„A service-based kis mikroszervizek halmaza.”	Kevés, durva szolgáltatás, jellemzően közös adattal.
„A közös adatbázis mindig hiba.”	Tudatos kompromisszum: egyszerűbb, de adatcsatolást hoz.
„Ha szolgáltatások vannak, a deployolhatóság önmagától megjön.”	A közös sémaváltozás több szolgáltatás összehangolt kiadását is igényelheti.

Röviden

• A service-based stílus kevés, durva, külön telepített domainszolgáltatásból áll.
• A szolgáltatások jellemzően közös adatbázist használnak.
• Kevesebb komplexitással jár, mint a mikroszervizek, de erős adatcsatolást hagy.
• Gyakori közbülső állomás a monolit szétbontásakor.

Ellenőrző kérdések

1. Miben különbözik a service-based a mikroszervizektől a szolgáltatások száma és az adat szempontjából?
2. Milyen előnyt és milyen kockázatot jelent a közös adatbázis?
3. Mikor elég egy rendszernek a service-based stílus?

Források

• Service-Based Architecture (Fundamentals of Software Architecture, 13. fejezet, O'Reilly) — a stílus meghatározása; csak az előnézetet láttuk.
• Service-based architecture (InfoQ, 2016) — Neal Ford előadásának összefoglalója: a közös adatbázis mint megkülönböztető jegy és a monolitból való átállás célja.
• Comparing Service-based Architectures (Neal Ford) — a SOA, service-based és mikroszervizek összevetése.