Ինչպես դարձնել NodeJS հավելվածը առանց սերվերի

Հուսով եմ `դուք սիրում եք Serverless- ը, ինչպես ես, քանի որ սա նույն թեմայի հերթական գրառումն է:

Եթե ​​դա պարզ սերվերներից զուրկ REST API է, ձեր տեղադրումը AWS- ում: Lambda + API Gateway- ը բավականին ակնհայտ է:

Բայց ինչ կասեք ձեր հետամնացության այլ (միկրո) ծառայությունների մասին: Գիտեք, որ ձեր բոլոր դիմումների ծածկագիրը մեկ մոնոլիտ AWS Lambda գործառույթի մեջ փաթաթելը լավագույն գաղափարը չէ:

Մարտահրավեր

Մենք ցանկանում ենք տրամադրել կիրառման մոդուլներ պարզապես որպես սերվեր չունեցող միկրո ծառայություններ, որոնք նույնպես պետք է միմյանց հետ հաղորդակցվեն: Betweenառայությունների միջև հաղորդակցությունը նախընտրելիորեն կարգավորվում է ACL տեսակի միջոցով:

Փորձ 1. API դարպաս

Սա առաջին միտքն է, որ ես ունեցել եմ, երբ փորձում եմ լուծել խնդիրը. Պարզապես բացահայտիր բոլոր միկրոծառայությունները API Gateway- ի միջոցով: Խնդիրն այն է ... ստեղծվող API- ները հանրային են:

Ինչու՞ է դա խնդիր: Օրինակ, մենք չենք ցանկանում, որ բիլինգային ծառայությունը մատչելի լինի աշխարհի ցանկացած կետում, նույնիսկ եթե մուտքը սահմանափակված է թույլտվությամբ:

Դե, դուք կարող եք API- ն դարձնել մասնավոր, բայց անվտանգության ուղեցույցները բավականին սահմանափակ են.

Կարող եք օգտագործել API Gateway ռեսուրսների քաղաքականությունը, որպեսզի ձեր API- ն ապահով կերպով կանչվի ՝
* Հատուկ AWS հաշվի օգտագործող * Նշված աղբյուրի IP հասցեի տիրույթներ կամ CIDR բլոկներ * Նշված վիրտուալ մասնավոր ամպեր (VPC) կամ VPC վերջնակետեր (ցանկացած հաշվի մեջ)

Սա բավականին դժվարացնում է նման ծառայությունների միջև կապի վերահսկումը: Դա անելու միակ միջոցը ծառայություններն առանձին VPC- ներում դնելն է, ինչը չափազանց շատ աշխատանք է:

Փորձ 2. Լամբդա

Ինչու մենք պարզապես յուրաքանչյուր միկրոսպասարկում չենք դնում առանձին AWS Lambda- ի մեջ: Սա կլուծի՞ խնդիրը:

Այո, դա իսկապես սերվերազերծված միկրոծառայություն է, և դուք կարող եք օգտագործել IAM քաղաքականությունը ՝ միջսպասարկային հասանելիությունն օպտիմալացնելու համար: Այնուամենայնիվ, դա «հեշտ» չէ:

Գիտեմ, որ այս օրերին միանգամայն նորմալ է առաքման ստորաբաժանման փոքրիկ դեր ունենալը: Այն դեպքում, երբ ձեր ծառայությունն ունի մեկից ավելի վերջնակետ / մեթոդ / գործառույթ, լավ է այն տրամադրել որպես բազմաթիվ լամբդա:

Ես հասկանում եմ օգուտները, բայց դուք զոհաբերում եք պահպանման և զարգացման դյուրինությունը: Բացի այդ, ինձ շատ դուր չի գալիս ծառայություն մատուցելու գաղափարը ՝ որպես Lambda գործառույթների ամբողջություն: Պատկերացնո՞ւմ եք մի քանի առանձին գործառույթներ, որոնք գործ ունեն բիլինգի հետ: Դա այլևս սահմանափակ ենթատեքստ չէ: Չնայած կան դեպքեր, երբ նման մանրահատկությունը կարող է օգտակար լինել, դա հազվադեպ դեպք է:

Փորձեք 3. Fatարպի Lambda

Կարո՞ղ ենք իրականում մի շարք վերջնակետեր տրամադրել որպես մեկ Lambda (իհարկե առանց API դարպասի):

Եթե ​​մենք կարողանայինք դա անել, մենք լիովին կօգտվեինք նախորդ տարբերակից, բայց կարող էինք նաև ընտրել մեր տեղակայման ստորաբաժանումների մանրակրկիտությունը:

Ահա թե ինչ եմ ուզում տեսնել. Anyանկացած ծառայություն, որը կարող եք իրականացնել, պետք է լինի պարզ, հին JS օբյեկտ ՝ մեթոդներով: Դա անելը բավականին հեշտ է `ավելացնելով մի քանի տող սոսինձի ծածկագիր ձեր օբյեկտի և AWS Lambda- ի միջև:

Ահա դրա իրականացումը ՝ aws-rpc: Այս nodejs մոդուլը բացահայտում է lambdaHandler գործառույթը, որտեղ դուք փոխանցում եք միայն մեկ օբյեկտ, և այն ավտոմատ կերպով հասանելի է դառնում բոլոր օգտվողներին, ովքեր կարող են մուտք գործել lambda.

ներմուծել {lambdaHandler} 'aws-rpc' - ից; Ներմուծեք {TestServiceImpl} - ը './TestServiceImpl- ից';
// սա ձեր բեմական միավորն է // սա այն է, ինչ դուք նշում եք որպես lambda handler function export const handler = lambdaHandler (նոր TestServiceImpl ());

Այժմ դուք կարող եք պարզապես տրամադրել «սպասարկողին» որպես AWS Lambda: Ինչպես անվանել մեթոդները.

Ներմուծեք {TestService} - ը './TestService- ից';
const հաճախորդ = սպասեք createClient- ին («LambdaName», «թեստ»); console.log (սպասեք client.test- ին ());

Խնդրում ենք նկատի ունենալ, որ հաճախորդի համառ օբյեկտի համար մեթոդներ ստեղծելու համար պետք է փոխանցեք բոլոր մեթոդների անունները createClient- ին, ինչպես օրինակ:

Դա անհրաժեշտ է, քանի որ JS- ը չունի ժամանակի տեղեկատվություն TypeScript ինտերֆեյսերի վերաբերյալ: Ես դա կարող էի իրականացնել վերացական դասերով, բայց չեմ սիրում _ \ _ (ツ) _ / ¯:

Բոնուս! Դուք կարող եք ամեն ինչ անել տեղում:

Կարծում եմ ՝ շատ կարևոր է, որ ձեր տեղական զարգացման միջավայրը լինի հնարավորինս հարմարավետ: Այդ պատճառով ես նաև ավելացրել եմ ծառայությունն ու հաճախորդը տեղականում աշխատելու հնարավորությունը ՝ առանց AWS- ի համար որևէ բան տրամադրելու (տես գործառույթները runService և createClient): Օրինակներ կարող եք գտնել GitHub պահոցում:

Ամփոփում

Դա անելը շատ հեշտ է, երբ մոլորվում ես ամպային մատակարարներ առաջարկող ծառայություններում և հիմնովին կապիտալ վերանորոգում քո ենթակառուցվածքը:

Ես միշտ ընտրում եմ ամենապարզ և բացահայտ լուծումը, որը կարող եմ մտածել: Նաև միշտ հիշեք, որ շատ տեխնիկա և պրակտիկա հնարավոր է նորից օգտագործել այլ հարթակներից (համարձակ NodeJS Lambda- ի գաղափարը ոգեշնչված է այսպես կոչված համարձակ ակնոցներով worldավա աշխարհից):

Եթե ​​ձեզ դուր եկավ այս թեման, կարդացեք նաև հետևյալը.

  • Դուք պետք է սովորեք, թե ինչպես կարելի է կառուցել սերվերների լավագույն ճարտարապետությունը
  • Ինչպե՞ս կառուցել անվճար սերվերային CI / CD խողովակաշար. 3 պարզ օրինակ
  • DynamoDB- ի հեշտ կրկնօրինակումը մարզերում
  • Ինչպես կառուցել բազմատարածաշրջանային ծրագիր (և վճարել զրո)
  • Java Web App- ը դարձնել առանց սերվերի

Մեկնաբանությունները, հավանումներն ու տարածումները շատ գնահատելի են: Ներքևից վերև: