Kā padarīt jebkuru NodeJS App bez servera

Es ceru, ka jums patīk Serverless tikpat daudz kā es, jo šī ir vēl viena ziņa par šo tēmu.

Tagad, ja mēs runājam par vienkāršu REST API bez servera, jūsu iestatīšana ir diezgan acīmredzama AWS: Lambda + API Gateway.

Bet kā ar citiem (mikro) pakalpojumiem, kas varētu būt jūsu aizmugures fonā? Jūs zināt, ka nav labākā ideja visu lietojumprogrammas kodu salikt vienā monolītā AWS Lambda funkcijā.

Izaicinājums

Mēs vēlamies ērti izvietot lietojumprogrammu moduļus kā bez serveru mikropakalpojumus, kuriem arī ir jāsazinās savā starpā. Vēlams, lai komunikācija starp pakalpojumiem būtu jāregulē ar kaut kādu ACL.

1. mēģinājums. API vārteja

Šī ir pirmā doma, kas man radās, mēģinot atrisināt problēmu: vienkārši atveriet visus mikropakalpojumus, izmantojot API Gateway. Problēma ir… Izveidotās API ir publiskas.

Kāpēc tā ir problēma? Piemēram, mēs nevēlamies, lai norēķinu pakalpojums būtu pakļauts visai pasaulei, pat ja piekļuve ir ierobežota, izmantojot kāda veida pilnvarojumu.

Jūs varat padarīt API privātu, taču drošības politikas ir diezgan ierobežotas:

Varat izmantot API vārtejas resursu politikas, lai ļautu droši izmantot jūsu API:
* lietotāji no noteikta AWS konta
* norādīti avota IP adrešu diapazoni vai CIDR bloki
* norādīti virtuālie privātie mākoņi (VPC) vai VPC gala punkti (jebkurā kontā)

Tas diezgan apgrūtinoši kontrolē sakarus starp šādiem pakalpojumiem. Vienīgais veids, kā to izdarīt, ir pakalpojumu ievietošana atsevišķos VPC, pārāk daudz darba.

Mēģinājums 2. Lambda

Kāpēc mēs neievietojam katru mikropakalpojumu atsevišķā AWS Lambda? Vai tas atrisinās problēmu?

Jā, patiesībā tas būs bez serveru mikroserviss, un jūs varēsit izmantot IAM politikas, lai noregulētu piekļuvi starp pakalpojumiem, bet… Tas nav “vienkārši”.

Es zinu, ka mūsdienās tas ir diezgan normāli, ka tā ir maza funkcija kā jūsu izvietošanas vienība. Un gadījumā, ja jūsu pakalpojumam ir vairāk nekā 1 parametru / metodi / funkciju, tiek uzskatīts, ka ir ok to izvietot kā vairākas Lambdas.

Es saprotu tā priekšrocības, taču jūs upurējat vieglu apkopi un attīstību. Turklāt man patiešām nepatīk ideja par pakalpojuma ieviešanu kā Lambda funkciju kopu. Iedomājieties, vairākas atsevišķas funkcijas, kas nodarbojas ar rēķinu izrakstīšanu? Tas vairs nav ierobežots konteksts. Lai gan ir gadījumi, kad šāda precizitāte var būt noderīga, taču tas ir reti.

Mēģinājums 3. Tauka Lambda

Vai mēs tiešām varam izvietot parametru kopu kā vienu Lambda (protams, neizmantojot API Gateway)?

Ja mēs to varētu izdarīt, mēs iegūtu visas iepriekšējās iespējas priekšrocības, taču mēs varētu arī izvēlēties savu izvietošanas vienību detalizāciju.

Vēlos, lai tas būtu šāds: katram izvēršamajam pakalpojumam vajadzētu būt vienkāršam, vecam JS objektam ar metodēm. Tas ir diezgan niecīgs, lai sasniegtu, pievienojot dažas līmes koda līnijas starp jūsu objektu un AWS Lambda.

Šeit ir mana tā ieviešana: aws-RPC. Šis nodejs modulis pakļauj funkciju lambdaHandler, kur jūs vienkārši pārvietojaties garām objektam, un tas tiek automātiski pakļauts ikvienam, kurš var piekļūt Lambda:

importēt {lambdaHandler} no 'aws-rpc';
importēt {TestServiceImpl} no './TestServiceImpl';
// šī ir jūsu izvietošanas vienība
// tas ir tas, ko jūs norādāt kā Lambda apstrādātāja funkciju
Export const handler = lambdaHandler (jauns TestServiceImpl ());

Tagad jūs varat vienkārši izvietot “apstrādātāju” kā AWS Lambda. Lūk, kā jūs izmantojat tās metodes:

importēt {TestService} no './TestService';
const client = jāgaida createClient  ("LambdaName", "test");
console.log (gaidiet client.test ());

Lūdzu, ņemiet vērā: lai varētu ģenerēt metodes klienta nepilnīgajam objektam, jums ir jāpāriet visi metožu nosaukumi uz createClient, kā mēs to darījām piemērā.

Tas ir nepieciešams, jo JS nav nekādas runtime informācijas par TypeScript saskarnēm. Es to varētu realizēt, izmantojot abstraktas klases, bet man tas nepatīk ¯ \ _ (ツ) _ / ¯.

Bonuss! To visu var vadīt uz vietas!

Es uzskatu, ka ir ļoti svarīgi, lai vietējā attīstības vide būtu pēc iespējas ērtāka. Tāpēc esmu pievienojis arī iespēju palaist pakalpojumu un klientu lokāli, neko neizvietojot AWS (sk. Funkcijas runService un createClient). Piemērus skatiet GitHub krātuvē.

Kopsavilkums

Tas ir ļoti viegli apmaldīties mākoņu pakalpojumu sniedzēju piedāvātajos pakalpojumos un uzlabot jūsu infrastruktūru.

Es vienmēr izvēlos visvienkāršāko un skaidrāko risinājumu, kādu vien spēju iedomāties. Tāpat vienmēr atcerieties, ka daudzas metodes un praksi var atkārtoti izmantot no citām platformām (tauku NodeJS Lambda ideju iedvesmojuši tā saucamie tauku burciņas no Java pasaules).

Ja jums patika šī tēma, pārbaudiet arī šos:

  • Jums jāiemācās izveidot labāko bezkontakta arhitektūru
  • Bezmaksas bezvada CI / CD cauruļvada izveide: 3 vienkārši piemēri
  • Kā viegli replicēt DynamoDB visos reģionos
  • Kā izveidot vairāku reģionu lietojumprogrammu (un maksāt nulli)
  • Padariet jebkuru Java Web App bez servera

Komentāri, atzīmes Patīk un akcijas tiek augstu novērtētas. Priekā!