Hogyan kösd össze a széttagolt rendszereket: integrációs és API-stratégia útmutató

A széttagolt rendszerek összekötése a tulajdonlással, a határokkal és az információáramlással kezdődik – nem egy integrációs eszköz kiválasztásával. Mielőtt bármilyen technológiát választanál, a működésnek meg kell tudnia mondani, hogy melyik rendszer felelős melyik adatért, hol lép be és ki az adat az egyes rendszerek határán, és mi történjen, ha egy átadás meghiúsul. A homályos tulajdonlásra és elmosódott határokra épülő integráció adatot mozgat olyan rendszerek között, amelyek ettől még nem viselkednek egy rendszerként. Hogy mi az összefüggő üzleti rendszer, azt az üzleti rendszerekről szóló útmutató (/resources/mit-tartalmaznak-az-uzleti-rendszerek) tárgyalja; ez az útmutató a megvalósítási mélység: hogyan tervezd meg a határokat és az információáramlást a már meglévő rendszerek között.

Kezdd a működési folyamattal, ahogy ma fut: az érintett rendszerekkel, azokkal, akik kezelik őket, azokkal az adatokkal, amelyek átlépik az egyes rendszerek határát, azokkal az állapotváltozásokkal, amelyeken egy rekord átmegy, azokkal az emberi jóváhagyásokkal, amelyek a folyamathoz tartoznak, és azokkal a külső függőségekkel, amelyeket a folyamat érint. A térkép a működés nyelvén készül, mielőtt bármilyen integrációs formát választanál. Célja nem az öncélú dokumentáció – a térkép az egyetlen megbízható alap annak eldöntéséhez, hogy mely adatoknak kell mozogniuk, ki felelős értük, és mi történjen, ha egy lépés meghiúsul.

Minden kulcsadathalmaznak legyen egy System of Record-ja – az a rendszer, amely az adatra nézve mérvadó. Az ügyfél, a megrendelés, a számla, a foglalás, a ticket és a raktári cikk tipikus példák: mindegyik egy rendszerhez tartozik forrásként, míg más rendszerek csak hivatkozást tárolnak róla. Ezek illusztratív kategóriák, nem pedig előírás arra, hogy melyik termék miért feleljen. A döntés az elszámoltathatóságról szól: ha két rendszer ellentmond egy megrendelésben, valakinek meg kell tudnia mondani, melyik változat az irányadó.

A rendszerhatár azt nevezi meg, mit birtokol egy rendszer, és mit nem. A megrendeléseket birtokló rendszer nem duplikálja az ügyfélnyilvántartást, és a számlázó rendszer sem tart fenn saját másolatot a megrendelésről. A homályos határok szinkronizációs problémákat okoznak, mert minden megduplázott tényt örökre összhangban kell tartani – integrációval, batch-sel vagy kézzel –, és minden összehangolási mechanizmus előbb-utóbb meghiúsul. A határ nem fal; megnevezett felelősség, és a rajta átlépő adat meghatározott módon mozog.

Nincs univerzális integrációs forma. A közvetlen pont-pont kapcsolatok kevés, stabil kapcsolat esetén működnek. A közös integrációs vagy szolgáltatási réteg központosítja a szerződéseket, ha több rendszer ugyanazon szabályok szerint cserél adatot. Az eseményvezérelt átadás lehetővé teszi, hogy az egyik rendszer közzétegye a változásokat, a többiek pedig aszinkron reagáljanak. Az ütemezett batch-szinkronizáció azokhoz az adatokhoz illik, amelyek elviselik az időszakos összehangolást. A kontrollált kézi határ legitim választás, ha az átadás ritka, ítéletet igényel, vagy túl nagy következménnyel jár az automatizáláshoz. A helyes forma a folyamatból, az adatokból, az időzítési követelményekből és a hiba következményeiből következik – nem a divatból.

Az API szerződés a határolt rendszerek között: explicit bemenetek, explicit kimenetek, stabil szemantika és definiált mód a hibajelzésre. A szerződéseknek stabilnak kell maradniuk, a változásnak tudatos verzió- vagy változáshatáron kell átmennie, és a hibasemantikát le kell írniuk, ahelyett hogy a meghiúsulást a véletlenre bíznák. Az azonosítás és az engedélyezés fogalmilag a szerződés része – ki mit hívhat meg –, de a stratégiai pont az, hogy a szerződés létezik, dokumentált, és gazdája van. Ez stratégiai útmutató, nem API-oktatóanyag: azok a döntések számítanak, hogy a szerződést megnevezed, stabilan tartod, és a hibáit láthatóvá teszed.

Minden integráció egy irányba mozgat adatot, és az iránynak explicitnek kell lennie: melyik rendszer az egyes mezők forrása, mi indítja a szinkronizációt, és mi történik, ha ugyanazt a rekordot két helyre írják. A duplikált írások és az eseti inkonzisztencia a valódi rendszerekben normális; az számít, hogy tervezve legyenek, ne felfedezve. Az újrapróbálkozás és az idempotencia teszi biztonságossá az ismételt kísérleteket – egy újra futtatható lépésnek ártalmatlannak kell lennie többszöri végrehajtás esetén is. A kiegyenlítés (reconciliation) – annak összevetése, amit a rendszerek ténylegesen tárolnak – teszi láthatóvá a csendes eltérést.

