ჰეი ჰაბრ!

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

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

ჰორიზონტალური მასშტაბირება

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

მაგალითად, მე ავიღებ აბსტრაქტულ ღრუბლოვან ფაილებს, ანუ OwnCloud-ის, OneDrive-ის და ა.შ.

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

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

CQRS

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

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

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

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

1. კლიენტმა გამოიწერა განახლებები.
2. კლიენტმა გაგზავნა მოთხოვნა სერვერზე.
3. სერვერმა უპასუხა "მოთხოვნა მიღებულია".
4. სერვერმა უპასუხა შედეგს არხის მეშვეობით „1“ წერტილიდან.

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

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

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

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

ღონისძიების დაფინანსება

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

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

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

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

ამ მიდგომის მნიშვნელოვანი მახასიათებლები:

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

შეგახსენებთ, რომ განვიხილავთ ფაილების ონლაინ შენახვის საქმეს. ამ შემთხვევაში, სისტემა ასე გამოიყურება:

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

და ორი მომხმარებლისთვის დიაგრამა ასე გამოიყურება (სხვადასხვა მომხმარებლისთვის განკუთვნილი სერვისები მითითებულია სხვადასხვა ფერში):

ბონუსები ასეთი კომბინაციიდან:

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

თუმცა, უარყოფითი მხარეები დაუყოვნებლივ ჩანს:

• ჩვენმა სისტემამ დაკარგა მკაცრი თანმიმდევრულობა. ეს ნიშნავს, რომ თუ, მაგალითად, გამოიწერთ სხვადასხვა სერვისებს, მაშინ თეორიულად შეგიძლიათ მიიღოთ განსხვავებული მდგომარეობა (რადგან ერთ-ერთ სერვისს შეიძლება არ ჰქონდეს დრო, რომ მიიღოს შეტყობინება შიდა რიგიდან). კიდევ ერთი შედეგი, სისტემას ახლა საერთო დრო არ აქვს. ანუ, შეუძლებელია, მაგალითად, ყველა მოვლენის დალაგება უბრალოდ ჩამოსვლის დროით, რადგან სერვერებს შორის საათები შეიძლება არ იყოს სინქრონული (უფრო მეტიც, ორ სერვერზე ერთი და იგივე დრო უტოპიაა).
• არცერთი მოვლენის უბრალოდ უკან დაბრუნება შეუძლებელია (როგორც შეიძლება გაკეთდეს მონაცემთა ბაზის საშუალებით). ამის ნაცვლად, თქვენ უნდა დაამატოთ ახალი მოვლენა − კომპენსაციის ღონისძიება, რომელიც შეცვლის ბოლო მდგომარეობას საჭიროზე. მაგალითად მსგავსი სფეროდან: ისტორიის გადაწერის გარეშე (რაც ზოგ შემთხვევაში ცუდია), თქვენ არ შეგიძლიათ დააბრუნოთ commit in git, მაგრამ შეგიძლიათ გააკეთოთ სპეციალური rollback commit, რომელიც არსებითად უბრალოდ უბრუნებს ძველ მდგომარეობას. თუმცა, როგორც არასწორი ჩადენა, ასევე უკან დაბრუნება ისტორიაში დარჩება.
• მონაცემთა სქემა შეიძლება შეიცვალოს გამოშვებიდან გამოშვებამდე, მაგრამ ძველი მოვლენები ვეღარ განახლდება ახალ სტანდარტზე (რადგან მოვლენები პრინციპში ვერ შეიცვლება).

როგორც ხედავთ, Event Sourcing კარგად მუშაობს CQRS-თან. უფრო მეტიც, სისტემის დანერგვა ეფექტური და მოსახერხებელი რიგებით, მაგრამ მონაცემთა ნაკადების გამიჯვნის გარეშე, თავისთავად უკვე რთულია, რადგან მოგიწევთ სინქრონიზაციის წერტილების დამატება, რომლებიც ანეიტრალებს რიგების მთელ დადებით ეფექტს. ორივე მიდგომის ერთდროულად გამოყენებისას აუცილებელია პროგრამის კოდის ოდნავ კორექტირება. ჩვენს შემთხვევაში, სერვერზე ფაილის გაგზავნისას, პასუხი მოდის მხოლოდ "ok", რაც მხოლოდ იმას ნიშნავს, რომ "ფაილის დამატების ოპერაცია შენახულია". ფორმალურად, ეს არ ნიშნავს, რომ მონაცემები უკვე ხელმისაწვდომია სხვა მოწყობილობებზე (მაგალითად, დედუპლიკაციის სერვისს შეუძლია აღადგინოს ინდექსი). თუმცა, გარკვეული პერიოდის შემდეგ, კლიენტი მიიღებს შეტყობინებას "ფაილი X შენახულია" სტილში.

Როგორც შედეგი:

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

გახეხვა

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

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

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

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

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

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

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

სტატიკური შინაარსის ჰოსტინგი

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

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

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

• სერვერი უზრუნველყოფს ჩამოტვირთვის URL-ს. ის შეიძლება იყოს file_id + გასაღების სახით, სადაც გასაღები არის მინიციფრული ხელმოწერა, რომელიც იძლევა რესურსზე წვდომის უფლებას მომდევნო 24 საათის განმავლობაში.
• ფაილი ნაწილდება მარტივი nginx-ით შემდეგი პარამეტრებით:
  • კონტენტის ქეშირება. ვინაიდან ეს სერვისი შეიძლება განთავსდეს ცალკე სერვერზე, ჩვენ დავტოვეთ რეზერვი მომავლისთვის, ყველა უახლესი გადმოწერილი ფაილის დისკზე შენახვის შესაძლებლობით.
  • გასაღების შემოწმება კავშირის შექმნის დროს
