Hogyan lehet bármilyen NodeJS App kiszolgáló nélküli

Remélem, annyira szereti a Serverless-t, mint én, mert ez egy újabb üzenet a témáról.

Ha most egy egyszerű kiszolgáló nélküli REST API-ról beszélünk, akkor a telepítés teljesen nyilvánvaló az AWS-en: Lambda + API Gateway.

De mi lenne más (mikro) szolgáltatásokkal, amelyek az Ön háttérszínvonala rendelkeznek? Tudod, nem az a legjobb ötlet, ha az összes alkalmazáskódot egyetlen monolit AWS Lambda funkcióba helyezi.

A kihívás

Azt akarjuk, hogy az alkalmazásmodulokat kiszolgáló nélküli mikroszolgáltatásokként könnyen telepítsük, amelyeknek szintén kommunikálniuk kell egymással. A szolgáltatások közötti kommunikációt előnyösen valamilyen ACL-nek kell szabályoznia.

1. kísérlet. API átjáró

Ez az első gondolat, amelyre gondoltam, amikor megpróbáltam megoldani a problémát: tegye ki az összes mikroszolgáltatást az API Gateway segítségével. A probléma az, hogy a létrehozott API-k nyilvánosak.

Miért van ez a probléma? Például, nem akarjuk, hogy egy számlázási szolgáltatás az egész világnak ki legyen téve, még akkor is, ha a hozzáférést valamilyen felhatalmazás korlátozza.

Nos, teheti az API-t magántulajdonossá, de a biztonsági házirendek meglehetősen korlátozottak:

Az API átjáró erőforrás-házirendjei lehetővé teszik az API biztonságos meghívását az alábbiak által:

* egy megadott AWS-fiók felhasználói
* megadott forrás IP-címtartományok vagy CIDR-blokkok
* meghatározott virtuális magán felhők (VPC) vagy VPC végpontok (bármely fiókban)

Ez meglehetősen bonyolultvá teszi az ilyen szolgáltatások közötti kommunikáció ellenőrzését. Ennek egyetlen módja a szolgáltatás külön VPC-kbe helyezése, túl sok munka.

Kísérlet 2. Lambda

Miért nem tesszük minden mikroszolgáltatást külön AWS Lambda-ba? Meg fogja oldani a problémát?

Igen, valójában kiszolgáló nélküli mikroszolgáltatás lesz, és az IAM-házirendekkel képes lesz kiszolgálni a hozzáféréseket a szolgáltatások között, de… ez nem „egyszerű”.

Tudom, hogy manapság ez teljesen normális, ha egy apró funkcióval rendelkezik, mint a telepítési egység. És abban az esetben, ha a szolgáltatásnak egynél több végpontja / módszere / funkciója van, rendben van, ha több Lambda-ként telepíti azt.

Megértem ennek előnyeit, de feláldozza a karbantartás és fejlesztés egyszerűségét. Ezenkívül nem nagyon szeretem azt a gondolatot, hogy egy szolgáltatást a Lambda funkcióinak halmazaként telepítsünk. Képzelje el, hogy több különálló funkció van a számlázással kapcsolatban? Ez már nem korlátozott kontextus. Noha vannak olyan esetek, amikor az ilyen részletesség hasznos lehet, de ez ritka eset.

3. kísérlet. Kövér Lambda

Lehetséges-e a végpontok halmazát egyetlen Lambda-ként telepíteni (természetesen az API átjáró használata nélkül)?

Ha ezt megtennénk, akkor az előző lehetőség minden előnyeit megszerezzük, de ki is választhatjuk telepítési egységeink részletességét.

A következőképpen szeretném: minden telepíthető szolgáltatásnak egyszerű, egyszerű JS objektumnak kell lennie módszerekkel. Ezt nagyon triviális elérni, ha néhány sort ragasztó kódot adunk az objektum és az AWS Lambda közé.

Itt van a megvalósításom: aws-rpc. Ez a nodejs modul lefedi a lambdaHandler funkciót, ahol csak átad egy tárgyat, és automatikusan kitéve mindenki számára, aki hozzáfér a Lambda-hoz:

{lambdaHandler} importálása az 'aws-rpc' -ből;
{TestServiceImpl} importálása a './TestServiceImpl' fájlból;

// ez a telepítési egység
// ezt határozod meg Lambda kezelő funkcióként
export const kezelő = lambdaHandler (új TestServiceImpl ());

Most már csak telepítheti a „kezelőt” AWS Lambda néven. Így hívhatja fel a módszereit:

importáljon {TestService} -et a './TestService' -ből;

const kliens = várjon createClient  ("LambdaName", "test");
console.log (várjon az client.test ());

Felhívjuk figyelmét, hogy ahhoz, hogy módszereket tudjon generálni az ügyfél-csonk objektumhoz, az összes metódusnevet át kell adnia a createClient-hez, ahogy a példában tettük.

Erre azért van szükség, mert a JS-nek nincs futási idejű információja a TypeScript interfészekről. Absztrakt osztályok segítségével tudtam megvalósítani, de ¯ \ _ (ツ) _ / / nem tetszik.

Bónusz! Az egészet helyben futtathatja!

Úgy gondolom, hogy nagyon fontos, hogy a helyi fejlesztési környezet a lehető legkényelmesebb legyen. Ez az oka annak, hogy a szolgáltatást és az ügyfelet lokálisan is futtatom anélkül, hogy bármit telepítenék az AWS-re (lásd a runService és a createClient függvényeket). A példákat lásd a GitHub tárházában.

összefoglalás

Ez nagyon könnyű eltévedni a felhő-szolgáltatók által nyújtott szolgáltatásokban, és megjavítani az infrastruktúráját.

Mindig a legegyszerűbb és legmeghatározóbb megoldást választom, amire gondolok. Ne felejtsd el továbbá, hogy sok technikát és gyakorlatot más platformon is felhasználhatnak (a zsíros NodeJS Lambda ötletét a Java világ úgynevezett zsírsüvegei inspirálják).

Ha tetszett ez a téma, nézd meg ezeket is:

Meg kell tanulnia, hogyan lehet a legjobb kiszolgáló nélküli architektúrát készíteni
Ingyenes kiszolgáló nélküli CI / CD csővezeték létrehozása: 3 egyszerű példa
A DynamoDB egyszerű replikálása a régiók között
Hogyan készíthető többrétegű alkalmazás (és nulla fizetés)
Legyen bármilyen Java Web App kiszolgáló nélküli

Nagyon értékelik a megjegyzéseket, kedveléseket és megosztásokat. Egészségére!

internautasporlapaz.org