JSON-RPC? अवघड REST घ्या

मला खात्री आहे की मथळ्यामुळे चांगली प्रतिक्रिया आली - "ठीक आहे, ते पुन्हा सुरू झाले आहे..." परंतु मला 5-10 मिनिटे तुमचे लक्ष वेधून घेऊ द्या आणि मी तुमच्या अपेक्षांना निराश न करण्याचा प्रयत्न करेन.

लेखाची रचना खालीलप्रमाणे असेल: एक स्टिरियोटाइपिकल विधान घेतले जाते आणि या स्टिरियोटाइपच्या उदयाचे "स्वरूप" प्रकट होते. मला आशा आहे की हे तुम्हाला तुमच्या प्रकल्पांमध्ये डेटा एक्सचेंज पॅराडाइमच्या निवडीकडे नवीन कोनातून पाहण्यास अनुमती देईल.

RPC काय आहे हे स्पष्ट होण्यासाठी, मी मानक विचारात घेण्याचा प्रस्ताव देतो JSON-RPC 2.0. REST सह स्पष्टता नाही. आणि ते नसावे. आपल्याला REST बद्दल माहित असणे आवश्यक असलेली प्रत्येक गोष्ट - ते वेगळे करणे अशक्य आहे HTTP.

RPC विनंत्या जलद आणि अधिक कार्यक्षम आहेत कारण त्या तुम्हाला बॅच विनंत्या करण्याची परवानगी देतात.

मुद्दा असा आहे की RPC मध्ये तुम्ही एकाच विनंतीवर एकाच वेळी अनेक प्रक्रिया कॉल करू शकता. उदाहरणार्थ, एक वापरकर्ता तयार करा, त्याला अवतार जोडा आणि त्याच विनंतीनुसार, त्याला काही विषयांची सदस्यता घ्या. फक्त एक विनंती, आणि किती फायदा!

खरंच, तुमच्याकडे फक्त एक बॅकएंड नोड असल्यास, बॅच विनंतीसह ते जलद वाटेल. कारण कनेक्शन स्थापित करण्यासाठी तीन REST विनंत्यांना एका नोडमधून तिप्पट संसाधनांची आवश्यकता असेल.

लक्षात ठेवा की REST च्या बाबतीत प्रथम विनंती नंतरच्या विनंत्या करण्यासाठी वापरकर्ता आयडी परत करणे आवश्यक आहे. ज्याचा एकूण निकालावरही नकारात्मक परिणाम होतो.

परंतु अशा पायाभूत सुविधा केवळ इन-हाऊस सोल्यूशन्स आणि एंटरप्राइझमध्ये आढळू शकतात. शेवटचा उपाय म्हणून, लहान WEB प्रकल्पांमध्ये. परंतु पूर्ण वाढ झालेले WEB सोल्यूशन्स, आणि ज्यांना HighLoad म्हणतात, ते तयार करण्यासारखे नाहीत. त्यांच्या पायाभूत सुविधांनी उच्च उपलब्धता आणि लोडचे निकष पूर्ण केले पाहिजेत. आणि चित्र बदलत आहे.

त्याच परिस्थितीत पायाभूत सुविधा क्रियाकलाप चॅनेल हिरव्या रंगात चिन्हांकित केले आहेत. RPC आता कसे वागते ते पहा. विनंती बॅलन्सरपासून बॅकएंडपर्यंत फक्त एका पायावर पायाभूत सुविधा वापरते. REST अजूनही पहिल्या विनंतीमध्ये गमावत असताना, तो संपूर्ण पायाभूत सुविधा वापरून गमावलेला वेळ भरून काढतो.

स्क्रिप्टमध्ये समृद्धीसाठी दोन नव्हे तर पाच किंवा दहा विनंत्या प्रविष्ट करणे पुरेसे आहे ... आणि "आता कोण जिंकले?" या प्रश्नाचे उत्तर. अस्पष्ट होते.

मी समस्येकडे आणखी विस्तृतपणे पाहण्याचा प्रस्ताव देतो. आकृतीत पायाभूत सुविधा चॅनेल कसे वापरले जातात हे दाखवले आहे, परंतु पायाभूत सुविधा केवळ चॅनेलपुरती मर्यादित नाही. उच्च-लोड इन्फ्रास्ट्रक्चरचा एक महत्त्वाचा घटक म्हणजे कॅशे. चला आता काही प्रकारचे वापरकर्ता कलाकृती मिळवूया. वारंवार. चला 32 वेळा म्हणू.

