Régóta szerettem volna egy cikket írni a mikroszolgáltatás-architektúra témájában, de két dolog folyamatosan megállított – minél jobban belemerültem a témába, annál inkább úgy tűnt számomra, hogy amit tudok, az nyilvánvaló, és amit nem. t tudom, hogy tanulmányozni és tanulmányozni kell. Másrészt úgy gondolom, hogy már van mit megvitatni széles közönség körében. Tehát szívesen fogadunk alternatív véleményeket.
Conway törvénye és az üzlet, a szervezet és az információs rendszer kapcsolata
Még egyszer megengedem magamnak, hogy idézzem:
"Minden szervezet, amely rendszert tervez (a tág értelemben), olyan tervet kap, amelynek szerkezete megismétli az adott szervezetben lévő csapatok szerkezetét."
– Melvyn Conway, 1967
Véleményem szerint ez a törvény inkább a vállalkozás megszervezésének megvalósíthatóságára vonatkozik, mintsem közvetlenül az információs rendszerre. Hadd magyarázzam el egy példával. Tegyük fel, hogy van egy elég stabil üzleti lehetőségünk olyan hosszú életciklussal, hogy van értelme vállalkozást szervezni (ez nem elírás, de nagyon szeretem ezt a kifejezést, amit elloptam) Természetesen ennek az üzletnek a támogató rendszere szervezetileg és folyamatilag megfelel ennek az üzletnek .
Információs rendszerek üzleti orientációja
Hadd magyarázzam el egy példával. Tegyük fel, hogy van egy üzleti lehetőség pizza értékesítéssel foglalkozó vállalkozás megszervezésére. A V1-es verzióban (nevezzük előinformációnak) a cég pizzéria, pénztárgép, kézbesítő volt. Ez a változat hosszú életű volt alacsony környezeti változékonyság mellett. Aztán a 2-es verzió váltotta fel – fejlettebb, és képes egy monolitikus architektúrájú információs rendszert használni az üzleti életben. És itt, véleményem szerint, egyszerűen szörnyű igazságtalanság van a monolitokkal kapcsolatban - az állítólagos monolitikus architektúra nem felel meg a domain üzleti modelljének. Igen, ha ez így lenne, a rendszer egyáltalán nem működhetne – ellentétben ugyanannak a Conway-törvénynek és a józan észnek. Nem, a monolitikus architektúra teljes mértékben összhangban van az üzleti modellel az üzletfejlesztés ezen szakaszában – természetesen arra a szakaszra gondolok, amikor a rendszert már létrehozták és üzembe helyezték. Teljesen csodálatos tény, hogy az építészeti megközelítéstől függetlenül a szolgáltatás-orientált architektúra 3-as verziója és a mikroszolgáltatás-architektúra N-verziója egyaránt jól fog működni. Mi a fogás?
Minden folyik, minden változik, vagy a mikroszolgáltatások a komplexitás elleni küzdelem eszközei?
Mielőtt folytatnánk, nézzünk meg néhány tévhitet a mikroszolgáltatási architektúráról.
A mikroszolgáltatási megközelítés hívei gyakran azzal érvelnek, hogy a monolit mikroszolgáltatásokra bontása leegyszerűsíti a fejlesztési megközelítést azáltal, hogy csökkenti az egyes szolgáltatások kódbázisát. Véleményem szerint ez a kijelentés teljes hülyeség. Komolyan, a nyilvánvaló kölcsönhatás egy monoliton és homogén kódon belül bonyolultnak tűnik? Ha ez valóban így lenne, akkor kezdetben minden projekt mikroszolgáltatásként épülne fel, miközben a gyakorlat azt mutatja, hogy a monolitról a mikroszolgáltatásokra való átállás sokkal gyakoribb. A komplexitás nem tűnik el, egyszerűen átkerül az egyes modulokból az interfészek (legyen szó adatbuszok, RPC, API-k és egyéb protokollok) és hangszerelő rendszerek felé. És ez nehéz!
A heterogén verem használatának előnye is megkérdőjelezhető. Nem vitatom, hogy ez is lehetséges, de a valóságban ritkán fordul elő (előretekintve - ennek meg kell történnie -, de inkább következményként, mint előnyként).
A termék életciklusa és a szolgáltatás életciklusa
Vessen egy pillantást a fenti diagramra. Nem véletlenül vettem észre egy vállalkozás különálló változatának csökkenő életciklusát - modern körülmények között egy vállalkozás verziók közötti átállásának felgyorsítása a meghatározó a siker szempontjából. Egy termék sikerét az üzleti hipotézisek tesztelésének sebessége határozza meg. És véleményem szerint itt rejlik a mikroszolgáltatási architektúra legfontosabb előnye. De menjünk sorban.
Térjünk át az információs rendszerek fejlődésének következő szakaszára – a SOA szolgáltatás-orientált architektúrájára. Tehát egy bizonyos ponton kiemeltük a termékünkben hosszú élettartamú szolgáltatások - hosszú életű abban az értelemben, hogy egy termék verziói között mozogva fennáll annak az esélye, hogy a szolgáltatás életciklusa hosszabb lesz, mint a termék következő verziójának életciklusa. Logikus lenne, ha egyáltalán nem változtatnánk rajtuk – mi Ami számít, az a következő verzióra való áttérés sebessége. De sajnos kénytelenek vagyunk folyamatosan változtatni a szolgáltatásokon - és itt minden nekünk működik, a DevOps gyakorlatok, a konténerezés és így tovább - minden, ami eszünkbe jut. De ezek még mindig nem mikroszolgáltatások!
Mikroszolgáltatások, mint eszközök a bonyolultság leküzdésére... konfigurációkezelés
És itt végre áttérhetünk a mikroszolgáltatások meghatározó szerepére – ez egy olyan megközelítés, amely leegyszerűsíti a termékkonfiguráció kezelését. Részletesebben, az egyes mikroszolgáltatások funkciója pontosan leírja a terméken belüli üzleti funkciót a domain modell szerint - ezek pedig olyan dolgok, amelyek nem egy rövid életű változatban, hanem egy hosszú életű üzleti lehetőségben élnek. És a termék következő verziójára való áttérés szó szerint észrevétlenül történik - megváltoztatsz/hozzáadsz egy mikroszolgáltatást, és talán csak azok interakciójának sémáját, és hirtelen a jövőben találod magad, maga mögött hagyva síró versenytársakat, akik továbbra is ugrálnak a verziók között. monolitjaikat. Most képzeljük el, hogy meglehetősen nagy mennyiségű mikroszolgáltatás létezik előre meghatározott interfésszel és üzleti lehetőségekkel. Ön pedig jön, és kész mikroszolgáltatásokból építi fel terméke szerkezetét - egyszerűen például egy diagram rajzolásával. Gratulálunk – van platformja –, és most vállalkozást vonzhat magának. Álmok Álmok.
Álláspontja
- A rendszer architektúráját az összetevőinek életciklusa határozza meg. Ha egy komponens egy termékverzión belül él, akkor nincs értelme a rendszer bonyolultságát mikroszolgáltatási megközelítéssel növelni.
- A mikroszolgáltatási architektúra a tartománymodellre kell, hogy épüljön – mivel az üzleti lehetőség a leghosszabb élettartamú tartomány
- A kézbesítési gyakorlatok (DevOps gyakorlatok) és a hangszerelés az egyik legfontosabb a mikroszolgáltatási architektúra számára - azért, mert az összetevők változási ütemének növekedése fokozott követelményeket támaszt a szállítás sebességével és minőségével szemben.
Forrás: will.com