Átalakítás lépésről lépésre: strangler fig és anti-corruption layer
Célok
A lecke végére el tudod magyarázni, hogyan lehet egy meglévő rendszert fokozatosan átalakítani, és mi a strangler fig és az anti-corruption layer szerepe ebben.
Miért kell fokozatosan?
Egy összetett rendszer egyszerre történő lecserélése kockázatos, és a közben megálló fejlesztés is költség. A fokozatos átalakítás a működő rendszert nem állítja le, hanem funkciónként teszi át az új szerkezetre. Ugyanez igaz akkor is, ha a cél nem mikroszerviz, hanem például moduláris monolit.
Strangler fig
Martin Fowler 2001-ben látott Queensland esőerdejében strangler fig fákat — olyan fákat, amelyek egy gazdafa repedésében csíráznak, majd saját gyökeret és lombkoronát növesztenek —, és ebből kapta az átalakítási minta nevét. A minta lényege: az új működést a régi mellé kell építeni, és a viselkedést darabonként át kell helyezni, amíg a régi rendszer kivezethető.
Az Azure Architecture Center szerint egy homlokzat (façade, proxy) fogja el a kéréseket, és kezdetben többségüket a régi rendszerhez, később egyre többet az újhoz irányítja. Amikor már semmi nem függ a régitől, azt kivezetik, majd a homlokzatot is eltávolítják vagy meghagyják a régi kliensek számára.
flowchart LR
C["Kliens"] --> F["Homlokzat (routing)"]
F -->|"régi funkciók"| M["Meglévő rendszer"]
F -->|"átvitt funkciók"| N["Új rész"]
M --> O[("Régi adat")]
N --> D[("Új adatgazda")]
Fowler tanácsai: kezdd kicsiben, tisztázd előre az elvárt eredményt, keresd meg azokat a „varratokat”, ahol a rendszer szétvágható, és előbb a kis komponenseket cseréld. Az átmeneti kód extra munka, de csökkenti a kockázatot. A szervezetnek is változnia kell, különben az új rendszer ugyanolyan merev lesz (Conway).
A routing átállítása csak a látható lépés. Az Azure-leírás szerint kezelni kell a régi és az új rendszer által közösen használt adatokat, a homlokzatot nem szabad egyetlen hibapontként vagy szűk keresztmetszetként hagyni, és a rendszerek közötti függéseket is kezelni kell. Különösen veszélyes két független írót létrehozni ugyanarra az üzleti állapotra az átállás alatt.
Anti-corruption layer
Ha az új rész kommunikál a régivel, a régi adatmodell és jelentésrendszer „megrontja” az újat. Az anti-corruption layer (röviden ACL, azaz korrupciót megakadályozó réteg) egy olyan homlokzat vagy adapter a két alrendszer között, amely lefordítja az egyik kéréseit a másik nyelvére. Eric Evans írta le a Domain-Driven Design című könyvében. Az új rendszer a saját modelljén keresztül beszél az ACL-lel, az ACL pedig a régi rendszer modelljén.
Az Azure-leírás szerint az ACL késleltetést és még egy kezelendő komponenst jelent, és el kell dönteni, hogy végleges-e, vagy az átállás végén kivezetik. Csak fordítást végezzen: üzleti szabály vagy vezénylés ne kerüljön bele.
Hogyan viszonyul a többihez?
A fokozatos átalakítás a szétbontás és az összevonás irányában is használható. A strangler fig az útválasztásról szól (belépési pont, 7.6), az ACL a jelentés fordításáról (határ, 1.3). Szolgáltatásra bontás előtt érdemes a modulit lépést megtenni (2.4), mert az feltárja a valódi hívásokat és adatigényeket.
Gyakori tévhitek
Állítás
Pontosítás
„A strangler fig csak a mikroszervizekhez tartozik.”
Bármilyen fokozatos átalakításnál használható.
„Az ACL csak mezőátnevezés.”
A jelentésbeli különbségeket és a hibákat is kezeli.
„Az átállás végén a homlokzat és az ACL mindig eltűnik.”
Meg is maradhatnak a régi kliensek kiszolgálására.
„A szétbontás előtt nincs más teendő.”
Előbb a belső határokat kell tisztázni (2.4).
Röviden
A strangler fig fokozatosan teszi át a funkciókat az új szerkezetre egy homlokzat mögött.
Az ACL lefordítja a két alrendszer modelljét, hogy a régi ne rontsa meg az újat.
Az útvonal átállítása nem azonos az adat átadásával.
Mindkét minta átmeneti infrastruktúrát jelent.
Ellenőrző kérdések
Miért nem elég az útvonalat átállítani egy funkció átvitelekor?
Mi a különbség a homlokzat és az ACL szerepe között?
Miért érdemes a modulitot a szétbontás előtt kialakítani?
Átalakítás lépésről lépésre: strangler fig és anti-corruption layer
Célok
A lecke végére el tudod magyarázni, hogyan lehet egy meglévő rendszert fokozatosan átalakítani, és mi a strangler fig és az anti-corruption layer szerepe ebben.
Miért kell fokozatosan?
Egy összetett rendszer egyszerre történő lecserélése kockázatos, és a közben megálló fejlesztés is költség. A fokozatos átalakítás a működő rendszert nem állítja le, hanem funkciónként teszi át az új szerkezetre. Ugyanez igaz akkor is, ha a cél nem mikroszerviz, hanem például moduláris monolit.
Strangler fig
Martin Fowler 2001-ben látott Queensland esőerdejében strangler fig fákat — olyan fákat, amelyek egy gazdafa repedésében csíráznak, majd saját gyökeret és lombkoronát növesztenek —, és ebből kapta az átalakítási minta nevét. A minta lényege: az új működést a régi mellé kell építeni, és a viselkedést darabonként át kell helyezni, amíg a régi rendszer kivezethető.
Az Azure Architecture Center szerint egy homlokzat (façade, proxy) fogja el a kéréseket, és kezdetben többségüket a régi rendszerhez, később egyre többet az újhoz irányítja. Amikor már semmi nem függ a régitől, azt kivezetik, majd a homlokzatot is eltávolítják vagy meghagyják a régi kliensek számára.
flowchart LR C["Kliens"] --> F["Homlokzat (routing)"] F -->|"régi funkciók"| M["Meglévő rendszer"] F -->|"átvitt funkciók"| N["Új rész"] M --> O[("Régi adat")] N --> D[("Új adatgazda")]Fowler tanácsai: kezdd kicsiben, tisztázd előre az elvárt eredményt, keresd meg azokat a „varratokat”, ahol a rendszer szétvágható, és előbb a kis komponenseket cseréld. Az átmeneti kód extra munka, de csökkenti a kockázatot. A szervezetnek is változnia kell, különben az új rendszer ugyanolyan merev lesz (Conway).
A routing átállítása csak a látható lépés. Az Azure-leírás szerint kezelni kell a régi és az új rendszer által közösen használt adatokat, a homlokzatot nem szabad egyetlen hibapontként vagy szűk keresztmetszetként hagyni, és a rendszerek közötti függéseket is kezelni kell. Különösen veszélyes két független írót létrehozni ugyanarra az üzleti állapotra az átállás alatt.
Anti-corruption layer
Ha az új rész kommunikál a régivel, a régi adatmodell és jelentésrendszer „megrontja” az újat. Az anti-corruption layer (röviden ACL, azaz korrupciót megakadályozó réteg) egy olyan homlokzat vagy adapter a két alrendszer között, amely lefordítja az egyik kéréseit a másik nyelvére. Eric Evans írta le a Domain-Driven Design című könyvében. Az új rendszer a saját modelljén keresztül beszél az ACL-lel, az ACL pedig a régi rendszer modelljén.
Az Azure-leírás szerint az ACL késleltetést és még egy kezelendő komponenst jelent, és el kell dönteni, hogy végleges-e, vagy az átállás végén kivezetik. Csak fordítást végezzen: üzleti szabály vagy vezénylés ne kerüljön bele.
Hogyan viszonyul a többihez?
A fokozatos átalakítás a szétbontás és az összevonás irányában is használható. A strangler fig az útválasztásról szól (belépési pont, 7.6), az ACL a jelentés fordításáról (határ, 1.3). Szolgáltatásra bontás előtt érdemes a modulit lépést megtenni (2.4), mert az feltárja a valódi hívásokat és adatigényeket.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források