როგორ გავაკეთოთ NodeJS აპლიკაცია სერვერზე

იმედი მაქვს, თქვენ გიყვართ Serverless ისევე, როგორც მე, რადგან ეს არის კიდევ ერთი პოსტი იმავე თემაზე.

თუ ეს არის მარტივი REST API სერვერზე ნაკლები, თქვენი დაყენება AWS- ში: Lambda + API Gateway საკმაოდ აშკარაა.

რას იტყვით სხვა (მიკრო) სერვისებზე, რაც თქვენს ბექენდს შეიძლება ჰქონდეს? თქვენ იცით, რომ თქვენი ყველა განაცხადის კოდის ერთი მონოლითური AWS Lambda ფუნქციად შეფუთვა არ არის საუკეთესო იდეა.

Გამოწვევა

ჩვენ გვინდა შემოგთავაზოთ აპლიკაციის მოდულები, უბრალოდ, როგორც სერვერული მიკრო სერვისები, რომლებსაც ასევე უწევთ ერთმანეთთან ურთიერთობა. სერვისებს შორის კომუნიკაცია სასურველია რეგულირდეს ACL ტიპის მიხედვით.

მცდელობა 1. API Gateway

ეს არის პირველი აზრი, რაც პრობლემის გადაჭრისას გამიჩნდა: უბრალოდ გაამჟღავნე ყველა მიკრო სერვისი API Gateway– ის საშუალებით. პრობლემა ისაა ... API- ები, რომლებიც იქმნება, საჯაროა.

რატომ არის ეს პრობლემა? მაგალითად, ჩვენ არ გვინდა, რომ ბილინგის სერვისი ხელმისაწვდომი იყოს მსოფლიოს ნებისმიერ წერტილში, მაშინაც კი, თუ წვდომა შეზღუდულია ავტორიზაციით.

თქვენ შეგიძლიათ API გახადოთ პირადი, მაგრამ უსაფრთხოების მითითებები საკმაოდ შეზღუდულია:

თქვენ შეგიძლიათ გამოიყენოთ API Gateway რესურსების პოლიტიკა, რომ დაუშვას თქვენი API უსაფრთხოდ გამოძახება:
* კონკრეტული AWS ანგარიშის მომხმარებელი * მითითებული წყარო IP მისამართების დიაპაზონი ან CIDR ბლოკები * მითითებული ვირტუალური კერძო ღრუბლები (VPC) ან VPC წერტილების წერტილები (ნებისმიერ ანგარიშში)

ეს საკმაოდ ართულებს ასეთ სერვისებს შორის კომუნიკაციის კონტროლს. ამის გაკეთების ერთადერთი გზაა ცალკეული VPC- ებში სერვისების განთავსება, რაც ძალიან ბევრი შრომაა.

ექსპერიმენტი 2. ლამბდა

რატომ არ ჩავდოთ თითოეული მიკრო მომსახურება ცალკე AWS Lambda- ში? მოაგვარებს ეს პრობლემას?

დიახ, ეს ნამდვილად არის სერვერული მიკროსერვისი და შეგიძლიათ გამოიყენოთ IAM პოლიტიკა, მომსახურების ოპტიმიზაციის მიზნით. ამასთან, ეს არ არის „მარტივი“.

მე ვიცი, რომ ამ დღეებში საკმაოდ ნორმალურია მშობიარობის განყოფილების მცირე როლი. იმ შემთხვევაში, თუ თქვენს სერვისს აქვს ერთზე მეტი საბოლოო წერტილი / მეთოდი / ფუნქცია, კარგია, თუ მას მრავალჯერადი ლამბდა წარმოადგენს.

მე მესმის სარგებელი, მაგრამ თქვენ სწირავთ შენარჩუნებას და განვითარებას. ასევე, მე ნამდვილად არ მომწონს იდეა, რომ მომსახურება გამოვავლინოთ როგორც Lambda ფუნქციების ნაკრები. წარმოიდგინეთ რამდენიმე ცალკეული ფუნქცია, რომლებიც ბილინგს ეხება? ეს აღარ არის შეზღუდული კონტექსტი. მიუხედავად იმისა, რომ არის შემთხვევები, როდესაც ასეთი მარცვლოვნება შეიძლება სასარგებლო იყოს, ეს იშვიათი შემთხვევაა.

სცადეთ 3. მსუქანი ლამბდა

შეგვიძლია რეალურად შემოგთავაზოთ მთელი რიგი წერტილებისა, როგორც ერთი Lambda (რა თქმა უნდა, API კარიბჭის გარეშე)?

