Kuidas muuta NodeJS App serverivabaks

Loodan, et te armastate Serverlessi sama palju kui mina, sest see on veel üks selleteemaline postitus.

Kui me räägime lihtsast serverivabast REST API-st, siis on teie häälestamine AWS-is üsna ilmne: Lambda + API Gateway.

Kuidas oleks lood teiste (mikro) teenustega, mis teie taustal võivad olla? Tead, pole kõige parem mõte panna kogu rakenduse kood ühte monoliitsesse AWS Lambda funktsiooni.

Väljakutse

Tahame rakenduse mooduleid hõlpsalt serverita mikroteenustena juurutada, mis peavad samuti omavahel suhtlema. Eelistatavalt peaks teenuste vahelist suhtlust reguleerima mingi ACL.

Katse 1. API-lüüs

See on esimene mõte, mis mul tekkis, kui üritasin probleemi lahendada: paljastage lihtsalt kõik mikroteenused API Gateway kaudu. Probleem on selles, et loodud API-d on avalikud.

Miks see probleem on? Näiteks ei soovi me, et arveldusteenus oleks kogu maailmas nähtav, isegi kui juurdepääsu piiratakse mingisuguse volituse abil.

Noh, saate API muuta privaatseks, kuid turvapoliitika on üsna piiratud:

Saate kasutada API Gateway ressursireegleid, et lubada oma API-l turvaliselt käivitada:
* kasutajad määratud AWS-i kontolt
* määratud allika IP-aadresside vahemikud või CIDR-plokid
* määratletud virtuaalsed privaatpilved (VPC) või VPC lõpp-punktid (mis tahes kontol)

See muudab selliste teenuste vahelise suhtluse juhtimise üsna tülikaseks. Ainus viis siin toimimiseks on teenuste eraldamine eraldi VPC-desse, liiga palju tööd.

Katse 2. Lambda

Miks me ei pane iga mikroteenust lihtsalt eraldi AWS-i lambdasse? Kas see lahendab probleemi?

Jah, tegelikult on see serverita mikroteenus ja saate kasutada IAM-i poliitikat juurdepääsude häälestamiseks teenuste vahel, kuid… see pole “lihtne”.

Ma tean, et see on tänapäeval täiesti tavaline, kui sellel on teie juurutusüksusena väike funktsioon. Ja kui teie teenusel on rohkem kui üks lõpp-punkt / meetod / funktsioon, peetakse seda sobivaks mitme lambdana kasutusele võtta.

Ma mõistan selle eeliseid, kuid te ohverdate hoolduse ja arendamise lihtsuse. Samuti ei meeldi mulle idee teenuse juurutamiseks Lambda funktsioonide komplektina. Kujutate ette, mitu eraldi arveldamisega seotud funktsiooni? See pole enam piiritletud kontekst. Ehkki on juhtumeid, kus selline detailsus võib olla kasulik, kuid see on harv juhtum.

Katse 3. Paks Lambda

Kas me saame rea lõpp-punktide komplekti juurutada ühe lambana (muidugi API Gatewayt kasutamata)?

Kui me saaksime seda teha, saaksime kõik eelmise valiku eelised, kuid saaksime valida ka oma juurutusüksuste detailsuse.

Soovin, et see oleks järgmine: iga juurutatav teenus peaks olema lihtne ja tavaline JS-i meetod koos meetoditega. See on üsna triviaalne, kui lisate oma objekti ja AWS Lambda vahele paar rida liimikoodi.

Siin on minu selle rakendamine: aws-RPC. See nodejs moodul paljastab funktsiooni lambdaHandler, kus te lihtsalt läbite objekti ja see kuvatakse automaatselt kõigile, kellel on juurdepääs Lambdale:

importige {lambdaHandler} kaustast 'aws-rpc';
importige {TestServiceImpl} kaustast ./TestServiceImpl ';
// see on teie juurutusüksus
// seda määrate Lambda käitlejafunktsiooniks
export const handler = lambdaHandler (uus TestServiceImpl ());

Nüüd saate lihtsalt käitleja AWS Lambdana kasutusele võtta. Selle meetodeid saate kasutada järgmiselt:

importige {TestService} kaustast './TestService';
const klient = ootama createClient  ("LambdaName", "test");
console.log (oodake klient.test ());

Pange tähele, et kliendi tübiobjekti jaoks meetodite genereerimiseks peate looma kõik meetodi nimed createClient, nagu me näites tegime.

See on vajalik, kuna JS-il puudub TypeScripti liideste kohta käitusaegne teave. Ma saaksin seda rakendada abstraktsete klasside abil, kuid see ei meeldi mulle ¯ \ _ (ツ) _ / ¯.

Boonus! Saate seda kõike kohapeal käitada!

Usun, et on väga oluline, et teie kohalik arengukeskkond oleks võimalikult mugav. Seetõttu lisasin ka võimaluse teenuse ja kliendi lokaalseks käitamiseks ilma AWS-i midagi juurutamata (vt funktsioone runService ja createClient). Näiteid leiate GitHubi hoidlast.

Kokkuvõte

Pilveteenuse pakkujate pakutavate teenuste ja teie infrastruktuuri ülehindamise kaudu on väga lihtne eksida.

Ma valin alati kõige lihtsama ja selgema lahenduse, millele oskan mõelda. Samuti pidage alati meeles, et paljusid tehnikaid ja tavasid saab kasutada ka teistelt platvormidelt (rasva NodeJS Lambda idee on inspireeritud niinimetatud rasvapurgidest Java-maailmast).

Kui teile see teema meeldis, siis vaadake neid ka:

  • Peate õppima, kuidas luua parimat serverivaba arhitektuuri
  • Tasuta serverivaba CI / CD torujuhtme loomine: 3 lihtsat näidet
  • Kuidas DynamoDB-d hõlpsalt replitseerida kõigis piirkondades
  • Kuidas luua mitut piirkonda hõlmavat rakendust (ja maksta nulli)
  • Muutke mis tahes Java Web App serverita

Kommentaarid, meeldimised ja jagamised on kõrgelt hinnatud. Terviseks!