अनुवादक का नोट

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

• सेवाओं की सहभागिता का वर्णन करने के लिए प्रोटोकॉल बफ़र्स भाषा का उपयोग करें;
  
• क्लाइंट भाग और सर्वर भाग दोनों के लिए 11 अलग-अलग भाषाओं के लिए वर्णित प्रोटोकॉल के आधार पर प्रोग्राम कोड उत्पन्न करें;
  
• सहभागिता घटकों के बीच प्राधिकरण को लागू करना;
  
• सिंक्रोनस और एसिंक्रोनस इंटरैक्शन दोनों का उपयोग करें।
  

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


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

नोट: पोस्ट में पायथन और गो के लिए कोड स्निपेट हैं। हम जंग और जावा का भी उपयोग करते हैं।

जीआरपीसी को सड़क

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

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

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

नोट: अगर उस समय fbthrift मौजूद थी, तो हम शायद Thrift समाधानों पर एक करीब से नज़र डालेंगे।

क्या कूरियर जीआरपीसी में लाता है

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

हालांकि कुछ मामलों में हम एक GRPC प्रॉक्सी के रूप में Bandaid का उपयोग करते हैं, हमारी अधिकांश सेवाएं विलंबता पर RPC के प्रभाव को कम करने के लिए एक दूसरे से सीधे संवाद करती हैं।

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

सुरक्षा: सेवा पहचान और टीएलएस पारस्परिक प्रमाणीकरण

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

टीएलएस में, जहां हम कनेक्शन के दोनों किनारों को नियंत्रित करते हैं, हमने सख्त प्रतिबंध लगाए हैं। सभी आंतरिक RPC को PFS एन्क्रिप्शन की आवश्यकता होती है। टीएलएस का आवश्यक संस्करण 1.2 और अधिक है। हमने ECDHE-ECDSA-AES128-GCM-SHA256 को प्राथमिकता देते हुए सममित और असममित एल्गोरिदम की संख्या को भी सीमित किया है।

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

पहचान सेवा ACLs, गति सीमा, सांख्यिकी, आदि के लिए एक वैश्विक पहचानकर्ता है। यह क्रिप्टोग्राफिक रूप से सुरक्षित है।

यहाँ एसीएल विन्यास और गति सीमा का एक उदाहरण हमारे ऑप्टिकल पैटर्न मान्यता सेवा में उपयोग किया जाता है:

limits:  dropbox_engine_ocr:    # All RPC methods.    default:      max_concurrency: 32      queue_timeout_ms: 1000      rate_acls:        # OCR clients are unlimited.        ocr: -1        # Nobody else gets to talk to us.        authenticated: 0        unauthenticated: 0 

हम SVID प्रारूप (क्रिप्टोग्राफिक रूप से सत्यापित दस्तावेज़ SPIFFE ) पर स्विच करने की संभावना पर विचार कर रहे हैं, जो कई खुले स्रोत परियोजनाओं के साथ हमारे ढांचे को संयोजित करने में मदद करेगा।

अवलोकन: आंकड़े और ट्रैकिंग

केवल एक पहचानकर्ता के साथ, आप आसानी से लॉग, आँकड़े, ट्रेस फ़ाइलें और कूरियर के बारे में अन्य डेटा पा सकते हैं।



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



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

हमारी कोड पीढ़ी के फायदों में से एक डेटा संरचनाओं के स्थैतिक आरंभीकरण की संभावना है, जैसे कि हिस्टोग्राम और ट्रेस ग्राफ। यह प्रदर्शन प्रभाव को कम करता है।



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



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

विश्वसनीयता, समय सीमा और वियोग

कूरियर विभिन्न भाषाओं में आम ग्राहक कार्यों (उदाहरण के लिए, टाइमआउट) को लागू करने के लिए एक केंद्रीय स्थान प्रदान करता है। हमने धीरे-धीरे विभिन्न विशेषताओं को जोड़ा, अक्सर उभरती समस्याओं के "मरणोपरांत" विश्लेषण के परिणामों के आधार पर।

समय सीमा

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

वास्तव में, हम उपयुक्त सेवाओं को परिभाषित करने में समय सीमा निर्धारित करने के लिए इंजीनियरों को मजबूर करके विश्वसनीयता समस्याओं के पूरे वर्गों को ठीक करने में सक्षम थे।

यह दृष्टिकोण आरपीसी से भी आगे जाता है। उदाहरण के लिए, हमारा ORM MySQL एक SQL क्वेरी टिप्पणी में समय सीमा के साथ एक RPC संदर्भ को क्रमबद्ध करता है। हमारी SQL प्रॉक्सी समय सीमा समाप्त होने पर टिप्पणियों और "मार" प्रश्नों को पार्स कर सकती है। और जब डेटाबेस कॉल डिबगिंग एक बोनस के रूप में, हमारे पास एक विशिष्ट RPC क्वेरी के लिए एक SQL क्वेरी बाइंडिंग है।

वियोग

पिछली RPC प्रणाली के ग्राहकों की एक और आम समस्या थी, बार-बार अनुरोध पर व्यक्तिगत घातीय विलंब और उतार-चढ़ाव के एल्गोरिदम का कार्यान्वयन।

हमने कूरियर में डिस्कनेक्ट की समस्या का एक बुद्धिमान समाधान खोजने की कोशिश की, जो सेवा और कार्य पूल के बीच LIFO बफर (अंतिम बार, पहले बाहर) के कार्यान्वयन के साथ शुरू हुआ।



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

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

आत्मनिरीक्षण: डिबगिंग समापन बिंदु

हालांकि डिबगिंग एंडपॉइंट सीधे कोरियर का हिस्सा नहीं हैं, लेकिन वे व्यापक रूप से ड्रॉपबॉक्स में उपयोग किए जाते हैं और उल्लेखित नहीं होने के लिए बहुत उपयोगी हैं।

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

क्रियान्वयन

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

हम इस अवसर को कैनरी सत्यापन प्रक्रिया में उपयोग करने की योजना बनाते हैं - कोड के पुराने और नए संस्करणों के बीच अंतर की खोज को स्वचालित करने के लिए।

एंडपॉइंट्स रनटाइम पर किसी सेवा की स्थिति को संशोधित करना संभव बनाता है। विशेष रूप से, गोलंग-आधारित सेवाएं गतिशील रूप से GCPercent को कॉन्फ़िगर कर सकती हैं ।

पुस्तकालय

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

आरपीसी

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

आवेदन स्तर

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

प्रदर्शन अनुकूलन

आवश्यक पैमाने पर हमारे जीआरपीसी ढांचे का विस्तार करके, हमने ड्रॉपबॉक्स के लिए कई अड़चनें पाईं।

टीएलएस हैंडशेक का संसाधन उपभोग

टीएलएस हैंडशेक के परिणामस्वरूप कई रिश्तों की सेवा करने वाली सेवाओं में, संयुक्त सीपीयू लोड काफी गंभीर हो सकता है (विशेषकर जब एक लोकप्रिय सेवा को रिबूट करते हुए)।

हस्ताक्षर करते समय प्रदर्शन में सुधार करने के लिए, हमने ECDSA P-256 के साथ RSA-2048 प्रमुख जोड़े को बदल दिया। यहां उनके प्रदर्शन के उदाहरण हैं (ध्यान दें: आरएसए के साथ, हस्ताक्षर सत्यापन तेज है)।

आरएसए:

 ~/c0d3/boringssl bazel run -- //:bssl speed -filter 'RSA 2048' Did ... RSA 2048 signing operations in ..............  (1527.9 ops/sec) Did ... RSA 2048 verify (same key) operations in .... (37066.4 ops/sec) Did ... RSA 2048 verify (fresh key) operations in ... (25887.6 ops/sec) 