Az elosztott folyamatok részben meghiúsulnak: az első rendszer elfogadta a változást, a második nem. A stratégiának el kell döntenie, mi történik ebben a pillanatban – még mielőtt bekövetkezne. Korlátos számú újrapróbálkozás, a hiba láthatóvá tétele azok számára, akik tudnak lépni, és a befejezhetetlen munka eljuttatása egy olyan helyre, ahol ember oldja meg – a dead-letter vagy manuális feldolgozási sor a koncepció, nem egy konkrét termék. A csendes meghiúsulás nem elfogadható: a némán elbukó átadás mindkét rendszer képét megrontja az igazságról. Amit megkíséreltek, ami meghiúsult, és ahogyan megoldották, annak visszakövethetőnek kell lennie.

Az integráció azt jelenti, hogy a rendszerek információt és állapotot cserélnek; az automatizálás azt, hogy a folyamatlépéseket csökkentett emberi közreműködéssel indítják és hajtják végre. Két különböző kérdésről van szó, amelyeket gyakran összekevernek. Egy folyamat igényelhet integrációt automatizálás nélkül – a rendszerek tisztán cserélik az adatot, miközben az emberek döntik el és hajtják végre a következő lépéseket. És egy folyamat automatizálható sok integráció nélkül is, ha egy rendszeren belül fut. A kettő szétválasztása őszintén tartja a beszélgetést: arra a kérdésre, hogyan cserélnek ezek a rendszerek adatot, előbb kell válaszolni, mint arra, hogy mely lépések futhatnak automatikusan – ezt a kérdést a munkafolyamat-automatizálás prioritási útmutatója (/resources/mit-automatizaljunk-eloszor) tárgyalja részletesen.

Egyedi integrációs fejlesztésre akkor van szükség, ha a használt termékek meglévő API-jai, csatlakozói és konfigurációja nem tudják teljesíteni a szükséges szerződést – az adatmozgást, az átalakítást, a hibakezelést vagy az időzítést. A válasz egy határolt egyedi integráció: egy kicsi, saját réteg, amely pontosan a hiányzó szerződést valósítja meg, és semmi többet – nem pedig csere-rendszer. Azt, hogy egy építés egyáltalán indokolt-e, az egyedi szoftver döntési kerete (/resources/mikor-erdemes-egyedi-szoftvert-fejleszteni) dönti el; az integrációs stratégia csak az egyedi rész határát határozza meg.

Ellenőrizetlen pont-pont kapcsolatok, amelyek tervezés nélkül nőnek.

Több csatlakozóban megduplázott üzleti logika, így egy szabályváltozást mindenhol el kell végezni.

Körkörös függőségek, ahol az A rendszer B-re vár, B C-re, C pedig A-ra.

Homályos adattulajdonlás, így minden rendszer azt hiszi, ugyanazt a rekordot birtokolja.

Rejtett átalakítások, ahol az adatot csendben formálják át rendszerek között, és senki sem emlékszik rá, hol.

Törékeny szinkron láncok, ahol egy lassú vagy meghiúsuló lépés az egész folyamatot blokkolja.

A válasz nem automatikusan a microservice- vagy eseményvezérelt architektúra. A válasz a tervezés: megnevezett határok, gazdával rendelkező szerződések és explicit hibakezelés – akár egy csatlakozóról, akár húszról van szó.

Kétértelmű kivételek, amelyeket egyetlen szabály sem tud előre leírni.

Visszafordíthatatlan vagy nagy következménnyel járó műveletek, például kifizetés, kimenő kommunikáció vagy rekordok törlése.

Ellentmondó rekordok, amikor két rendszer ugyanazon tény különböző változatát tárolja, és egy embernek kell eldöntenie, melyik a helyes.

Meghiúsult kiegyenlítés, amikor az automatikus összevetés olyan eltérést talál, amelyet nem lehet automatikusan feloldani.

A küszöb a következmény, nem a mennyiség: az emberi kontrollpontok oda tartoznak, ahol tévedni drága – nem oda, ahol a rendszer elfoglalt.

Melyik rendszer az egyes mozgó adathalmazok System of Record-ja?

Mire van valóban szüksége a fogadó rendszernek, és mi az a minimális adatmennyiség, amely kielégíti?

Mikor lehet az adatcsere esetileg inkonzisztens, és mikor kell pontosnak lennie?

Mi történik, ha egy átadás meghiúsul – ki látja, és ki oldja meg?

Minden lépés biztonságosan megismételhető-e, és ártalmatlan-e a kétszeri kézbesítés?

Ki a szerződés gazdája mindkét oldalon, és hogyan kerülnek felülvizsgálatra a változások?

A folyamat mely részei maradnak emberi kontroll alatt, és miért?

Hogyan figyelik az integrációt, és hogyan érzékelik és egyenlítik ki az eltéréseket?

Az integrációs architektúra akkor sikeres, ha csökkenti a működési széttagoltságot: ha a rendszerek a megfelelő információt a megfelelő irányban cserélik, ha a hibák láthatók és megoldhatók, és ha egy ember meg tudja nevezni, mi kié. Eszközöket struktúra nélkül összekötni csak hatékonyabbá teszi a széttagoltságot – ugyanaz a megduplázott adat, ugyanaz a homályos tulajdonlás, csak gyorsabban mozog. A jó integrációs stratégia próbája nem az, hány rendszert kötöttek össze. Hanem az, hogy a működés ezután inkább egy rendszerként viselkedik-e.