NGINX-ის თანამედროვე აპლიკაციების შემუშავების პრინციპები. Ნაწილი 1

გამარჯობა მეგობრებო. კურსის დაწყების მოლოდინში PHP backend დეველოპერი, ტრადიციულად გაგიზიარებთ სასარგებლო მასალის თარგმანს.

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

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

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

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

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

ამ პრინციპების გამოყენებით, თქვენ ისარგებლებთ პროგრამული უზრუნველყოფის განვითარების უახლესი ტენდენციებით, მათ შორის DevOps აპლიკაციების შემუშავებასა და მიწოდებაზე, კონტეინერების გამოყენებაზე (მაგალითად, docker) და კონტეინერის ორკესტრირების ჩარჩოები (მაგალითად, კუბერნეტები), მიკროსერვისების გამოყენება (მათ შორის Microservice Architecture). NGINX и ქსელური კომუნიკაციის არქიტექტურა მიკროსერვისის აპლიკაციებისთვის.

რა არის თანამედროვე აპლიკაცია?

თანამედროვე აპლიკაციები? თანამედროვე დასტა? კონკრეტულად რას ნიშნავს "თანამედროვე"?

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

თანამედროვე აპი მხარს უჭერს მრავალ კლიენტს, იქნება ეს React JavaScript ბიბლიოთეკის მომხმარებლის ინტერფეისი, Android ან iOS მობილური აპი, თუ აპი, რომელიც უკავშირდება სხვა API-ს. თანამედროვე აპლიკაცია გულისხმობს კლიენტების განუსაზღვრელ რაოდენობას, რომლებისთვისაც ის უზრუნველყოფს მონაცემებს ან მომსახურებას.

თანამედროვე აპლიკაცია უზრუნველყოფს API-ს მოთხოვნილ მონაცემებსა და სერვისებზე წვდომისათვის. API უნდა იყოს უცვლელი და მუდმივი და არ იყოს დაწერილი კონკრეტულად კონკრეტული კლიენტის მოთხოვნისთვის. API ხელმისაწვდომია HTTP(S)-ით და უზრუნველყოფს წვდომას GUI-ში ან CLI-ში არსებულ ყველა ფუნქციაზე.

მონაცემები ხელმისაწვდომი უნდა იყოს საყოველთაოდ მიღებულ, თავსებადობის ფორმატში, როგორიცაა JSON. API ავლენს ობიექტებს და სერვისებს სუფთა, ორგანიზებული გზით, როგორიცაა RESTful API ან GraphQL, უზრუნველყოფს ღირსეულ ინტერფეისს.

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

ამ ტიპის სტეკის პოპულარული ვერსიები ეფუძნება Java, Python, Node, Ruby, PHP и Go. მიკროსერვისის არქიტექტურა NGINX წარმოადგენს თითოეულ აღნიშნულ ენაზე განხორციელებული თანამედროვე სტეკის მაგალითს.

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

პრინციპები

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

ერთ-ერთი პრინციპი ჟღერს, როგორც "პატარა აპლიკაციების გაკეთება", მოდით უბრალოდ დავარქვათ სიმცირის პრინციპი. არსებობს წარმოუდგენლად რთული აპლიკაციები, რომლებიც შედგება მრავალი მოძრავი ნაწილისგან. თავის მხრივ, აპლიკაციის აგება მცირე, დისკრეტული კომპონენტებისგან აადვილებს მის დიზაინს, შენარჩუნებას და მუშაობას მთლიანობაში. (გაითვალისწინეთ, რომ ჩვენ ვთქვით "ამარტივებს" და არა "ამარტივებს").

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

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

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

მოდით განვიხილოთ ეს სამი პრინციპი უფრო დეტალურად.

სიმცირის პრინციპი

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

აპლიკაციები იშლება შემდეგი მიზეზების გამო:

• შემცირებული შემეცნებითი დატვირთვა დეველოპერებზე;
• ტესტირების დაჩქარება და გამარტივება;
• განაცხადში ცვლილებების სწრაფი მიწოდება.

დეველოპერებზე შემეცნებითი დატვირთვის შემცირების რამდენიმე გზა არსებობს და სწორედ აქ მოქმედებს სიმცირის პრინციპი.

ასე რომ, აქ არის სამი გზა შემეცნებითი დატვირთვის შესამცირებლად:

