JSON-आरपीसी? मुश्किल आराम करो

मुझे यकीन है कि शीर्षक ने एक स्वस्थ प्रतिक्रिया पैदा की - "ठीक है, यह फिर से शुरू हो गया है..." लेकिन मुझे 5-10 मिनट के लिए आपका ध्यान आकर्षित करने दीजिए, और मैं आपकी उम्मीदों को निराश नहीं करने की कोशिश करूंगा।

लेख की संरचना इस प्रकार होगी: एक रूढ़िवादी बयान लिया जाता है और इस स्टीरियोटाइप के उद्भव की "प्रकृति" का पता चलता है। मुझे आशा है कि यह आपको अपनी परियोजनाओं में डेटा विनिमय प्रतिमान की पसंद को एक नए कोण से देखने की अनुमति देगा।

आरपीसी क्या है, इसके बारे में स्पष्ट होने के लिए, मैं मानक पर विचार करने का प्रस्ताव करता हूं JSON-आरपीसी 2.0. REST के साथ कोई स्पष्टता नहीं है। और यह नहीं होना चाहिए. REST के बारे में आपको जो कुछ जानने की आवश्यकता है - वह इससे अप्रभेद्य है HTTP.

RPC अनुरोध तेज़ और अधिक कुशल होते हैं क्योंकि वे आपको बैच अनुरोध करने की अनुमति देते हैं।

मुद्दा यह है कि आरपीसी में आप एक अनुरोध में एक साथ कई प्रक्रियाओं को कॉल कर सकते हैं। उदाहरण के लिए, एक उपयोगकर्ता बनाएं, उसमें एक अवतार जोड़ें और, उसी अनुरोध में, उसे कुछ विषयों की सदस्यता दें। बस एक विनती, और कितना फायदा!

दरअसल, यदि आपके पास केवल एक बैकएंड नोड है, तो यह बैच अनुरोध के साथ तेज़ प्रतीत होगा। क्योंकि तीन REST अनुरोधों के लिए कनेक्शन स्थापित करने के लिए एक नोड से तीन गुना अधिक संसाधनों की आवश्यकता होगी।

ध्यान दें कि REST के मामले में पहले अनुरोध में बाद के अनुरोधों के लिए उपयोगकर्ता आईडी लौटानी होगी। जिसका समग्र परिणाम पर भी नकारात्मक प्रभाव पड़ता है।

लेकिन ऐसे बुनियादी ढांचे केवल इन-हाउस समाधान और एंटरप्राइज़ में ही पाए जा सकते हैं। अंतिम उपाय के रूप में, छोटी वेब परियोजनाओं में। लेकिन पूर्ण विकसित वेब समाधान, और यहां तक ​​कि जिन्हें हाईलोड कहा जाता है, वे भी बनाने लायक नहीं हैं। उनके बुनियादी ढांचे को उच्च उपलब्धता और भार के मानदंडों को पूरा करना होगा। और तस्वीर बदल रही है.

उसी परिदृश्य के अंतर्गत अवसंरचना गतिविधि चैनल हरे रंग में चिह्नित हैं। ध्यान दें कि RPC अब कैसे व्यवहार करती है। अनुरोध बैलेंसर से बैकएंड तक केवल एक पैर पर बुनियादी ढांचे का उपयोग करता है। जबकि REST अभी भी पहले अनुरोध में हार जाता है, यह संपूर्ण बुनियादी ढांचे का उपयोग करके खोए हुए समय की भरपाई करता है।

स्क्रिप्ट में संवर्धन के लिए दो नहीं, बल्कि, मान लीजिए, पाँच या दस... और प्रश्न का उत्तर "अब कौन जीतता है?" दर्ज करना पर्याप्त है। अस्पष्ट हो जाता है.

मैं समस्या पर और भी व्यापक नजर डालने का प्रस्ताव करता हूं। आरेख दिखाता है कि बुनियादी ढांचे के चैनलों का उपयोग कैसे किया जाता है, लेकिन बुनियादी ढांचा चैनलों तक ही सीमित नहीं है। हाई-लोड इंफ्रास्ट्रक्चर का एक महत्वपूर्ण घटक कैश है। आइए अब किसी प्रकार की उपयोगकर्ता कलाकृति प्राप्त करें। बार-बार. मान लीजिए 32 बार.

