JSON-RPC? मुश्किल जंग ले लो

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यहां आरपीसी के लिए, सब कुछ बहुत खराब हो जाता है। RPC केवल CDN लोडिंग के साथ कार्य को प्रत्यायोजित करने में सक्षम नहीं है। हमलों का मुकाबला करने के लिए केवल सिस्टम पर भरोसा किया जा सकता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नीचे प्रवेश सीमा

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

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

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

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

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