1. შეამცირეთ დრო, რომელიც მათ უნდა გაითვალისწინონ ახალი ფუნქციის შემუშავებისას - რაც უფრო მოკლეა დრო, მით ნაკლებია შემეცნებითი დატვირთვა.
2. შეამცირეთ კოდის რაოდენობა, რომელზეც ტარდება ერთჯერადი სამუშაო - ნაკლები კოდი - ნაკლები დატვირთვა.
3. განაცხადში დამატებითი ცვლილებების შეტანის პროცესის გამარტივება.

განვითარების დროის ჩარჩოს შემცირება

დავუბრუნდეთ იმ დღეებს, როდესაც მეთოდოლოგია waterfall იყო განვითარების პროცესის სტანდარტი და აპლიკაციის შემუშავების ან განახლებისთვის ექვსი თვიდან ორ წლამდე ვადები ჩვეულებრივი პრაქტიკა იყო. როგორც წესი, ინჟინრები ჯერ წაიკითხავენ შესაბამის დოკუმენტებს, როგორიცაა პროდუქტის მოთხოვნები (PRD), სისტემის საცნობარო დოკუმენტი (SRD), არქიტექტურის გეგმა და დაიწყებენ ამ ყველაფრის გაერთიანებას ერთ კოგნიტურ მოდელში, რომლის მიხედვითაც ისინი კოდირებულნი არიან. მოთხოვნები და, შესაბამისად, არქიტექტურა შეიცვალა, სერიოზული ძალისხმევა იყო საჭირო, რომ მთელი გუნდი ეცნობებინა კოგნიტური მოდელის განახლებების შესახებ. ასეთმა მიდგომამ, უარეს შემთხვევაში, შეიძლება უბრალოდ პარალიზება მოახდინოს სამუშაოზე.

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

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

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

მცირე კოდების ბაზები

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

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

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

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

მცირე დამატებითი ცვლილებები

პრინციპის ბოლო ელემენტი სიმცირე არის ცვლილებების მართვა. დეველოპერებისთვის განსაკუთრებული ცდუნებაა, გადახედონ კოდების ბაზას (თუნდაც, შესაძლოა, საკუთარ, ძველ კოდს) და თქვან: „ეს სისულელეა, ჩვენ უნდა გადავწეროთ ეს ყველაფერი“. ზოგჯერ ეს სწორი გადაწყვეტილებაა და ზოგჯერ არა. ის აკისრებს გლობალური მოდელის ცვლილების ტვირთს განვითარების გუნდს, რაც თავის მხრივ იწვევს მასიური შემეცნებით დატვირთვას. უმჯობესია ინჟინრებმა ყურადღება გაამახვილონ ცვლილებებზე, რომლებსაც შეუძლიათ სპრინტის დროს განახორციელონ, რათა დროულად განავითარონ საჭირო ფუნქციები, თუმცა თანდათანობით. საბოლოო პროდუქტი უნდა წააგავდეს წინასწარ დაგეგმილს, მაგრამ გარკვეული ცვლილებებითა და ტესტირებით კლიენტის საჭიროებებზე.

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

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

1. გამოიყენეთ მეთოდოლოგია agileშეზღუდოს დრო, რომელშიც გუნდმა ყურადღება უნდა გაამახვილოს ძირითად მახასიათებლებზე.
2. განახორციელეთ თქვენი განაცხადი, როგორც მრავალი მიკროსერვისი. ეს შეზღუდავს ფუნქციების რაოდენობას, რომლებიც შეიძლება განხორციელდეს და გააძლიერებს საზღვრებს, რომლებიც ინარჩუნებენ კოგნიტურ დატვირთვას.
3. უპირატესობა მიანიჭეთ მატულ ცვლილებებს დიდსა და უხერხულზე, შეცვალეთ კოდის მცირე ნაწილები. გამოიყენეთ დამალვის ფუნქცია ცვლილებების განსახორციელებლად, მაშინაც კი, თუ ისინი არ იქნება ხილული მათი დამატებისთანავე.

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

პირველი ნაწილის დასასრული.

მალე გამოვაქვეყნებთ თარგმანის მეორე ნაწილს, ახლა კი ველოდებით თქვენს კომენტარებს და გეპატიჟებით ღია დღე, რომელიც დღეს 20.00:XNUMX საათზე გაიმართება.

წყარო: www.habr.com