პროგრამული უზრუნველყოფის არქიტექტურა და სისტემების დიზაინი: დიდი სურათი და რესურსების სახელმძღვანელო

გამარჯობა კოლეგებო.

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

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

Კადრი ისააკ სმიტი Unsplash-დან

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

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

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

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

დააყენეთ საწყისი დონე

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

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

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

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

შექმენით ცოდნა მონაცემთა შენახვისა და მოპოვების შესახებ

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

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

Კადრი სამუელ ზელერი Unsplash-დან

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

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

კომუნიკაციის ნიმუშები

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

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

Კადრი ტონი სტოდარდი Unsplash-დან

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

კავშირის განაწილება

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

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

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

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

თქვენ ასევე უნდა იცოდეთ ამის შესახებ შინაარსის მიწოდების ქსელები (CDN). CDN არის პროქსი სერვერების გლობალური განაწილებული ქსელი, რომელიც აწვდის ინფორმაციას კვანძებიდან, რომლებიც გეოგრაფიულად მდებარეობს კონკრეტულ მომხმარებელთან უფრო ახლოს. CDN-ების გამოყენება სასურველია, თუ მუშაობთ JavaScript, CSS და HTML სტატიკურ ფაილებთან. გარდა ამისა, დღეს გავრცელებულია ღრუბლოვანი სერვისები, რომლებიც უზრუნველყოფენ ტრაფიკის მენეჯერებს, მაგალითად, Azure Traffic მენეჯერი, გაძლევთ გლობალურ განაწილებას და შემცირებულ შეყოვნებას დინამიურ კონტენტთან მუშაობისას. თუმცა, ასეთი სერვისები, როგორც წესი, სასარგებლოა იმ შემთხვევებში, როდესაც თქვენ უნდა იმუშაოთ მოქალაქეობის არმქონე ვებ სერვისებთან.

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

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

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

• მყარი პრინციპები
• ცნებები დომენზე ორიენტირებული დიზაინიკერძოდ აგრეგატები, გუნდები და ღონისძიებები
• ექვსკუთხა არქიტექტურა
• პასუხისმგებლობის დაყოფა ბრძანებებად და მოთხოვნებად (CQRS)
• ღონისძიების რეგისტრაცია
• მსახიობი მოდელი
• MVC, MVVM და MVP დიზაინის შაბლონები

თანამშრომლობითი მიდგომები

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

Კადრი კალეიდიკო Unsplash-დან

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

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

წყარო: www.habr.com