JSON-RPC? მიიღეთ რთული დასვენება

დარწმუნებული ვარ, სათაურმა ჯანსაღი რეაქცია გამოიწვია - "კარგი, ისევ დაიწყო..." მაგრამ ნება მომეცით თქვენი ყურადღება 5-10 წუთით დავიპყრო და ვეცდები არ გავაცრუო თქვენი მოლოდინი.

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

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

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

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

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

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

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

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

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

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

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

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

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

მოდით, ახლა დავთვალოთ რამდენი მოთხოვნა "დაბადა" REST-მა და RPC-მა განსახილველ ინფრასტრუქტურაში?

ითხოვს
Inbox
დასაბრუნებლად
DBMS-ზე
რბილი ქეშისკენ (Redis)
TOTAL

დასვენება
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] საუკეთესო შემთხვევაში (თუ გამოიყენება ლოკალური ქეში) 1 მოთხოვნა (ერთი!), უარეს შემთხვევაში 32 შემომავალი მოთხოვნა.

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

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

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

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

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

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

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

RPC-ის ეს თვისება აშკარა უპირატესობაა, რადგან მარტივია მონაცემთა ბაზის თანმიმდევრული შენარჩუნება. მაგრამ REST-ით უფრო და უფრო რთულდება. მოთხოვნები შეიძლება არათანმიმდევრულად მივიდეს სხვადასხვა backend კვანძებში.

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

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

მოდით შევხედოთ დიაგრამას. იგი წარმოადგენს ინფრასტრუქტურას მაღალი ხელმისაწვდომობის ელემენტებით. არსებობს ორი დამოუკიდებელი საკომუნიკაციო არხი SMS გეითვეიებით. მაგრამ... რას ვხედავთ? SMS-ის გაგზავნისას ჩნდება შეცდომა 503 - სერვისი დროებით მიუწვდომელია. იმიტომ რომ SMS გაგზავნა შეფუთულია ჯგუფური მოთხოვნით, შემდეგ მთელი მოთხოვნა უკან უნდა დაბრუნდეს. მოქმედებები DBMS-ში გაუქმებულია. კლიენტი იღებს შეცდომას.

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

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

დამეთანხმებით, კლიენტის მხრიდან სერვისი არ გვეჩვენება ისეთი სანდო, როგორც ჩვენ გვსურს... რაც შეეხება REST-ს?

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

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

როგორც ვხედავთ, JSON-RPC-ის საიმედოობა გადაჭარბებულია. მართლაც, უფრო ადვილია მონაცემთა ბაზაში თანმიმდევრულობის ორგანიზება. მაგრამ მსხვერპლი, ამ შემთხვევაში, იქნება მთლიანად სისტემის საიმედოობა.

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

REST-ში შესვლის ბარიერი უფრო დაბალია

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

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

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

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

გულწრფელად ვიმედოვნებ, რომ თქვენი დრო არ დავკარგე.

წყარო: www.habr.com