उच्च भाराच्या मागण्या पूर्ण करण्यासाठी RPC पायाभूत सुविधांमध्ये लक्षणीय सुधारणा कशी झाली आहे ते पहा. गोष्ट अशी आहे की REST RPC च्या विपरीत HTTP प्रोटोकॉलची संपूर्ण शक्ती वापरते. वरील चित्रात, ही शक्ती विनंती पद्धती - GET द्वारे लक्षात येते.

HTTP पद्धतींमध्ये, इतर गोष्टींबरोबरच, कॅशिंग धोरणे असतात. आपण त्यांना येथे दस्तऐवजीकरणात शोधू शकता HTTP. RPC साठी, POST विनंत्या वापरल्या जातात, ज्या अशक्त मानल्या जात नाहीत, म्हणजेच, समान POST विनंत्यांची वारंवार पुनरावृत्ती केल्याने भिन्न परिणाम मिळू शकतात (उदाहरणार्थ, प्रत्येक टिप्पणी पाठवल्यानंतर, या टिप्पणीची दुसरी प्रत दिसून येईल) (स्त्रोत).

परिणामी, RPC पायाभूत सुविधा कॅशे प्रभावीपणे वापरण्यात अक्षम आहे. यामुळे सॉफ्टवेअर कॅशे "आयात" करण्याची गरज निर्माण होते. आकृती रेडिस या भूमिकेत दाखवते. सॉफ्टवेअर कॅशे, यामधून, विकसकाने कोडचा अतिरिक्त स्तर आणि आर्किटेक्चरमध्ये लक्षणीय बदल जोडणे आवश्यक आहे.

आता विचाराधीन पायाभूत सुविधांमध्ये REST आणि RPC ने किती विनंत्या "जन्म" दिल्या आहेत ते मोजूया?

चौकश्या
इनबॉक्स
बॅकएंड करण्यासाठी
DBMS ला
सॉफ्ट कॅशेमध्ये (रेडीस)
TOTAL

उर्वरित
1 / 32 *
1
1
0
3 / 35

जनता सरकारच्या
32
32
1
31
96

[*] सर्वोत्तम प्रकरणात (स्थानिक कॅशे वापरल्यास) 1 विनंती (एक!), सर्वात वाईट परिस्थितीत 32 इनकमिंग विनंत्या.

पहिल्या योजनेच्या तुलनेत, फरक उल्लेखनीय आहे. आता REST चा फायदा स्पष्ट होतो. पण मी तिथे थांबू नये असे सुचवतो. विकसित पायाभूत सुविधांमध्ये CDN समाविष्ट आहे. अनेकदा ते DDoS आणि DoS हल्ल्यांना तोंड देण्याच्या समस्येचे निराकरण करते. आम्हाला मिळते:

येथेच RPC साठी गोष्टी खरोखरच वाईट होतात. RPC CDN वर कामाचा भार सोपवण्यास सक्षम नाही. हल्ल्यांना तोंड देण्यासाठी आम्ही फक्त सिस्टमवर अवलंबून राहू शकतो.

इथेच संपवता येईल का? आणि पुन्हा, नाही. HTTP पद्धती, वर नमूद केल्याप्रमाणे, त्यांची स्वतःची "जादू" आहे. आणि हे विनाकारण नाही की GET पद्धत इंटरनेटवर मोठ्या प्रमाणावर वापरली जाते. लक्षात ठेवा की ही पद्धत सामग्रीच्या एका भागामध्ये प्रवेश करण्यास सक्षम आहे, आपल्या कोडवर नियंत्रण हस्तांतरित होण्यापूर्वी पायाभूत सुविधा घटकांचा अर्थ लावू शकतील अशा परिस्थिती सेट करण्यास सक्षम आहे आणि असेच. हे सर्व तुम्हाला लवचिक, आटोपशीर पायाभूत सुविधा निर्माण करण्यास अनुमती देते जे खरोखरच मोठ्या प्रमाणात विनंत्या हाताळू शकतात. परंतु RPC मध्ये ही पद्धत... दुर्लक्षित आहे.

मग बॅच विनंत्या (RPC) जलद आहेत असा समज का आहे? वैयक्तिकरित्या, मला असे वाटते की बहुतेक प्रकल्प केवळ विकासाच्या अशा स्तरावर पोहोचत नाहीत जिथे REST आपली ताकद दाखवू शकेल. शिवाय, छोट्या प्रकल्पांमध्ये तो त्याच्या कमकुवतपणा दाखवण्यास अधिक इच्छुक असतो.

