जीआरपीसी एक चौराहे संचार प्रोटोकॉल के रूप में। यैंडेक्स रिपोर्ट

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

- पहले, मैं आपको Yandex.Market के बारे में कुछ तथ्यों से परिचित कराना चाहूंगा, वे रिपोर्ट के हिस्से के रूप में उपयोगी होंगे। पहला तथ्य: हम विभिन्न भाषाओं में सेवाएँ लिखते हैं। यह सेवाओं के लिए ग्राहकों की आवश्यकताओं को लागू करता है।

और अगर हमारे पास जावा में एक सेवा है, तो अच्छा होगा यदि ग्राहक इसके लिए है, उदाहरण के लिए, प्लस या थोड़ा भी।



हमारे पास जितनी भी सेवाएं हैं वे स्वतंत्र हैं, पूरे बाजार में कोई बड़ी योजना नहीं है। माइक्रोसर्विसेस स्वतंत्र रूप से जारी किए जाएंगे, और हमारे लिए पिछड़ी संगतता यहां महत्वपूर्ण है, ताकि प्रोटोकॉल इसका समर्थन करे।

तीसरा तथ्य: हमारे पास समकालिक और अतुल्यकालिक एकीकरण है। रिपोर्ट में, मैं मुख्य रूप से सिंक्रोनस के बारे में बात करूंगा।

हमने क्या उपयोग किया? अब, निश्चित रूप से, हमारी एकीकरण का आधार REST या REST जैसी सेवाएं हैं जो HTTP 1.1 पर XML / JSON का आदान-प्रदान करती हैं। एक्सएमएल-आरपीसी भी है - हम मुख्य रूप से इसका उपयोग पायथन कोड के साथ एकीकृत करते समय करते हैं, अर्थात, पायथन में एक अंतर्निहित एक्सएमएल-आरपीसी सर्वर है। यह वहां तैनात करने के लिए पर्याप्त सुविधाजनक है, और हम इसका समर्थन करते हैं।

हम एक बार CORBA थे। सौभाग्य से, हमने इसे त्याग दिया। अब HTTP पर ज्यादातर REST और XML / JSON।



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

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

त्रुटि से निपटने के लिए एक सुसंगत दृष्टिकोण भी आवश्यक है: हर कोई जिसने REST सेवाएँ की हैं, वह जानता है कि आप केवल HTTP स्थिति का उपयोग नहीं कर सकते हैं। वे आमतौर पर समस्या का विस्तृत विवरण नहीं देते हैं, आपको उनकी कुछ स्थितियों, उनके विवरण को दर्ज करना होगा। बाकी सेवाओं में, हर कोई इन त्रुटियों के अपने स्वयं के कार्यान्वयन का परिचय देता है, हर बार आपको इसके साथ अलग तरीके से काम करना पड़ता है। यह हमेशा सुविधाजनक नहीं होता है।

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

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

gRPC। सिद्धांत

मैं gRPC के सैद्धांतिक भाग के बारे में बात करना चाहूंगा - यह क्या है, विचार क्या हैं। और फिर हम अभ्यास के लिए आगे बढ़ेंगे।



सामान्य तौर पर, gRPC एक अमूर्त विनिर्देश है। यह एक अमूर्त आरपीसी (दूरस्थ प्रक्रिया कॉल) का वर्णन करता है, यानी एक दूरस्थ प्रक्रिया कॉल जिसमें कुछ गुण होते हैं। अब हम उन्हें सूचीबद्ध करेंगे। पहली संपत्ति एकल कॉल और स्ट्रीमिंग दोनों के लिए समर्थन है। अर्थात्, सभी सेवाएँ जो इस युक्ति को लागू करती हैं, दोनों विकल्पों का समर्थन करती हैं। अगला आइटम मेटाडेटा की उपलब्धता है, अर्थात्, पेलोड के साथ आप किसी प्रकार के मेटाडेटा को पारित कर सकते हैं - सशर्त, हेडर। और - बॉक्स के बाहर एक अनुरोध और टाइमआउट रद्द करने के लिए समर्थन।

यह यह भी मानता है कि संदेशों और सेवाओं का विवरण एक निश्चित इंटरफ़ेस डेफिनिशन लैंग्वेज या आईडीएल के माध्यम से किया जाता है। विनिर्देश HTTP / 2 पर वायर प्रोटोकॉल का भी वर्णन करता है, अर्थात, gRPC मानता है कि यह केवल HTTP / 2 पर काम करता है।



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



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



पिछड़ी अनुकूलता के बारे में। मैं यह नोट करना चाहूंगा कि प्रोटो आईडीएल एक ऐसा प्रारूप है जिसमें बैकवर्ड कम्पेटिबिलिटी बॉक्स से बाहर रखी गई है, अर्थात, यह बैकवर्ड कम्पैटिबिलिटी के बैकलॉग के साथ कल्पना की गई थी, और Google ने प्रोटो 3 का एक वर्जन जारी किया, जो प्रोटो 2 की तुलना में, बैकवर्ड कम्पैटिबिलिटी को और भी बेहतर बनाता है। वहाँ, प्लस, सभी प्रकार के विनिर्देश हैं, कैसे और क्या बदला जा सकता है ताकि कुछ गैर-तुच्छ मामलों में पिछड़े संगतता को संरक्षित किया जा सके।

डिफ़ॉल्ट मानों की संभावना है, आप नए फ़ील्ड जोड़ सकते हैं और उपभोक्ता को वास्तव में कुछ भी बदलने की आवश्यकता नहीं है। प्रोटो 3 के सभी क्षेत्र वैकल्पिक हैं और, उदाहरण के लिए, हटाए जा सकते हैं और दूरस्थ क्षेत्र तक पहुँचने से क्लाइंट पर त्रुटियाँ नहीं होती हैं।



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



अनुरोध और समय सीमा को रद्द करने के बारे में, मैं यह नोट करना चाहूंगा कि अनुरोध को सर्वर और क्लाइंट पर रद्द किया जा सकता है। यदि हम समझते हैं कि सब कुछ, हमें अनुरोध को पूरा करने की आवश्यकता नहीं है, तो हम इसे रद्द कर सकते हैं। अनुरोध पर टाइमआउट सेट करना संभव है। जीआरपीसी में, अधिकांश रनटाइम लाइब्रेरी टाइमआउट की अवधारणा के रूप में एक समय सीमा का उपयोग करते हैं। लेकिन वास्तव में ऐसा ही है। यही है, यह वह समय है जब अनुरोध पूरा होना चाहिए।

और सबसे दिलचस्प बात यह है कि सर्वर अनुरोध को रद्द करने और टाइमआउट की समाप्ति के बारे में दोनों का पता लगा सकता है और इसके पक्ष में अनुरोध को निष्पादित करना बंद कर सकता है। यह बहुत अच्छा है, यह मुझे लगता है कि कहीं और नहीं है।

प्रलेखन के बारे में, मैं यह नोट करना चाहता था कि चूंकि जीआरपीसी के लिए आईडीएल में प्रोटो प्रारूप का उपयोग किया जाता है, इसलिए यह नियमित कोड है। वहां आप बहुत विस्तृत सहित टिप्पणियों को लिख सकते हैं। और आपको यह समझने की आवश्यकता है कि आपकी सेवा के साथ एकीकरण करने के लिए, आपके उपयोगकर्ताओं को अपने घर में इस प्रोटो-प्रारूप की आवश्यकता होगी, और यह उन्हें टिप्पणियों के साथ मिल जाएगा, वे कहीं और झूठ नहीं बोलेंगे। यह बहुत सुविधाजनक है। और आप इस विवरण का विस्तार कर सकते हैं, अर्थात्, यह एक ऐसी सुविधाजनक सुविधा है कि प्रलेखन कोड के बगल में जाता है, बहुत कुछ ऐसा है जैसे कि javadoc या किसी अन्य टिप्पणी के रूप में विधियों के बगल में झूठ हो सकता है।

gRPC यूनरी कॉल। अभ्यास

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



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

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



यहाँ हमारे प्रोटो फ़ाइल के लिए एक नमूना कोड है। आप देख सकते हैं कि हम पहले संदेश का वर्णन करते हैं, अर्थात्, हमारे पास इको रीसपेस्ट और इको रिस्पांस है। इसमें केवल एक स्ट्रिंग फ़ील्ड है जो संदेश को संग्रहीत करता है।

दूसरा चरण हम अपनी प्रक्रिया का वर्णन करते हैं। इनपुट प्रक्रिया EchoRequest को स्वीकार करता है, परिणाम के रूप में EchoResponse देता है, सब कुछ काफी तुच्छ है। यह जीआरपीसी सेवा और संदेशों का वर्णन है जो पीछा किया जाएगा।




आइए देखें कि यह प्लसस के मामले में कैसे चल रहा है, उदाहरण के लिए। इसे तीन चरणों में इकट्ठा किया जाता है। पहले चरण में, हमारा कार्य संदेश स्रोत उत्पन्न करना है। यहां हम इस टीम के साथ ऐसा कर रहे हैं। हम प्रोटो कंपाइलर को कॉल करते हैं, प्रोटो-फाइल को इनपुट में पास करते हैं, संकेत करते हैं कि आउटपुट फाइल कहां रखी जाए।

दूसरी टीम। हम भी उसी तरह से सेवाएं उत्पन्न करते हैं। पिछले कमांड के साथ एकमात्र अंतर यह है कि हम प्लगइन पास करते हैं, और विवरण के आधार पर, जो प्रोटो प्रारूप में है, यह सेवाएं उत्पन्न करता है।

तीसरा चरण - हम यह सब एक बिनार में इकट्ठा करते हैं ताकि हमारे सर्वर को लॉन्च किया जा सके।

लिंकर को एक अतिरिक्त झंडा दिया जाता है, इसे grpc ++ _ प्रतिबिंब कहा जाता है। मैं नोट करना चाहता हूं - जीआरपीसी सर्वर में ऐसी सुविधा, सर्वर प्रतिबिंब है। यह आपको यह पता लगाने की अनुमति देता है कि किस तरह की सेवाएं, आरपीसी-कॉल और संदेश सेवा है। डिफ़ॉल्ट रूप से, इसे बंद कर दिया जाता है, और आप सेवा का उपयोग केवल तभी कर सकते हैं जब आपके पास हाथ पर एक प्रोटो-प्रारूप हो। लेकिन, उदाहरण के लिए, डिबगिंग के लिए, हाथ में प्रोटो-फॉर्मेट के बिना, यह बहुत सुविधाजनक है, बस प्रतिबिंब सुविधा के साथ सर्वर चालू करें और तुरंत जानकारी प्राप्त करें।




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

अगला, हम ServerBuilder बनाते हैं, इसमें हमारी सेवा पंजीकृत करते हैं, जिसे हमने थोड़ा अधिक बनाया था।




अब हम आने वाले अनुरोधों की प्रतीक्षा करते हैं।





अब जावा में क्लाइंट देखते हैं। हम ग्रेडल इकट्ठा करते हैं। हमारा काम पहले प्रोटोफ्यू प्लगइन को जोड़ना है।

निर्भरता का एक मूल सेट है जिसे हमें अपनी सेवा के लिए खींचने की आवश्यकता है, उन्हें संकलन चरण में आवश्यक है।

मैं यह भी ध्यान देना चाहता हूं कि एक रनटाइम लाइब्रेरी है। जावा के लिए, यह सर्वर और क्लाइंट के रूप में नेट्टी का उपयोग करता है, यह HTTP / 2 का समर्थन करता है, यह काफी सुविधाजनक और उच्च-प्रदर्शन है।

आगे हम प्रोटो कंपाइलर को कॉन्फ़िगर करते हैं। कंपाइलर को स्वयं जावा के लिए स्थानीय रूप से स्थापित करने की आवश्यकता नहीं है, इसे कलाकृतियों से लिया जा सकता है।

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





जावा कोड पर चलते हैं। यहाँ हम सबसे पहले अपनी सेवा का स्टब बनाने वाले हैं। चैनल प्रदान करने के लिए जावा के लिए हमारा काम है। रनटाइम लाइब्रेरी में एक ChannelBuilder है जिसके साथ हम इस चैनल का निर्माण कर सकते हैं। यहां हमने मैन्युअल रूप से सादगी के लिए सादे पाठ को चालू किया, लेकिन HTTP2 और gRPC डिफ़ॉल्ट रूप से सब कुछ एन्क्रिप्ट करते हैं और TLS का उपयोग करते हैं।

हमारे पास हमारे ग्राहक का एक स्टब है, एक तुल्यकालिक क्लाइंट यहां उत्पन्न होता है। उसी तरह, आप एक एसिंक्रोनस क्लाइंट उत्पन्न कर सकते हैं, अन्य विकल्प हैं।

अगला, हम अपने प्रोटोबफ अनुरोध बनाते हैं, अर्थात हम एक प्रोटोबफ संदेश का निर्माण करते हैं।





यह सब है, इसे भेजें, हमारे ग्राहक पर हम getEcho कहते हैं और परिणाम प्रिंट करते हैं। सब कुछ सरल है। जैसा कि आप देख सकते हैं, काफी कोड की आवश्यकता है, और एकीकरण बनाया गया है।

जीआरपीसी स्ट्रीमिंग। अभ्यास

अब आइए एक और उन्नत चीज़ देखें, यह है स्ट्रीमिंग। मैं आपको बताता हूं कि यह कैसे काम करता है, और बाद में मैं आपको बताता हूं कि इसका उपयोग कैसे करना है।



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

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



स्ट्रीमिंग सेवाओं को लागू करने के लिए हमें क्या आवश्यकता है? हमारे पास एक ही प्रोटो प्रारूप है। हम एक और आरपीसी जोड़ रहे हैं, और यहां आप देख सकते हैं कि हमने अनुरोध से पहले और प्रतिक्रिया से पहले दो कीवर्ड जोड़े हैं। इस प्रकार, हम EchoRequest और EchoResponse स्ट्रीम घोषित करते हैं।




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



यहाँ अब रीडिंग है, यहाँ रिकॉर्डिंग है।




जावा क्लाइंट में, चीजें थोड़ी अधिक जटिल होती हैं। वहाँ आप किसी भी तुल्यकालिक एपीआई का उपयोग नहीं कर सकते हैं, अर्थात यह केवल धाराओं के साथ काम नहीं करता है। और वहां अतुल्यकालिक एपीआई का उपयोग किया जाता है। यही है, हमारा काम ऑब्जर्वर टेम्पलेट को लागू करना है। वहाँ एक StreamObserver इंटरफ़ेस है। इसमें तीन विधियाँ शामिल हैं: onNext, onCompleted, और onError। यहाँ, सादगी के लिए, मैंने केवल onNext को लागू किया। यह केवल तभी टवीट्स करता है जब उत्तर सर्वर से हमारे पास आता है।




यहाँ मैं सिर्फ धागे के बीच मैसेजिंग के लिए एक कतार में लगा हूं।



अंतर क्या है? ब्लॉकस्टब के बजाय, हम सिर्फ नया स्टब बनाते हैं। यह एक अतुल्यकालिक कार्यान्वयन है जो सिर्फ ऑब्जर्वर के साथ काम कर सकता है। वास्तव में, आप ऑब्जर्वर पर यूरी कॉल कर सकते हैं, बस इतना सुविधाजनक नहीं है। हम, कम से कम, इसका सक्रिय रूप से उपयोग नहीं करते हैं।

