Már régóta szerettem volna írni egy cikket a mikroszolgáltatás architektúrájáról, de folyamatosan két dolog megállított: minél jobban belemerültem a témába, annál inkább úgy tűnt, hogy amit tudok, az nyilvánvaló, és amit nem tudok, azt még tanulmányoznunk kell. Másrészt úgy érzem, hogy már van miről beszélni a széles közönség előtt. Így alternatív véleményeket szívesen fogadok.
Conway-törvény és a kapcsolat a vállalkozás, a szervezet és az információs rendszer között
Újra engedjék meg, hogy idézzek:
„Bármely szervezet, amely bármilyen rendszert tervez (széles értelemben), olyan dizájnt fog kapni, amelynek struktúrája tükrözi a szervezeten belüli csapatok struktúráját.”
— Melvyn Conway, 1967
Véleményem szerint ez a törvény inkább a vállalkozás szervezetének célszerűségéhez kapcsolódik, mint közvetlenül az információs rendszerhez. Egy példán keresztül magyaráznám el. Tegyük fel, hogy van egy elegendően stabil üzleti lehetőség, amelynek életciklusa olyan hosszú, hogy érdemes vállalkozást alapítani (nem elírás, nagyon tetszik ez a kifejezés, amit elraboltam). Természetesen az üzlet számára biztosító rendszernek szervezeti és folyamati szempontból meg kell felelnie ennek az üzletnek.
Üzletorientált információs rendszerek
Egy példán keresztül magyaráznám el. Tegyük fel, hogy van egy üzleti lehetőség, amely a pizza értékesítésére vonatkozik. Az V1 verzióban (nevezzük ezt információelőtti verziónak) a cég egy pizzéria, pénztár és házhoz szállító szolgáltatás volt. Ez a verzió hosszú életű volt a környezetének alacsony változékonysága miatt. Aztán megérkezett a 2-es verzió — fejlettebb, amely már az üzleti alapját képező információs rendszert használja monolitikus architektúrával. És itt véleményem szerint egy borzalmas igazságtalanság merül fel a monolitokkal szemben — állítólag a monolitikus architektúra nem felel meg az üzleti domain modellnek.Ha így lenne, a rendszer egyáltalán nem működne - ellentmondva Conway törvényének és a józan észnek. Nem, a monolitikus architektúra teljes mértékben megfelel a vállalkozás üzleti modelljének ezen fejlődési szakaszában - természetesen arra a szakaszra gondolok, amikor a rendszer már létrejött és üzembe helyezték. Különösen figyelemre méltó tény, hogy függetlenül az architekturális megközelítéstől, a 3-as verziójú szolgáltatás-orientált architektúra és az N verziójú mikroszerviz architektúra egyaránt jól fog működni. Hol a csapda?
Minden áramlik, minden változik, vagy a mikroszervizek a bonyolultság leküzdésének eszköze?
Mielőtt folytatnánk, nézzük át néhány félreértést a mikroszerviz architektúrával kapcsolatban.
A mikroszervizes megközelítés előnyeit hangoztató szakértők gyakran azt állítják, hogy a monolit felbontása mikroszervizekre megkönnyíti a fejlesztést a különböző szolgáltatások kódalapjának csökkentésével. Véleményem szerint ez az állítás teljesen nonszensz. Tényleg, a monolit és a homogén kód közötti interakció olyan bonyolult? Ha ez tényleg így lenne, minden projektet mikroszervizekként építenének, míg a gyakorlat azt mutatja, hogy a monolitból a mikroszervizekhez való migráció a gyakoribb. A bonyolultság nem tűnik el, csak a különálló modulokból átkerül az interfészekbe (legyenek azok adatbuszok, RPC, API és egyéb protokollok) és az orchestráló rendszerekbe. És ez - bonyolult!
A heterogén stack használatának előnye is kétséges. Nem fogom vitatni, hogy ez lehetséges, de a valóságban ritkán fordul elő (Előre szaladva - ennek lennie kell - de inkább következmény, nem pedig előny).
A termék életciklusa és a szolgáltatás életciklusa
Nézze meg újra a fenti diagramot. Nem véletlenül jegyeztem meg az üzleti verzió egyes ciklusainak csökkenését - a mai körülmények között éppen az üzlet verziók közötti átmenetének felgyorsulása a sikerének kulcsa. A termék sikerességét a benne lévő üzleti hipotézisek ellenőrzésének sebessége határozza meg. És itt, véleményem szerint, rejlik a mikroszerviz architektúra kulcsfontosságú előnye. De menjünk sorjában.
Lépjünk át az információs rendszerek evolúciójának következő szintjére — a szolgáltatásorientált architektúrára (SOA). Tehát, egy bizonyos pillanatban kiemeltük a termékünkben hosszú életű szolgáltatások — hosszú életű abban az értelemben, hogy amikor átállunk a termék következő verziójára, van lehetőség arra, hogy a szolgáltatás életciklusa hosszabb legyen, mint a termék aktuális verziójának életciklusa. Logikus lenne, ha egyáltalán nem változtatnánk rajtuk — nekünk éppen a következő verzióra való áttérés sebessége fontos. De sajnos, folyamatosan változtatásokat kell végeznünk a szolgáltatásokban — erre szükség van, és az összes DevOps gyakorlat, konténerizálás és bármi más — mindez belefér. De ez még mindig nem mikro-szolgáltatások!
A mikro-szolgáltatások mint a komplexitás kezelési eszközei… a konfiguráció kezelésében
És itt végre átérhetünk a mikro-szolgáltatások meghatározó szerepére — ez egy megközelítés, ami egyszerűsíti a termék konfigurációjának kezelését. Pontosabban, minden egyes mikro-szolgáltatás funkciója ténylegesen a terméken belüli üzleti funkciót írja le a domain modell szerint — ezek pedig olyan dolgok, amelyek nem egy rövid életű verzióban élnek, hanem egy hosszú életű üzleti lehetőségben. És a következő verzióra való áttérés szó szerint észrevétlenül történik — módosítasz/hozzáadsz egy mikro-szolgáltatást, esetleg csak a kölcsönhatásuk sémáját, és hirtelen a jövőben találod magad, hátrahagyva a síró versenytársakat, akik továbbra is ugrálnak a monolitjaik verziói között. Most képzeld el, hogy van egy elég nagy számú mikro-szolgáltatásod előre meghatározott interfészekkel és üzleti lehetőségekkel. Te pedig összegyűjtöd, és felépíted a terméked struktúráját készen álló mikro-szolgáltatásokból — egyszerűen csak egy diagramot rajzolva például. Gratulálok — most már neked van egy platformod — és most már üzleti lehetőségeket generálhatsz. Álmok, álmok.
Következtetések
- A rendszer architektúráját a benne lévő komponensek életciklusa határozza meg. Ha egy komponens a termék verzióján belül él — nincs értelme növelni a rendszer bonyolultságát mikro-szolgáltatásos megközelítéssel.
- A mikro-szolgáltatásos architektúrának a domain modellen kell alapulnia — mivel az üzleti lehetőség a leginkább hosszú életű terület.
- A szállítási gyakorlatok (DevOps gyakorlatok) és az orchestráció kulcsfontosságú jelentőséggel bírnak a mikroszolgáltatás-alapú architektúrában, mert az összetevők változásának felgyorsulása magasabb követelményeket támaszt a szállítás sebességével és minőségével szemben.
Forrás: habr.com