ECDSA:

 ~/c0d3/boringssl bazel run -- //:bssl speed -filter 'ECDSA P-256' Did ... ECDSA P-256 signing operations in ... (40410.9 ops/sec) Did ... ECDSA P-256 verify operations in .... (17037.5 ops/sec) 

चूंकि RSA-2048 के साथ सत्यापन ECDSA P-256 की तुलना में लगभग तीन गुना तेज है, इसलिए आप ऑपरेशन की गति बढ़ाने के लिए रूट और अंतिम प्रमाणपत्र के लिए RSA का चयन कर सकते हैं। लेकिन सुरक्षा के दृष्टिकोण से, सब कुछ इतना सरल नहीं है: आप विभिन्न क्रिप्टोग्राफिक प्राइमेटरीज की श्रृंखलाएं बनाएंगे, और इसलिए, परिणामी सुरक्षा मापदंडों का स्तर सबसे कम होगा। और यदि आप प्रदर्शन में सुधार करना चाहते हैं, तो हम रूट और अंतिम प्रमाणपत्र के रूप में संस्करण RSA-4096 (और उच्चतर) के प्रमाण पत्र का उपयोग करने की अनुशंसा नहीं करते हैं।

हमने यह भी पाया कि टीएलएस लाइब्रेरी (और संकलन झंडे) चुनने से प्रदर्शन और सुरक्षा दोनों पर महत्वपूर्ण प्रभाव पड़ता है। तुलना करें, उदाहरण के लिए, लिबरेएसएसएल एक ही हार्डवेयर पर स्व-लिखित ओपनएसएसएल के साथ मैकओएस एक्स मोजवे पर बनाता है।

लिब्रेएसएसएल 2.6.4:

 ~ openssl speed rsa2048 LibreSSL 2.6.4 ...                 sign verify sign/s verify/s rsa 2048 bits 0.032491s 0.001505s     30.8 664.3 

ओपनएसएसएल 1.1.1a:

  ~ openssl speed rsa2048 OpenSSL 1.1.1a  20 Nov 2018 ...                 sign verify sign/s verify/s rsa 2048 bits 0.000992s 0.000029s   1208.0 34454.8 

हालांकि, टीएलएस हैंडशेक बनाने का सबसे तेज़ तरीका यह बिल्कुल नहीं है! हमने जीआरपीसी-कोर और जीआरपीसी-पायथन में सत्र बहाली के लिए समर्थन शामिल किया है, जिससे तैनाती के दौरान सीपीयू पर लोड कम हो जाता है।

एन्क्रिप्शन सस्ता है

कई लोग गलती से मानते हैं कि एन्क्रिप्शन महंगा है। वास्तव में, यहां तक ​​कि सबसे सरल आधुनिक कंप्यूटर लगभग तुरंत सममित एन्क्रिप्शन करते हैं। एक मानक प्रोसेसर 40 Gb / s प्रति कोर की गति से डेटा को एन्क्रिप्ट और प्रमाणित करने में सक्षम है:

 ~/c0d3/boringssl bazel run -- //:bssl speed -filter 'AES' Did ... AES-128-GCM (8192 bytes) seal operations in ... 4534.4 MB/s 

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

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

उच्च विलंबता डेटा चैनल (BDP)

अनुवादक के नोट: मूल उपशीर्षक में बैंडविड्थ-देरी उत्पाद शब्द का उपयोग किया गया है, जिसका रूसी में स्थापित अनुवाद नहीं है।

ड्रॉपबॉक्स बैकबोन नेटवर्क में कई डेटा सेंटर शामिल हैं । कभी-कभी विभिन्न क्षेत्रों में स्थित नोड्स को आरपीसी के माध्यम से संचार करना पड़ता है, उदाहरण के लिए, प्रतिकृति के लिए। टीसीपी का उपयोग करते समय, सिस्टम कर्नेल एक विशेष कनेक्शन में संचारित डेटा की मात्रा को सीमित करने के लिए ज़िम्मेदार है (/ proc / sys / net / ipv4 / tcp_ {r, w} mem ), हालांकि HTTP / 2 पर आधारित gRPC का अपना उपकरण है प्रवाह नियंत्रण। Grpc-go में BDP की ऊपरी सीमा सख्ती से 16 MB तक सीमित है , जो एक अड़चन को ट्रिगर कर सकती है।