• სურვილისამებრ: ნაკადის შინაარსის დამუშავება. მაგალითად, თუ ჩვენ შევკუმშავთ ყველა ფაილს სერვისში, მაშინ ჩვენ შეგვიძლია განვახორციელოთ განლაგება პირდაპირ ამ მოდულში. შედეგად: IO ოპერაციები კეთდება იქ, სადაც მათ ეკუთვნის. ჯავაში არქივი ადვილად გამოყოფს უამრავ დამატებით მეხსიერებას, მაგრამ საქმიანი ლოგიკის მქონე სერვისის Rust/C++ პირობითად გადაწერა ასევე შეიძლება არაეფექტური იყოს. ჩვენს შემთხვევაში გამოიყენება სხვადასხვა პროცესები (ან თუნდაც სერვისები) და, შესაბამისად, შეგვიძლია საკმაოდ ეფექტურად გავმიჯნოთ ბიზნეს ლოგიკა და IO ოპერაციები.

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

კიდევ ერთი მაგალითი (განმტკიცებისთვის): თუ თქვენ მუშაობდით Jenkins/TeamCity-თან, მაშინ იცით, რომ ორივე გამოსავალი იწერება Java-ში. ორივე მათგანი ჯავის პროცესია, რომელიც ამუშავებს როგორც კონსტრუქციის ორკესტრირებას, ასევე შინაარსის მართვას. კერძოდ, ორივეს აქვს დავალებები, როგორიცაა "ფაილის/საქაღალდის გადატანა სერვერიდან". მაგალითად: არტეფაქტების გაცემა, წყაროს კოდის გადაცემა (როდესაც აგენტი არ ჩამოტვირთავს კოდს პირდაპირ საცავიდან, მაგრამ სერვერი აკეთებს მას), წვდომა ჟურნალებზე. ყველა ეს ამოცანა განსხვავდება მათი IO დატვირთვით. ანუ გამოდის, რომ სერვერს, რომელიც პასუხისმგებელია კომპლექსურ ბიზნეს ლოგიკაზე, ამავდროულად უნდა შეძლოს მონაცემთა დიდი ნაკადების ეფექტურად გატარება. და რაც ყველაზე საინტერესოა, არის ის, რომ ასეთი ოპერაციის დელეგირება შესაძლებელია იმავე nginx-ზე ზუსტად იგივე სქემის მიხედვით (გარდა იმისა, რომ მოთხოვნას უნდა დაემატოს მონაცემთა გასაღები).

თუმცა, თუ ჩვენს სისტემას დავუბრუნდებით, მივიღებთ მსგავს დიაგრამას:

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

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

დასკვნა

ყველა ეს მიდგომა ადრე იყო ცნობილი. იგივე VK დიდი ხანია იყენებს სტატიკური შინაარსის ჰოსტინგის იდეას სურათების საჩვენებლად. ბევრი ონლაინ თამაში იყენებს Sharding სქემას მოთამაშეების რეგიონებად დასაყოფად ან თამაშის ლოკაციების გამოსაყოფად (თუ სამყარო თავად არის ასეთი). Event Sourcing მიდგომა აქტიურად გამოიყენება ელექტრონული ფოსტით. სავაჭრო აპლიკაციების უმეტესობა, სადაც მონაცემები მუდმივად მიიღება, რეალურად აგებულია CQRS მიდგომაზე, რათა შეძლონ მიღებული მონაცემების გაფილტვრა. ჰორიზონტალური სკალირება საკმაოდ დიდი ხანია გამოიყენება ბევრ სერვისში.

თუმცა, რაც მთავარია, ყველა ეს ნიმუში გახდა ძალიან ადვილი გამოსაყენებელი თანამედროვე აპლიკაციებში (თუ ისინი შესაბამისია, რა თქმა უნდა). ღრუბლები დაუყოვნებლივ გვთავაზობენ Sharding-ს და ჰორიზონტალურ სკალირებას, რაც ბევრად უფრო ადვილია, ვიდრე თავად შეუკვეთოთ სხვადასხვა გამოყოფილი სერვერები სხვადასხვა მონაცემთა ცენტრში. CQRS ბევრად უფრო ადვილი გახდა, თუნდაც მხოლოდ ისეთი ბიბლიოთეკების განვითარების გამო, როგორიცაა RX. დაახლოებით 10 წლის წინ, იშვიათ ვებსაიტს შეეძლო ამის მხარდაჭერა. Event Sourcing ასევე წარმოუდგენლად მარტივია დაყენება Apache Kafka-სთან მზა კონტეინერების წყალობით. 10 წლის წინ ეს იქნებოდა ინოვაცია, ახლა უკვე ჩვეულებრივი მოვლენაა. იგივეა სტატიკური შინაარსის ჰოსტინგი: უფრო მოსახერხებელი ტექნოლოგიების გამო (მათ შორის, რომ არსებობს დეტალური დოკუმენტაცია და პასუხების დიდი მონაცემთა ბაზა), ეს მიდგომა კიდევ უფრო მარტივი გახდა.

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

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

წყარო: www.habr.com