თუ ამის გაკეთება შეგვეძლო, სრულად ვისარგებლებდით წინა ვარიანტით, მაგრამ ასევე შეგვეძლო ავირჩიოთ ჩვენი განლაგების ერთეულების გრანულურობა.

აი ის, რაც მე მსურს: ნებისმიერი სერვისი, რომლის განხორციელებაც შეგიძლიათ, უნდა იყოს მარტივი, ძველი JS ობიექტი, მეთოდებით. ამის გაკეთება საკმაოდ მარტივია და დაამატეთ წებოს კოდის რამდენიმე ხაზი თქვენს ობიექტსა და AWS Lambda- ს შორის.

აი, ჩემი განხორციელება: aws-rpc. ეს nodejs მოდული ამჟღავნებს lambdaHandler ფუნქციას, სადაც მხოლოდ ერთ ობიექტს გადიხართ და ის ავტომატურად ხელმისაწვდომი ხდება ყველა მომხმარებლისთვის, ვისაც lambda- ზე წვდომა აქვს:

იმპორტირება {lambdaHandler} 'aws-rpc' -დან; იმპორტირება {TestServiceImpl} - დან './TestServiceImpl';
// ეს არის თქვენი ინსცენირების განყოფილება // ეს არის ის, რასაც თქვენ მიუთითებთ, როგორც lambda დამმუშავებლის ფუნქცია ექსპორტი const handler = lambdaHandler (ახალი TestServiceImpl ());

ახლა თქვენ შეგიძლიათ უბრალოდ მიუთითოთ "დამმუშავებელი", როგორც AWS Lambda. როგორ მოვუწოდებთ მეთოდებს:

იმპორტირება {TestService} - დან './TestService';
const კლიენტი = დაველოდოთ createClient- ს ("LambdaName", "ტესტი"); console.log (დაელოდეთ კლიენტს. ტესტს ());

გთხოვთ გაითვალისწინოთ, რომ იმისათვის, რომ შეძლოთ მეთოდების გენერირება კლიენტის დანიშნულების ობიექტისთვის, თქვენ უნდა გადასცეთ მეთოდის ყველა სახელი, რომ შექმნას Client, როგორც მაგალითად.

ეს აუცილებელია, რადგან JS– ს არ აქვს ინფორმაცია გამეორების შესახებ TypeScript ინტერფეისების შესახებ. აბსტრაქტული კლასებით შემიძლია განვახორციელო, მაგრამ არ მომწონს ¯ \ _ (ツ) _ /.

ბონუსი! ამის გაკეთება შეგიძლიათ ადგილობრივად!

ვფიქრობ, ძალიან მნიშვნელოვანია თქვენი ადგილობრივი განვითარების გარემო მაქსიმალურად კომფორტული იყოს. ამ მიზეზით, მე ასევე დავამატე სერვისისა და კლიენტის ლოკალურად გამოყენების შესაძლებლობა ისე, რომ არ მიმეწოდებინა რაიმე AWS (იხილეთ ფუნქციები runService და createClient) მაგალითები შეგიძლიათ იხილოთ GitHub საცავში.

Შემაჯამებელი

ამის გაკეთება ძალიან მარტივია, როდესაც დაიკარგებით მომსახურებაში, რომელსაც ღრუბლის პროვაიდერები გვთავაზობენ და განახორციელებენ თქვენს ინფრასტრუქტურას.

მე ყოველთვის ვარჩევ იმ უმარტივეს და გარკვეულ გამოსავალს, რაზეც ვფიქრობ. ასევე, ყოველთვის გახსოვდეთ, რომ მრავალი ტექნიკა და პრაქტიკა შეიძლება გამოყენებულ იქნეს სხვა პლატფორმებიდან (თამამი NodeJS Lambda– ს იდეა შთაგონებულია ე.წ. თამამი სათვალეებით ჯავის სამყაროდან).

თუ მოგეწონათ ეს თემა, წაიკითხეთ შემდეგიც:

  • თქვენ უნდა გაიგოთ, თუ როგორ უნდა შექმნათ საუკეთესო სერვერული არქიტექტურა
  • როგორ შევქმნათ უფასო სერვერული CI / CD მილსადენი: 3 მარტივი მაგალითი
  • DynamoDB– ის მარტივი რეპლიკაცია რეგიონებში
  • როგორ შევქმნათ მრავალ რეგიონალური პროგრამა (და გადაიხადე ნული)
  • გახადეთ Java Web App სერვერული

კომენტარები, მოწონებები და გაზიარებები ძალიან დასაფასებელია. ქვედა ზევით!