REST किंवा RPC ची निवड ही एखाद्या प्रकल्पातील व्यक्तीची स्वैच्छिक निवड नाही. ही निवड प्रकल्पाच्या आवश्यकता पूर्ण करणे आवश्यक आहे. जर एखादा प्रकल्प REST मधून जे काही करू शकतो ते सर्व पिळून काढू शकत असेल आणि त्याला त्याची खरोखर गरज असेल, तर REST हा एक उत्कृष्ट पर्याय असेल.

परंतु, जर REST चे सर्व फायदे मिळवण्यासाठी, तुम्हाला पायाभूत सुविधांचे त्वरीत स्केल करण्यासाठी प्रकल्पासाठी devops विशेषज्ञ, पायाभूत सुविधा व्यवस्थापित करण्यासाठी प्रशासक, WEB सेवेचे सर्व स्तर डिझाइन करण्यासाठी आर्किटेक्ट... आणि प्रकल्पासाठी नियुक्त करणे आवश्यक आहे. , त्याच वेळी, दिवसाला तीन पॅक मार्जरीन विकतो... मी RPC ला चिकटून राहीन, कारण... हा प्रोटोकॉल अधिक उपयुक्ततावादी आहे. कॅशे आणि इन्फ्रास्ट्रक्चर कसे कार्य करते याचे सखोल ज्ञान आवश्यक नाही, परंतु विकसकाला आवश्यक असलेल्या प्रक्रियेसाठी साध्या आणि समजण्यायोग्य कॉलवर लक्ष केंद्रित करेल. व्यवसायात आनंद होईल.

RPC विनंत्या अधिक विश्वासार्ह आहेत कारण त्या एकाच व्यवहारात बॅच विनंत्या अंमलात आणू शकतात

RPC ची ही मालमत्ता निश्चित फायदा आहे, कारण डेटाबेस सुसंगत ठेवणे सोपे आहे. पण REST सह ते अधिकाधिक क्लिष्ट होत जाते. विनंत्या वेगवेगळ्या बॅकएंड नोड्सवर विसंगतपणे येऊ शकतात.

REST चा हा "तोटा" वर वर्णन केलेल्या त्याच्या फायद्याची दुसरी बाजू आहे - सर्व पायाभूत संसाधने कार्यक्षमतेने वापरण्याची क्षमता. जर पायाभूत सुविधांची रचना खराब केली गेली असेल आणि त्याहीपेक्षा प्रकल्पाचे आर्किटेक्चर आणि विशेषतः डेटाबेस खराब डिझाइन केलेले असेल तर ही खरोखर मोठी वेदना आहे.

पण बॅच विनंत्या वाटतात तितक्या विश्वसनीय आहेत? चला एक केस पाहू: आम्ही एक वापरकर्ता तयार करतो, त्याचे प्रोफाइल काही वर्णनासह समृद्ध करतो आणि त्याला नोंदणी पूर्ण करण्यासाठी एक गुप्त एसएमएस पाठवतो. त्या. एका बॅच विनंतीमध्ये तीन कॉल.

चला आकृती पाहू. हे उच्च उपलब्धता घटकांसह पायाभूत सुविधा सादर करते. एसएमएस गेटवेसह दोन स्वतंत्र संप्रेषण चॅनेल आहेत. पण... आपण काय पाहतो? एसएमएस पाठवताना, एक त्रुटी 503 येते - सेवा तात्पुरती अनुपलब्ध आहे. कारण एसएमएस पाठवणे बॅच विनंतीमध्ये पॅक केले जाते, त्यानंतर संपूर्ण विनंती परत करणे आवश्यक आहे. DBMS मधील क्रिया रद्द केल्या आहेत. क्लायंटला एक त्रुटी प्राप्त होते.

पुढचा प्रयत्न म्हणजे लॉटरी. एकतर विनंती त्याच नोडला पुन्हा दाबेल आणि पुन्हा त्रुटी देईल, किंवा तुम्ही भाग्यवान असाल आणि ते कार्यान्वित केले जाईल. परंतु मुख्य गोष्ट अशी आहे की किमान एकदा आमच्या पायाभूत सुविधांनी आधीच व्यर्थ काम केले आहे. एक भार होता, पण फायदा नाही.

ठीक आहे, चला कल्पना करूया की आम्ही स्वतःला ताणले आहे (!) आणि जेव्हा विनंती अंशतः यशस्वीरित्या पूर्ण केली जाऊ शकते तेव्हा पर्यायाद्वारे विचार केला. आणि काही वेळाच्या अंतराने पुन्हा उरलेले पूर्ण करण्याचा प्रयत्न करू (कोणते? समोरचे ठरवते का?). पण लॉटरी तशीच राहिली. एसएमएस पाठवण्याची विनंती पुन्हा अयशस्वी होण्याची 50/50 शक्यता असते.

