A middleware a webfejlesztésben általánosan használt kifejezés. A szövegkörnyezettől függően sok mindent jelenthet, ami kissé zavarossá teszi a kifejezést.
Ebben a cikkben a fogalom meghatározásával kezdjük, majd folytatjuk a vita tárgyát a különböző felhasználási esetekről.
A cikk elolvasása után jobban részt vehet társaival folytatott műszaki és építészeti beszélgetésekben. Ön képes lesz arra is, hogy biztonságos és megbízható API-kat és adatfolyamokat tervezzen.
A Middleware meghatározása
A middleware olyan szoftver, amely két alkalmazás vagy szolgáltatás között közvetítőként működik, megkönnyítve azok kommunikációját.
Úgy gondolhat rá, mint egy proxy, amely adatgyűjtőként, fordítóként vagy egyszerűen csak a kérelmeket továbbító proxy-ként működhet.
Közönséges esetek a köztes szoftverekhez
1) Fordító
Számos adatcsere-formátum létezik, például JSON, XML és Protobuf. Annak ellenére, hogy manapság leginkább a JSON-t használjuk, mindegyiknek megvan a maga használati esete.
Például a Protobuffer-ekről ismert, hogy jobban teljesítenek, mint a JSON, de nem olvashatók emberben. Tehát előfordulhat, hogy Protobuffereket használ belső szolgáltatásokhoz, és akkor használhatja a JSON-ot, ha az API-felhasználó böngésző.
Megtekintheti a Protobuffers-ről szóló cikkemet is, ha többet szeretne megtudni róluk.
Tegyük fel, hogy szükségünk van erre a két szolgáltatásra, amelyek különböző protokollokat beszélnek, hogy kommunikáljanak egymással.
Hozhatunk létre egy köztes szoftvert, amely adatkonvertáló könyvtárat használ, és a kéréseket olyan formátumra fordítja, amelyet a fogadó szolgáltatás érthet.
2) Adatok felhalmozása-másolása
A Microservice architektúra egy népszerű építészeti minta, amelyet gyakran alkalmaznak a modern alkalmazásokban.
Ha még nem ismeri a mikroszolgáltatások architektúráját, az alapvetően azt jelenti, hogy az alkalmazás sok kicsi alkalmazásból vagy szolgáltatásból áll, amelyek egymástól függetlenek és az interneten keresztül kommunikálva működnek együtt.
Például egy e-kereskedelmi projektben rendelkezhet mikroszolgáltatással a termékek tárolására és visszakeresésére, egy másik mikroszolgáltatására keresésre, és egy másikra a felhasználók hitelesítésére és tárolására. És mindegyiknek megvan a saját adatbázisa.
Most tegyük fel, hogy a keresésünket úgy akarjuk megvalósítani, hogy a felhasználókra és a termékekre egyaránt keressen.
Ha ez egy monolit alkalmazás volt, akkor egyszerűen írhatunk egy lekérdezést az egyes táblák keresésére és az eredmények összekapcsolására. De most az adatbázisunk különböző szervereken fut.
Ennek a problémának több megoldása van, és kettőt fogunk megvizsgálni.
Adatok felhalmozása
Középprogram segítségével mindkét szerverre kéréseket küldhetünk, és megkérhetjük őket, hogy az adatbázisukban keressék meg a keresett szónak megfelelő felhasználói neveket és termékeket.
Ezután mindkét szerverről gyűjthetjük az eredményeket, és visszaadhatjuk azokat az ügyfélnek. Ne feledje, hogy a kérések száma lineárisan növekszik a kiszolgálók számának növekedésével (és ezeket az adatokat is össze kell egyesítenünk).
Adatok másolása
Ismétlődő adatokat tárolhatunk keresési szerverünkön, így közvetlenül kereshet rájuk, ahelyett, hogy termék- és felhasználói kiszolgálóktól kérne. Ez a memória szempontjából kevésbé hatékony, de sokkal gyorsabb - és a sebesség kritikus a keresési szolgáltatások szempontjából.
Ha a szükséges táblázatok Termék és Felhasználó, akkor ezeket a táblákat létrehozhatjuk keresési szerverünkön is. Ezután, amikor új felhasználót mentünk a felhasználói adatbázisunkba, egy példányt is mentünk a keresőkiszolgálóra.
Pár lehetőségünk van: először hívhatjuk a keresőkiszolgáló mentési metódusait a Felhasználói és Termékkiszolgálók mentési módszereiből az adatok másolásához. Vagy létrehozhatunk egy köztes szoftvert a mentéshez, amely a következőket fogja tenni:
- Amikor mentési kérelem érkezik, hívja meg a Termék / Felhasználó szerver mentését és a Keresési szerver mentését.
- Ha az első mentés sikertelen, akkor ne hívja a másikat (ezzel az adatbázisok következetesek maradnak).
Nézzük meg a tervdiagramokat köztes szoftver nélkül. Először így néz ki anélkül, hogy:
Csúnyán néz ki, igaz? Valóban, csúnya, és bonyolultabbá és szorosabban összekapcsolja a kódot.
Itt van ugyanaz a megoldás egy köztes szoftverrel:
Ebben a forgatókönyvben az ügyféloldal csak felhívja a köztes szoftvert, hogy mentse a terméket vagy a felhasználót, és a többi kezeli.
Nincs kód az adatok másolásához a termék- vagy a felhasználói kiszolgálókon vagy az ügyféloldalon. A Middleware gondoskodik ezekről a dolgokról.
3) API biztonság
Bármely elülső ügyféloldali kód esetében megtekinthetjük a kimenő kéréseket, akár a böngésző konzolján, akár egy proxy segítségével.
Beszéltünk egy felhasználói szerverről, amely gondoskodik a bejelentkezésről és a regisztrációról. Ha kezelői kódunk közvetlenül elküldi a kéréseket az adott kiszolgálónak, akkor a hitelesítési szerverünk címe ki lesz téve. Miután megtanulta a háttérprogramunk IP-címét, a támadók eszközök segítségével megkereshetik a végpontjainkat, és kiszolgálókon kereshetnek sérülékenységeket.
Közepes szoftvert használhatunk proxyként a hitelesítési szerver URL-jének elrejtésére. Kezelőfelületünk kommunikál a köztes szoftverrel, és továbbítja a kérést a hitelesítési szervernek, és visszaadja a választ.
Ez a megközelítés azt is lehetővé teszi, hogy blokkoljunk minden kérést a hitelesítési szerverünkhöz, kivéve a köztes szoftverünk URL-jéből érkező kéréseket. Ez sokkal biztonságosabbá teszi hitelesítési szerverünket.
Ez korábban nem volt lehetséges, mert a kezelőfelületünk kommunikált a hitelesítési szerverrel. Mivel a kezelőfelület az ügyfél számítógépét jelenti, nem tudtunk IP-szűrőt alkalmazni.
4) Nyilvános API-k bemutatása
Az előző részben megtudtuk, hogy a köztes eszközökkel korlátozható az API-hoz való hozzáférés.
Most nézzük meg az egyenlet másik oldalát: Mi van, ha korlátozott hozzáférést akarunk biztosítani az API-hoz? Talán egy szoftver szoftvermérnöke vagyunk, és a bank hackathont tervez. Hozzáférést kellene biztosítanunk az API-hoz, igaz?
De mivel bank vagyunk, természetesen nem tudunk hozzáférést biztosítani a teljes API-hoz, és nem engedhetünk meg minden műveletet. Ez azt jelenti, hogy meg kell találnunk a korlátozott hozzáférés biztosításának módját.
Erre a célra megvalósíthatunk egy köztes szoftvert, amely csak a végpontok egy részét tárja fel, és a kéréseket átirányítja a tényleges API-ra. Ezután megadjuk ezt az API-t a fejlesztőknek a hackathonon.
Következtetés
Ebben a bejegyzésben azzal kezdtük, hogy meghatározzuk, mi is a köztes szoftver, és megpróbáltuk kategorizálni a köztes eszközök webes fejlesztési eseteit.
Ne feledje, hogy ez nem a felhasználási esetek teljes listája, de remélem, hogy hasznos volt Önnek.
Köszönöm, hogy elolvasta. Ha tetszett a cikk, meghívlak, nézd meg a blogomat. Feliratkozhat a levelezőlistámra is, hogy értesítést kapjon, amikor új bejegyzést teszek közzé :)