net.Server गोलंग या grpc.Server

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

golang / protobuf या गोगो / protobuf

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

हमेशा की तरह, गोगो / प्रोटोबॉफ़ के लिए संक्रमण कुछ चिंताओं के साथ था , लेकिन यदि आप यथोचित कार्यक्षमता को सीमित करते हैं, तो कोई समस्या नहीं होनी चाहिए।

कार्यान्वयन का विवरण

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

सेवा विवरण

परीक्षण सेवा परिभाषा के एक अंश पर एक नज़र डालें:

 service Test {   option (rpc_core.service_default_deadline_ms) = 1000;   rpc UnaryUnary(TestRequest) returns (TestResponse) {       option (rpc_core.method_default_deadline_ms) = 5000;   }   rpc UnaryStream(TestRequest) returns (stream TestResponse) {       option (rpc_core.method_no_deadline) = true;   }   ... } 

जैसा कि ऊपर कहा गया है, सभी कूरियर विधियों के लिए एक समय सीमा आवश्यक है। निम्नलिखित विकल्प का उपयोग करके, आप पूरी सेवा के लिए समय सीमा निर्धारित कर सकते हैं:

 option (rpc_core.service_default_deadline_ms) = 1000; 

एक ही समय में, प्रत्येक विधि को अपनी स्वयं की समय सीमा पर सेट किया जा सकता है, संपूर्ण सेवा की समय सीमा को रद्द कर सकता है (यदि कोई हो):

 option (rpc_core.method_default_deadline_ms) = 5000; 

दुर्लभ मामलों में जब समय-सीमा समझ में नहीं आती है (उदाहरण के लिए, संसाधन को ट्रैक करते समय), डेवलपर इसे अक्षम कर सकता है:

 option (rpc_core.method_no_deadline) = true; 

इसके अतिरिक्त, सेवा विवरण में विस्तृत एपीआई प्रलेखन होना चाहिए, संभवतः उपयोग उदाहरणों के साथ।

ठूंठ पीढ़ी

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

यह डिफ़ॉल्ट gRPC सर्वर स्टब्स जैसा दिखता है:

 func _Test_UnaryUnary_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {       in := new(TestRequest)       if err := dec(in); err != nil {               return nil, err       }       if interceptor == nil {               return srv.(TestServer).UnaryUnary(ctx, in)       }       info := &grpc.UnaryServerInfo{               Server: srv,               FullMethod: "/test.Test/UnaryUnary",       }       handler := func(ctx context.Context, req interface{}) (interface{}, error) {               return srv.(TestServer).UnaryUnary(ctx, req.(*TestRequest))       }       return interceptor(ctx, in, info, handler) } 

सभी प्रसंस्करण अंदर होता है: प्रोटोबुफ़ को डिकोड करना, इंटरसेप्टर लॉन्च करना (कोड में interceptor चर देखें), यूनेरी हैंडलर लॉन्च करना।

अब कूरियर स्टब्स पर एक नज़र डालें:

 func _Test_UnaryUnary_dbxHandler(       srv interface{},       ctx context.Context,       dec func(interface{}) error,       interceptor grpc.UnaryServerInterceptor) (       interface{},       error) {       defer processor.PanicHandler()       impl := srv.(*dbxTestServerImpl)       metadata := impl.testUnaryUnaryMetadata       ctx = metadata.SetupContext(ctx)       clientId = client_info.ClientId(ctx)       stats := metadata.StatsMap.GetOrCreatePerClientStats(clientId)       stats.TotalCount.Inc()       req := &processor.UnaryUnaryRequest{               Srv: srv,               Ctx: ctx,               Dec: dec,               Interceptor: interceptor,               RpcStats: stats,               Metadata: metadata,               FullMethodPath: "/test.Test/UnaryUnary",               Req: &test.TestRequest{},               Handler: impl._UnaryUnary_internalHandler,               ClientId: clientId,               EnqueueTime: time.Now(),       }       metadata.WorkPool.Process(req).Wait()       return req.Resp, req.Err } 