देखें कि कैसे उच्च भार की मांगों को पूरा करने के लिए आरपीसी बुनियादी ढांचे में उल्लेखनीय सुधार हुआ है। बात यह है कि RPC के विपरीत, REST HTTP प्रोटोकॉल की पूरी शक्ति का उपयोग करता है। उपरोक्त चित्र में, यह शक्ति अनुरोध विधि - GET के माध्यम से महसूस की जाती है।

HTTP विधियों में, अन्य बातों के अलावा, कैशिंग रणनीतियाँ होती हैं। आप उन्हें दस्तावेज़ में पा सकते हैं HTTP. RPC के लिए, POST अनुरोधों का उपयोग किया जाता है, जिन्हें निष्क्रिय नहीं माना जाता है, अर्थात, एक ही POST अनुरोधों की बार-बार पुनरावृत्ति अलग-अलग परिणाम दे सकती है (उदाहरण के लिए, प्रत्येक टिप्पणी भेजे जाने के बाद, इस टिप्पणी की एक और प्रति दिखाई देगी) (स्रोत).

नतीजतन, आरपीसी इंफ्रास्ट्रक्चर कैश का प्रभावी ढंग से उपयोग करने में असमर्थ है। इससे सॉफ़्टवेयर कैश को "आयात" करने की आवश्यकता होती है। आरेख रेडिस को इस भूमिका में दिखाता है। बदले में, सॉफ़्टवेयर कैश के लिए डेवलपर को कोड की एक अतिरिक्त परत और आर्किटेक्चर में ध्यान देने योग्य परिवर्तन जोड़ने की आवश्यकता होती है।

आइए अब गिनें कि विचाराधीन बुनियादी ढांचे में REST और RPC ने कितने अनुरोधों को "जन्म दिया"?

अनुरोध
इनबॉक्स
बैकएंड करने के लिए
डीबीएमएस को
सॉफ्ट कैश के लिए (रेडिस)
TOTAL

बाकी
1 / 32 *
1
1
0
/ 3 35 है

आरपीसी
32
32
1
31
96

[*] सर्वोत्तम स्थिति में (यदि स्थानीय कैश का उपयोग किया जाता है) 1 अनुरोध (एक!), सबसे खराब स्थिति में 32 आने वाले अनुरोध।

पहली योजना की तुलना में, अंतर आश्चर्यजनक है। अब REST का लाभ स्पष्ट हो गया है। लेकिन मेरा सुझाव है कि वहां न रुकें। विकसित बुनियादी ढांचे में एक सीडीएन शामिल है। अक्सर यह DDoS और DoS हमलों का मुकाबला करने की समस्या को भी हल करता है। हम पाते हैं:

यहीं पर आरपीसी के लिए चीजें वास्तव में खराब हो जाती हैं। आरपीसी किसी सीडीएन को कार्यभार सौंपने में सक्षम नहीं है। हम हमलों का मुकाबला करने के लिए केवल सिस्टम पर भरोसा कर सकते हैं।

क्या यहीं ख़त्म होना संभव है? और फिर, नहीं. जैसा कि ऊपर बताया गया है, HTTP विधियों का अपना "जादू" है। और यह अकारण नहीं है कि इंटरनेट पर GET पद्धति का व्यापक रूप से उपयोग किया जाता है। ध्यान दें कि यह विधि सामग्री के एक टुकड़े तक पहुँचने में सक्षम है, ऐसी स्थितियाँ निर्धारित करने में सक्षम है जिन्हें बुनियादी ढाँचे के तत्व आपके कोड पर नियंत्रण स्थानांतरित करने से पहले व्याख्या कर सकते हैं, इत्यादि। यह सब आपको लचीला, प्रबंधनीय बुनियादी ढांचा बनाने की अनुमति देता है जो अनुरोधों के वास्तव में बड़े प्रवाह को संभाल सकता है। लेकिन आरपीसी में इस पद्धति को... नजरअंदाज कर दिया जाता है।

तो फिर यह मिथक क्यों बना हुआ है कि बैच अनुरोध (आरपीसी) तेज़ होते हैं? व्यक्तिगत रूप से, मुझे ऐसा लगता है कि अधिकांश परियोजनाएँ विकास के उस स्तर तक नहीं पहुँच पाती हैं जहाँ REST अपनी ताकत दिखाने में सक्षम हो। इसके अलावा, छोटी परियोजनाओं में, वह अपनी कमजोरियाँ दिखाने के लिए अधिक इच्छुक रहता है।

