JSON-RPC? कठिन REST लिनुहोस्

म पक्का छु कि हेडलाइनले स्वस्थ प्रतिक्रिया निम्त्यायो - "ठीक छ, यो फेरि सुरु भयो ..." तर मलाई 5-10 मिनेटको लागि तपाईंको ध्यान खिच्न दिनुहोस्, र म तपाईंको अपेक्षाहरूलाई निराश नगर्ने प्रयास गर्नेछु।

लेखको संरचना निम्नानुसार हुनेछ: एक स्टिरियोटाइपिकल कथन लिइन्छ र यस स्टेरियोटाइपको उद्भवको "प्रकृति" प्रकट हुन्छ। मलाई आशा छ कि यसले तपाईंलाई नयाँ कोणबाट तपाईंको परियोजनाहरूमा डेटा एक्सचेन्ज प्रतिमानको छनोट हेर्न अनुमति दिनेछ।

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

RPC अनुरोधहरू छिटो र अधिक कुशल हुन्छन् किनभने तिनीहरूले तपाईंलाई ब्याच अनुरोधहरू गर्न अनुमति दिन्छ।

बिन्दु यो हो कि RPC मा तपाइँ एकै अनुरोधमा धेरै प्रक्रियाहरू कल गर्न सक्नुहुन्छ। उदाहरणका लागि, प्रयोगकर्ता सिर्जना गर्नुहोस्, उसलाई अवतार थप्नुहोस् र, उही अनुरोधमा, उसलाई केही शीर्षकहरूमा सदस्यता लिनुहोस्। एउटा मात्र अनुरोध, कति फाइदा!

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

ध्यान दिनुहोस् कि REST को मामला मा पहिलो अनुरोध पछि अनुरोध गर्न को लागी प्रयोगकर्ता आईडी फिर्ता गर्नुपर्छ। जसले समग्र नतिजामा पनि नकारात्मक असर पार्छ ।

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

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

लिपिमा समृद्धिको लागि दुईवटा अनुरोध होइन, पाँच वा दस भन्नुहोस् ... र "अब कसले जित्छ?" भन्ने प्रश्नको जवाफ प्रविष्ट गर्न पर्याप्त छ। अस्पष्ट हुन्छ।

म समस्यालाई अझ फराकिलो रूपमा हेर्ने प्रस्ताव गर्दछु। रेखाचित्रले पूर्वाधार च्यानलहरू कसरी प्रयोग गरिन्छ भनेर देखाउँछ, तर पूर्वाधार च्यानलहरूमा सीमित छैन। उच्च-लोड पूर्वाधारको एक महत्त्वपूर्ण घटक क्यास हो। अब केहि प्रकारको प्रयोगकर्ता कलाकृति प्राप्त गरौं। बारम्बार । ३२ पटक भनौं।

उच्च लोडको मागहरू पूरा गर्न RPC पूर्वाधारमा कसरी उल्लेखनीय सुधार भएको छ हेर्नुहोस्। कुरा यो हो कि REST ले HTTP प्रोटोकलको पूर्ण शक्ति प्रयोग गर्दछ, RPC को विपरीत। माथिको रेखाचित्रमा, यो शक्ति अनुरोध विधि - GET मार्फत महसुस गरिएको छ।

HTTP विधिहरू, अन्य चीजहरू बीच, क्यासिङ रणनीतिहरू छन्। तपाईंले तिनीहरूलाई कागजातमा फेला पार्न सक्नुहुन्छ HTTP। RPC को लागि, POST अनुरोधहरू प्रयोग गरिन्छ, जसलाई idempotent मानिँदैन, अर्थात्, एउटै POST अनुरोधहरूको दोहोर्याइले फरक परिणामहरू फर्काउन सक्छ (उदाहरणका लागि, प्रत्येक टिप्पणी पठाएपछि, यो टिप्पणीको अर्को प्रतिलिपि देखा पर्नेछ) (स्रोत).

फलस्वरूप, RPC प्रभावकारी रूपमा पूर्वाधार क्यासहरू प्रयोग गर्न असमर्थ छ। यसले सफ्टवेयर क्यासहरू "आयात" गर्न आवश्यक हुन्छ। रेखाचित्रले रेडिसलाई यस भूमिकामा देखाउँछ। सफ्टवेयर क्यास, बारीमा, विकासकर्तालाई कोडको अतिरिक्त तह र वास्तुकलामा उल्लेखनीय परिवर्तनहरू थप्न आवश्यक छ।

अब गणना गरौं REST र RPC ले विचाराधीन पूर्वाधारमा कतिवटा अनुरोधहरूलाई "जन्म दिए"?

अनुरोधहरू
इनबक्स
ब्याकइन्डमा
DBMS मा
नरम क्यासमा (रेडिस)
TOTAL

REST
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 संग यो अधिक र अधिक जटिल हुन्छ। अनुरोधहरू विभिन्न ब्याकएन्ड नोडहरूमा असंगत रूपमा आउन सक्छन्।

REST को यो "नुकसान" माथि वर्णन गरिएको यसको फाइदाको फ्लिप पक्ष हो - सबै पूर्वाधार स्रोतहरू कुशलतापूर्वक प्रयोग गर्ने क्षमता। यदि पूर्वाधार नराम्रोसँग डिजाइन गरिएको छ भने, र अझ पनि यदि परियोजनाको वास्तुकला र विशेष गरी डाटाबेस खराब डिजाइन गरिएको छ भने, यो वास्तवमै ठूलो पीडा हो।

तर के ब्याच अनुरोधहरू तिनीहरू जस्तो देखिन्छ जस्तो विश्वसनीय छन्? एउटा केस हेरौं: हामी प्रयोगकर्ता सिर्जना गर्छौं, उसको प्रोफाइललाई केही विवरणसहित समृद्ध गर्छौं र दर्ता पूरा गर्नको लागि गोप्य एसएमएस पठाउँछौं। ती। एक ब्याच अनुरोध मा तीन कल।

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

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

ठीक छ, कल्पना गरौं कि हामीले आफैंलाई (!) तनावमा राखेका छौं र अनुरोध आंशिक रूपमा सफलतापूर्वक पूरा गर्न सकिन्छ भन्ने विकल्प मार्फत सोच्यौं। र हामी केहि समय अन्तराल पछि पुन: पूरा गर्न कोशिस गर्नेछौं (कुन एक? अगाडि निर्णय गर्छ?)। तर चिठ्ठा उस्तै रह्यो। SMS पठाउने अनुरोधमा फेरि असफल हुने 50/50 मौका छ।

सहमत हुनुहुन्छ, ग्राहक पक्षबाट, सेवा हामीले चाहेजस्तो भरपर्दो देखिँदैन... REST को बारेमा के हो?

REST ले HTTP को जादू फेरि प्रयोग गर्दछ, तर अब प्रतिक्रिया कोडहरूको साथ। SMS गेटवेमा त्रुटि ५०३ देखा पर्दा, ब्यालेन्सरमा ब्याकइन्डले यो त्रुटि प्रसारण गर्छ। ब्यालेन्सरले यो त्रुटि प्राप्त गर्दछ र क्लाइन्टसँग जडान तोडे बिना, अनुरोधलाई अर्को नोडमा पठाउँदछ, जसले अनुरोधलाई सफलतापूर्वक प्रशोधन गर्दछ। ती। ग्राहकले अपेक्षित परिणाम प्राप्त गर्दछ, र पूर्वाधारले "उच्च पहुँचयोग्य" को उच्च शीर्षक पुष्टि गर्दछ। प्रयोगकर्ता खुसी छन्।

र फेरि यो सबै होइन। ब्यालेन्सरले 503 को प्रतिक्रिया कोड मात्र प्राप्त गरेन। प्रतिक्रिया गर्दा, मानक अनुसार, यो कोड "पुनः प्रयास-पछि" हेडरको साथ प्रदान गर्न सल्लाह दिइन्छ। हेडरले ब्यालेन्सरलाई स्पष्ट बनाउँछ कि यो नोडलाई निर्दिष्ट समयको लागि यो मार्गमा बाधा पुर्‍याउनु उपयुक्त छैन। र SMS पठाउनको लागि अर्को अनुरोधहरू सिधै नोडमा पठाइनेछ जसमा SMS गेटवेसँग कुनै समस्या छैन।

हामी देख्न सक्छौं, JSON-RPC को विश्वसनीयता ओभररेट गरिएको छ। वास्तवमा, डाटाबेसमा स्थिरता व्यवस्थित गर्न सजिलो छ। तर बलिदान, यस अवस्थामा, सम्पूर्ण प्रणालीको विश्वसनीयता हुनेछ।

निष्कर्ष धेरै हदसम्म अघिल्लो एक जस्तै छ। जब पूर्वाधार सरल छ, JSON-RPC को स्पष्टता निश्चित रूपमा एक प्लस हो। यदि परियोजनाले उच्च भारको साथ उच्च उपलब्धता समावेश गर्दछ भने, REST अझ सही जस्तो देखिन्छ, यद्यपि अधिक जटिल, समाधान।

REST मा प्रवेश थ्रेसहोल्ड कम छ

मलाई लाग्छ कि माथिको विश्लेषणले, RPC को बारे मा स्थापित स्टिरियोटाइपहरू debunking, स्पष्ट रूपमा देखाएको छ कि REST मा प्रवेश को लागि थ्रेसहोल्ड निस्सन्देह RPC मा भन्दा उच्च छ। यो HTTP ले कसरी काम गर्दछ भन्ने बारे गहिरो बुझाइको आवश्यकताको कारणले गर्दा, साथै अवस्थित पूर्वाधार तत्वहरूको बारेमा पर्याप्त ज्ञान हुनु आवश्यक छ जुन WEB परियोजनाहरूमा प्रयोग गर्न सकिन्छ।

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

अवश्य पनि, REST HTTP भन्दा बढी जटिल छैन। तर HTTP आफैंमा एक राम्रो डिजाइन गरिएको प्रोटोकल हो जसले दशकहरूमा यसको मूल्य प्रमाणित गरेको छ। यदि HTTP आफैंको गहिरो समझ छैन भने, त्यसपछि REST न्याय गर्न सकिँदैन।

तर RPC को बारे मा - तपाईं सक्नुहुन्छ। यसको स्पेसिफिकेशन लिन पर्याप्त छ। त्यसैले तपाईलाई चाहिन्छ मूर्ख JSON-RPC? वा यो अझै पनि मुश्किल REST छ? तपाईं निर्णय गर्नुहोस्।

म ईमानदारीपूर्वक आशा गर्दछु कि मैले तपाईंको समय बर्बाद गरेको छैन।

स्रोत: www.habr.com