सहमत, क्लायंटच्या बाजूने, सेवा आम्हाला पाहिजे तितकी विश्वासार्ह वाटत नाही... REST चे काय?

REST पुन्हा HTTP ची जादू वापरते, परंतु आता प्रतिसाद कोडसह. जेव्हा SMS गेटवेवर 503 त्रुटी आढळते, तेव्हा बॅकएंड ही त्रुटी बॅलन्सरवर प्रसारित करतो. बॅलन्सरला ही त्रुटी प्राप्त होते आणि क्लायंटशी कनेक्शन तोडल्याशिवाय, विनंती दुसर्या नोडला पाठवते, जी विनंतीवर यशस्वीरित्या प्रक्रिया करते. त्या. क्लायंटला अपेक्षित परिणाम प्राप्त होतो, आणि पायाभूत सुविधा त्याच्या "उच्च प्रवेशयोग्य" शीर्षकाची पुष्टी करते. वापरकर्ता आनंदी आहे.

आणि पुन्हा ते सर्व नाही. बॅलन्सरला फक्त 503 चा प्रतिसाद कोड मिळाला नाही. प्रतिसाद देताना, मानकानुसार, हा कोड “पुन्हा प्रयत्न-आफ्टर” हेडरसह प्रदान करणे उचित आहे. हेडर बॅलन्सरला हे स्पष्ट करते की या मार्गावरील या नोडला निर्दिष्ट वेळेसाठी त्रास देणे योग्य नाही. आणि एसएमएस पाठवण्याच्या पुढील विनंत्या थेट नोडवर पाठवल्या जातील ज्याला एसएमएस गेटवेमध्ये कोणतीही समस्या नाही.

जसे आपण पाहू शकतो, JSON-RPC ची विश्वासार्हता ओव्हररेट केलेली आहे. खरंच, डेटाबेसमध्ये सुसंगतता आयोजित करणे सोपे आहे. परंतु बलिदान, या प्रकरणात, संपूर्ण प्रणालीची विश्वासार्हता असेल.

निष्कर्ष मुख्यत्वे मागील सारखाच आहे. जेव्हा पायाभूत सुविधा सोप्या असतात, तेव्हा JSON-RPC ची स्पष्टता निश्चितपणे एक प्लस आहे. जर प्रकल्पात उच्च भारासह उच्च उपलब्धता समाविष्ट असेल, तर REST अधिक अचूक, जरी अधिक जटिल, समाधानासारखे दिसते.

REST साठी प्रवेशाचा उंबरठा कमी आहे

मला असे वाटते की वरील विश्लेषणाने, RPC बद्दलच्या प्रस्थापित स्टिरियोटाइपचे खंडन करून, REST मध्ये प्रवेशाची मर्यादा निःसंशयपणे RPC पेक्षा जास्त आहे हे स्पष्टपणे दर्शविले आहे. हे HTTP कसे कार्य करते याबद्दल सखोल समजून घेण्याची गरज आहे, तसेच WEB प्रकल्पांमध्ये वापरल्या जाऊ शकणार्‍या आणि वापरल्या जाणार्‍या विद्यमान पायाभूत घटकांबद्दल पुरेसे ज्ञान असणे आवश्यक आहे.

मग बर्याच लोकांना असे का वाटते की REST सोपे होईल? माझे वैयक्तिक मत असे आहे की हे उघड साधेपणा REST मधून प्रकट होते. त्या. REST हा प्रोटोकॉल नसून एक संकल्पना आहे... REST ला मानक नाही, काही मार्गदर्शक तत्वे आहेत... REST HTTP पेक्षा अधिक क्लिष्ट नाही. उघड स्वातंत्र्य आणि अराजकता "मुक्त कलाकारांना" आकर्षित करते.

अर्थात, REST HTTP पेक्षा अधिक क्लिष्ट नाही. परंतु HTTP हा स्वतःच एक सु-डिझाइन केलेला प्रोटोकॉल आहे ज्याने अनेक दशकांपासून त्याचे मूल्य सिद्ध केले आहे. जर HTTP ची स्वतःची सखोल माहिती नसेल, तर REST चा न्याय करता येणार नाही.

परंतु RPC बद्दल - आपण हे करू शकता. त्याचे तपशील घेणे पुरेसे आहे. तर तुम्हाला गरज आहे मूर्ख JSON-RPC? किंवा तो अजूनही अवघड REST आहे? तुम्ही ठरवा.

मला मनापासून आशा आहे की मी तुमचा वेळ वाया घालवला नाही.

स्त्रोत: www.habr.com