किसी प्रोजेक्ट में REST या RPC का चुनाव किसी व्यक्ति की स्वैच्छिक पसंद नहीं है। यह विकल्प परियोजना की आवश्यकताओं को पूरा करना चाहिए. यदि कोई प्रोजेक्ट REST से वह सब कुछ प्राप्त करने में सक्षम है जो वह वास्तव में कर सकता है, और उसे वास्तव में इसकी आवश्यकता है, तो REST एक उत्कृष्ट विकल्प होगा।

लेकिन अगर, REST के सभी लाभ प्राप्त करने के लिए, आपको बुनियादी ढांचे को तेजी से बढ़ाने के लिए प्रोजेक्ट के लिए डेवॉप्स विशेषज्ञों को नियुक्त करने की आवश्यकता है, बुनियादी ढांचे का प्रबंधन करने के लिए प्रशासक, WEB सेवा की सभी परतों को डिजाइन करने के लिए एक वास्तुकार... और परियोजना , एक ही समय में, एक दिन में मार्जरीन के तीन पैक बेचता है... मैं आरपीसी के साथ रहूंगा, क्योंकि... यह प्रोटोकॉल अधिक उपयोगितावादी है. इसमें कैश और बुनियादी ढांचे के काम करने के तरीके के बारे में गहन ज्ञान की आवश्यकता नहीं होगी, बल्कि डेवलपर को उसकी आवश्यक प्रक्रियाओं के लिए सरल और समझने योग्य कॉल पर ध्यान केंद्रित करना होगा। व्यापार सुखमय रहेगा।

आरपीसी अनुरोध अधिक विश्वसनीय हैं क्योंकि वे एक ही लेनदेन के भीतर बैच अनुरोधों को निष्पादित कर सकते हैं

आरपीसी की यह संपत्ति एक निश्चित लाभ है, क्योंकि डेटाबेस को सुसंगत रखना आसान है। लेकिन REST के साथ यह और अधिक जटिल हो जाता है। अनुरोध अलग-अलग बैकएंड नोड्स पर असंगत रूप से आ सकते हैं।

REST का यह "नुकसान" ऊपर वर्णित इसके लाभ का दूसरा पक्ष है - सभी बुनियादी ढांचे संसाधनों का कुशलतापूर्वक उपयोग करने की क्षमता। यदि बुनियादी ढांचा खराब तरीके से डिजाइन किया गया है, और इससे भी अधिक अगर परियोजना की वास्तुकला और विशेष रूप से डेटाबेस खराब तरीके से डिजाइन किया गया है, तो यह वास्तव में एक बड़ा दर्द है।

लेकिन क्या बैच अनुरोध उतने ही विश्वसनीय हैं जितने लगते हैं? आइए एक मामले को देखें: हम एक उपयोगकर्ता बनाते हैं, उसकी प्रोफ़ाइल को कुछ विवरण के साथ समृद्ध करते हैं और उसे पंजीकरण पूरा करने के रहस्य के साथ एक एसएमएस भेजते हैं। वे। एक बैच अनुरोध में तीन कॉल।

आइए आरेख देखें. यह उच्च उपलब्धता वाले तत्वों के साथ एक बुनियादी ढांचा प्रस्तुत करता है। एसएमएस गेटवे के साथ दो स्वतंत्र संचार चैनल हैं। लेकिन... हम क्या देखते हैं? एसएमएस भेजते समय, त्रुटि 503 उत्पन्न होती है - सेवा अस्थायी रूप से अनुपलब्ध है। क्योंकि एसएमएस भेजने को एक बैच अनुरोध में पैक किया गया है, फिर पूरे अनुरोध को वापस ले लिया जाना चाहिए। DBMS में क्रियाएँ रद्द कर दी गई हैं। क्लाइंट को एक त्रुटि प्राप्त होती है.

अगला प्रयास लॉटरी का है। या तो अनुरोध एक ही नोड पर बार-बार आएगा और एक त्रुटि लौटाएगा, या आप भाग्यशाली होंगे और इसे निष्पादित किया जाएगा। लेकिन मुख्य बात यह है कि कम से कम एक बार हमारा बुनियादी ढांचा पहले ही व्यर्थ काम कर चुका है। भार तो था, पर लाभ नहीं।