आगे हम अपने ऑब्जर्वर का निर्माण करते हैं।

और हम अपने आरपीसी कॉल करते हैं। हम इनपुट के लिए ResponseObserver पास करते हैं, और आउटपुट पर यह हमें RequestObserver जारी करता है। इसके अलावा, हम RequestObserver पर कॉल कर सकते हैं, इस प्रकार सर्वर पर संदेश प्रेषित कर सकते हैं। और हमारा ResponseObserver संदेशों को ट्विच और प्रोसेस करेगा।

यहाँ एक उदाहरण है। हम सिर्फ एक कॉल कर रहे हैं। वहां पर कॉल करें, निवेदन करें।

कतार से आगे, हम सर्वर के जवाब देने और प्रिंट करने की प्रतीक्षा करते हैं।





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



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

इसके अलावा, स्ट्रीमिंग स्कीम सर्वर पुश के लिए अच्छी तरह से अनुकूल है। आपको यह समझने की ज़रूरत है कि मैंने सबसे चरम विकल्प पर विचार किया जब हमारे पास द्विदिश स्ट्रीमिंग है। और शायद एक दिशा में स्ट्रीमिंग। उदाहरण के लिए, क्लाइंट से सर्वर या सर्वर से क्लाइंट तक। एक क्लाइंट के लिए सर्वर के मामले में, हम कुछ सर्वर से कनेक्ट कर सकते हैं, और यह हमें pushies भेजेगा, और इसके लिए हमें नियमित रूप से मतदान करने की आवश्यकता नहीं होगी।

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

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

, . . . , - , , . . gRPC .

, gRPC.



, . - . gRPC . , , , , , . , runtime- . , . , OK, runtime- .

, Java . . google.rpc.Status 3 : , . , . , . — , , .

error details, , . : , , , stack traces, . , .

— , HTTP , ? . BadRequest . , , error details, .

. , , BadRequest - ( ), - error detail. , , , - . , .



. . , , , . - - , - - , , . . , , Zipkin. , HTTP , — metadata. .

, . , - , , , .

runtime-, - , . Java ClientInterceptor ServerInterceptor. , , . , , , , , - . , - API - . , , , , - . , gRPC, , - . , , - , , , .



- . -. Java . , , - . - , .



. gRPC — . HTTP/2 . - , ? : , . . , gRPC grpc_cli, curl. , . , -, . , gRPC , .

, evans. , CLI: , , , . , . - , , , , , .

- UI — , Postman, — BloomRPC. Postman . Postman, , , . , BloomRPC , .

- , . , , grpc_cli. . , . , , . , . , - - . — .



, , gRPC. . - , - , . Swagger. , HTTP/1 . OpenAPI , . . , HTTP/2, Swagger — .

WSDL — , . . Swagger, , . . -.

, , , , JAX-RS, Java . .

Twirp. ? Go, . . , , Go , gRPC Twirp. ? , gRPC — , , , IDL . proto- , gRPC-. protoc, , .

Twirp . proto- , HTTP/1.1 , JSON. , Twirp Go. , , Java Jetty. , .



? gRPC — REST . , , , , HTTP/2 balancer. service discovery, . gRPC , . .

gRPC — , . CLI, UI. , .

, gRPC. inter-process-. , sidecar pattern. , . , . , -. - , , -. . , , , , - .

, . gRPC . , . , unary-. , .

:
— C gRPC — , . , , , .
— Awesome gRPC — GitHub . , , , . . — , .

आप कुछ स्लाइड्स पर इंटरनेट पर कई अन्य संसाधन पा सकते हैं। लेकिन मुझे ये सबसे ज्यादा पसंद है। प्रस्तुति से थोड़ा संशोधित कोड यहां है । धन्यवाद!