यहाँ कोड काफ़ी है, तो चलिए इसे पार्स करते हैं।

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

 defer processor.PanicHandler() 

एक और कारण है कि हम अपना स्वयं का पैनिक हैंडलर चलाते हैं, यह सुनिश्चित करने के लिए कि कोई त्रुटि होने पर एप्लिकेशन क्रैश हो जाता है। इस मामले में मानक गोलंग / नेट HTTP हैंडलर समस्या की अनदेखी करेगा और नए अनुरोधों (यहां तक ​​कि क्षतिग्रस्त और असंगत) की सेवा करना जारी रखेगा।

फिर हम आने वाले अनुरोध के मेटाडेटा के आधार पर मूल्यों को फिर से परिभाषित करते हुए संदर्भ पास करते हैं:

 ctx = metadata.SetupContext(ctx) clientId = client_info.ClientId(ctx) 

हम अधिक विस्तृत एकत्रीकरण के लिए सर्वर-साइड क्लाइंट आँकड़े (और अधिक दक्षता के लिए कैश) भी बनाते हैं:

 stats := metadata.StatsMap.GetOrCreatePerClientStats(clientId) 

यह रेखा निष्पादन के दौरान प्रत्येक ग्राहक (यानी, TLS पहचानकर्ता) के लिए आँकड़े बनाती है। हमारे पास प्रत्येक सेवा के लिए सभी तरीकों पर आंकड़े भी हैं। चूंकि स्टब जनरेटर में कोड जनरेशन के दौरान सभी तरीकों तक पहुंच होती है, इसलिए हम उन्हें स्टेटिकली पहले से बना सकते हैं, जिससे प्रोग्राम को धीमा करने से बचा जा सकता है।

उसके बाद, हम एक अनुरोध संरचना बनाते हैं, इसे कार्य पूल में स्थानांतरित करते हैं और निष्पादन की प्रतीक्षा करते हैं:

 req := &processor.UnaryUnaryRequest{       Srv:        srv,       Ctx:        ctx,       Dec:        dec,       Interceptor:    interceptor,       RpcStats:       stats,       Metadata:       metadata,       ... } metadata.WorkPool.Process(req).Wait() 

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

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

विभिन्न अनुप्रयोगों के लिए विशिष्ट त्रुटि कोड

हमारे स्टब जनरेटर भी डेवलपर्स को विशेष विकल्पों का उपयोग करके एप्लिकेशन-विशिष्ट त्रुटि कोड निर्दिष्ट करने की अनुमति देता है:

 enum ErrorCode { option (rpc_core.rpc_error) = true; UNKNOWN = 0; NOT_FOUND = 1 [(rpc_core.grpc_code)="NOT_FOUND"]; ALREADY_EXISTS = 2 [(rpc_core.grpc_code)="ALREADY_EXISTS"]; ... STALE_READ = 7 [(rpc_core.grpc_code)="UNAVAILABLE"]; SHUTTING_DOWN = 8 [(rpc_core.grpc_code)="CANCELLED"]; } 

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

पायथन परिवर्तन

