संस्करण नियंत्रण के माध्यम से स्थिरता

इंजीनियरी

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

प्रोटोकॉल बफर फाइलों का कैसे विन्यस्त किया जाए?

आवश्यकताओं के आधार पर आपकी प्रोटो परिभाषाएँ सेट करना कंपनी से कंपनी या ऐप से ऐप में भिन्न हो सकता है। जीआरपीसी प्रोटोकॉल को डिज़ाइन किया गया था ताकि यह एक स्कीमा को लागू करने के लिए प्रोटोकॉल बफ़र्स या .proto फ़ाइलों का उपयोग कर सके जो एक सर्वर और क्लाइंट उत्पन्न कर सकता है जो परिभाषित स्वरूपों के बाद संदेश भेज सकता है। सबसे पहले आप दो अलग-अलग जीथब रेपो या फ़ोल्डर्स में दो स्थानों पर एक .proto फ़ाइल सेट कर सकते हैं जो सामान्य मॉड्यूल साझा नहीं करते हैं और कनेक्ट करने के लिए लेगो ब्लॉक प्राप्त करते हैं। किसी बिंदु पर आप कई सेवा परिभाषाओं और संदेशों के साथ समाप्त हो सकते हैं जो रेपो में डुप्लिकेट हैं। जीआरपीसी के साथ आप कोड को डुप्लिकेट होने से रोकने के लिए उन मॉड्यूल को आयात कर सकते हैं जिनकी आपको फाइलों में जरूरत है। उस नोट पर फाइलों को मचान बनाने और निर्भरता प्रबंधकों को आपके ऐप के अंदर उपयोग करने के लिए npm, कार्गो, या भेजने के लिए एक केंद्रीय स्थान सेटअप करने में मदद मिल सकती है। संगीतकार । इसका एक उदाहरण इस स्थान पर पाया जा सकता है और npm i @a11ywatch/protos चलाकर npm (नोड पैकेज मैनेजर) का उपयोग करके परीक्षण किया जा सकता है। आप नोड_मॉड्यूल के अंदर परिभाषा फ़ाइलें देखेंगे।.

एनपीएम से अंदर प्रोटो बफर का उपयोग कर `npm i @a11ywatch/protos` खोल में।. — नोड_मॉड्यूल के अंदर प्रोटो फाइलों का उदाहरण

सेवर के बाद वर्जनिंग से लाभ होता है.

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

बाइनरी ब्रेकिंग परिवर्तन

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