ठीक है, आइए कल्पना करें कि हमने खुद पर दबाव डाला है (!) और उस विकल्प के बारे में सोचा है जब अनुरोध आंशिक रूप से सफलतापूर्वक पूरा किया जा सकता है। और बाकी को हम कुछ समय अंतराल के बाद फिर से पूरा करने की कोशिश करेंगे (कौन सा? क्या सामने वाला तय करता है?)। लेकिन लॉटरी वैसी ही रही. एसएमएस भेजने का अनुरोध दोबारा विफल होने की 50/50 संभावना है।

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

REST फिर से HTTP के जादू का उपयोग करता है, लेकिन अब प्रतिक्रिया कोड के साथ। जब एसएमएस गेटवे पर त्रुटि 503 होती है, तो बैकएंड इस त्रुटि को बैलेंसर पर प्रसारित करता है। बैलेंसर इस त्रुटि को प्राप्त करता है और क्लाइंट के साथ कनेक्शन तोड़े बिना, अनुरोध को दूसरे नोड पर भेजता है, जो अनुरोध को सफलतापूर्वक संसाधित करता है। वे। ग्राहक को अपेक्षित परिणाम प्राप्त होता है, और बुनियादी ढांचा "अत्यधिक सुलभ" के अपने उच्च शीर्षक की पुष्टि करता है। उपयोगकर्ता खुश है.

और फिर इतना ही नहीं. बैलेंसर को केवल 503 का प्रतिक्रिया कोड प्राप्त नहीं हुआ। प्रतिक्रिया देते समय, मानक के अनुसार, इस कोड को "पुनः प्रयास-आफ्टर" हेडर के साथ प्रदान करने की सलाह दी जाती है। हेडर बैलेंसर को यह स्पष्ट कर देता है कि इस मार्ग पर एक निर्दिष्ट समय के लिए इस नोड को परेशान करना उचित नहीं है। और एसएमएस भेजने का अगला अनुरोध सीधे उस नोड पर भेजा जाएगा जिसमें एसएमएस गेटवे के साथ कोई समस्या नहीं है।

जैसा कि हम देख सकते हैं, JSON-RPC की विश्वसनीयता को अधिक महत्व दिया गया है। दरअसल, डेटाबेस में स्थिरता को व्यवस्थित करना आसान है। लेकिन इस मामले में, बलिदान समग्र रूप से सिस्टम की विश्वसनीयता होगी।

निष्कर्ष काफी हद तक पिछले निष्कर्ष के समान है। जब बुनियादी ढांचा सरल होता है, तो JSON-RPC की स्पष्टता निश्चित रूप से फायदेमंद होती है। यदि प्रोजेक्ट में उच्च लोड के साथ उच्च उपलब्धता शामिल है, तो REST अधिक सही, यद्यपि अधिक जटिल, समाधान जैसा दिखता है।

REST में प्रवेश सीमा कम है

मुझे लगता है कि उपरोक्त विश्लेषण ने, RPC के बारे में स्थापित रूढ़िवादिता को खारिज करते हुए, स्पष्ट रूप से दिखाया कि REST में प्रवेश की सीमा निस्संदेह RPC की तुलना में अधिक है। यह HTTP कैसे काम करता है इसकी गहरी समझ की आवश्यकता के साथ-साथ मौजूदा बुनियादी ढांचे के तत्वों के बारे में पर्याप्त ज्ञान की आवश्यकता के कारण है जिनका उपयोग WEB परियोजनाओं में किया जा सकता है और किया जाना चाहिए।

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

बेशक, REST HTTP से अधिक जटिल नहीं है। लेकिन HTTP स्वयं एक अच्छी तरह से डिज़ाइन किया गया प्रोटोकॉल है जिसने दशकों से अपनी उपयोगिता साबित की है। यदि HTTP की ही गहरी समझ नहीं है तो REST को आंका नहीं जा सकता।

लेकिन आरपीसी के बारे में - आप कर सकते हैं। इसकी स्पेसिफिकेशन लेना ही काफी है. तो क्या आपको चाहिए बेवकूफ JSON-RPC? या यह अभी भी मुश्किल बाकी है? आप तय करें।

मुझे पूरी उम्मीद है कि मैंने आपका समय बर्बाद नहीं किया है।

स्रोत: www.habr.com