पायथन स्टब्स सभी कूरियर हैंडलर्स में एक स्पष्ट संदर्भ पैरामीटर जोड़ते हैं:

 from dropbox.context import Context from dropbox.proto.test.service_pb2 import (       TestRequest,       TestResponse, ) from typing_extensions import Protocol class TestCourierClient(Protocol):   def UnaryUnary(           self,           ctx, # type: Context           request, # type: TestRequest           ):       # type: (...) -> TestResponse       ... 

पहले तो यह अजीब लग रहा था, लेकिन समय के साथ, डेवलपर्स को स्पष्ट रूप से ctx की आदत हो गई, जैसे वे स्वयं को इस्तेमाल करते थे।

कृपया ध्यान दें कि हमारे स्टब पूरी तरह से मैपी के लिए टाइप किए गए हैं, जो कि प्रमुख रिफैक्टरिंग के दौरान ऑफसेट है। इसके अलावा, कुछ आईडीई (जैसे PyCharm) के साथ एकीकरण सरल है।

स्थैतिक टाइपिंग के लिए प्रवृत्ति का पालन करने के लिए जारी रखते हुए, हम प्रोटोकॉल में स्वयं के लिए खसरा एनोटेशन जोड़ते हैं:

 class TestMessage(Message):   field: int   def __init__(self,       field : Optional[int] = ...,       ) -> None: ...   @staticmethod   def FromString(s: bytes) -> TestMessage: ... 

ये एनोटेशन कई सामान्य बगों से बचेंगे, जैसे कि प्रकार स्ट्रिंग के क्षेत्र में कोई नहीं का मान निर्दिष्ट करना ।

यह कोड यहाँ उपलब्ध है ।

प्रवासन की प्रक्रिया

नया RPC स्टैक बनाना कोई आसान काम नहीं है, लेकिन अगर आप ऑपरेटिंग कॉम्प्लेक्सिटी के दृष्टिकोण से देखते हैं, तो इसके पूर्ण संक्रमण की प्रक्रिया के आगे भी खड़े नहीं होते हैं। इसलिए, हमने पुराने आरपीसी से कूरियर तक के डेवलपर्स के लिए संक्रमण को आसान बनाने की कोशिश की। चूंकि प्रवासन अक्सर त्रुटियों के साथ होता है, इसलिए हमने इसे चरणों में लागू करने का निर्णय लिया।

चरण 0: पुराने आरपीसी को फ्रीज करें

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

चरण 1: पुराने आरपीसी और कूरियर के लिए सामान्य इंटरफ़ेस

हमने पुराने आरपीसी और कूरियर के लिए एक सामान्य इंटरफ़ेस को परिभाषित करके शुरू किया। हमारी कोड पीढ़ी यह सुनिश्चित करने वाली थी कि स्टब्स के दोनों संस्करण इस इंटरफ़ेस के अनुरूप हैं:

 type TestServer interface {  UnaryUnary(     ctx context.Context,     req *test.TestRequest) (     *test.TestResponse,     error)  ... } 

चरण 2: नए इंटरफ़ेस पर माइग्रेट करें

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

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

चरण 3: ग्राहकों को आरपीसी कूरियर में माइग्रेट करें

माइग्रेशन प्रक्रिया के दौरान, हमने एक ही मशीन के विभिन्न पोर्ट पर पुराने और नए दोनों सर्वरों को एक साथ लॉन्च करना शुरू किया। क्लाइंट-साइड RPC कार्यान्वयन स्विचिंग एक पंक्ति को बदलकर किया गया था:

 class MyClient(object): def __init__(self): -   self.client = LegacyRPCClient('myservice') +   self.client = CourierRPCClient('myservice') 

कृपया ध्यान दें कि इस मॉडल के साथ, आप एक ग्राहक को एक समय में स्थानांतरित कर सकते हैं, जिसकी शुरुआत SLA के निम्न स्तर के साथ होती है।

चरण 4: सफाई

, , RPC ( ). — .

निष्कर्ष

, Courier — RPC-, , Dropbox.

, Courier:

1. — . .
   
2. — , .
   
3. , . Codegen.
   
4. . , , . , : .
   
5. RPC- — , . . .
   

Courier, gRPC , , , .

gRPC Python , C++ Python Rust . ALTS TLS- (, ).