पिछड़ा संगतता

पिछड़ी संगतता क्या है

पिछड़ी संगतता - सिस्टम के अद्यतन होने पर पुराने ग्राहकों/उपभोक्ताओं को स्वीकार करने और सही ढंग से संसाधित करने के लिए सिस् सरल: आप सेवा/घटनाओं का एक नया संस्करण जारी करते हैं, और मौजूदा एकीकरण अपरिवर्तित काम करना जारी रखते हैं।

कुंजी: समझौतों को न तोड़ें। कोई भी विकास जोड़ ने के माध्यम से है, रीमेकिंग नहीं, पहले से ही जारी एक।

मूल सिद्धांत

1. एडिटिव-फर्स्ट

नए क्षेत्र/विधियाँ/घटनाएँ वैकल्पिक रूप से जोड़ी जाती हैं। मौजूदा कुछ भी नहीं हटाया जाता है और अर्थ नहीं बदलता है।

2. न्यूनतम वारंटी संविदा (एमजीसी)

कर्नेल को परिभाषित करें - क्षेत्रों/संक्रियाओं का एक सेट जिसके बिना स्क्रिप्ट अपना अर्थ खो देती है। कोर स्थिर है। बाकी सब कुछ एक्सटेंशन है।

3. सहिष्णु पाठक

क्लाइंट अज्ञात क्षेत्रों को अनदेखा करते हैं और नया एनम (फॉलबैक) मानों को सही ढंग से

4. संस्करण नीति

ब्रेकिंग चेंज - केवल प्रमुख लाइन ('/v2 ',' भुगतान के माध्यम से। v2 ',' घटना। v2 ')। माइनर - एडिटिव।

5. अवलोकन - संविदा का हिस्सा

क्लाइंट संस्करण, प्रारूप, क्षमता फ्लैग लॉग/ट्रैक और मैट्रिक्स में दिखाई देते हैं। यह आपको अपने माइग्रेशन को प्रबंधित करने की अ

सुरक्षित बनाम खतरनाक परिवर्तन

आम तौर पर सुरक्षित (बीसी-ओके)

वैकल्पिक फ़ील्ड जोड़ें (JSON/Avro/Protobuf 'वैकल्पिक '/' nullable').
नया समापन बिंदु/विधियाँ/घटनाएँ जोड़ें.

अतिरिक्त मानों के साथ एनम एक्सटेंशन (सहिष्णु पाठक के साथ)।

सत्यापन का कमजोर होना (अधिकतम, वैकल्पिक प्रारूपों के अलावा)।

गैर-सार्थक शीर्षिका/मेटाडेटा जोड़ें।

खतरनाक (ब्रेकिंग)

क्षेत्रों को मिटाएँ/नाम बदलें, मौजूदा क्षेत्रों के प्रकार या अनिवार्य बदलें।

स्थिति/त्रुटि कोड शब्दार्थ बदलते हैं।

अन्य क्षेत्रों के लिए प्रोटोबुफ टैग का पुन: उपयोग करें।

घटना विभाजन कुंजी बदलना (कुल के लिए क्रम को तोड़ ता है)।

SLAs/टाइमआउट को कसना, जिससे पुराने ग्राहक गिरना शुरू हो जाते हैं।

इंटरैक्शन स्टाइल्स द्वारा

REST/HTTP + JSON

एडिटिविटी: नया फ़ील्ड - 'वैकल्पिक', सर्वर को पुराने क्लाइंट से उनकी आवश्यकता नहीं है।

संस्करण: प्रमुख - पारगमन ('/v2 ') या मीडिया प्रकार; मामूली - एक्सटेंशन के माध्यम से और '? शामिल = '/'? फ़ील्ड्स = '।

त्रुटियां: समान प्रारूप; प्रमुख के बिना कोड/शब्दार्थ न बदलें।

ETag/If-Match: रेसिंग के बिना सुरक्षित अपडेट के लिए।

Idempotency: POST के लिए 'Idempotency-Key' - पुराने ग्राहक रिट्रीट पर प्रभाव को 'दोगुना' नहीं करते हैं।

gRPC/Protobuf

टैग अपरिवर्तित हैं। मिटाए गए टैग पुनः प्रयोग नहीं किए जा सकते.

नए क्षेत्र - 'वैकल्पिक '/' दोहराया'; डिफ़ॉल्ट मानों को पुराने कोड द्वारा सही ढंग से संभाला जाता

स्ट्रीमिंग: नाबालिग के भीतर संदेशों के आदेश/दायित्व को न बदलें।

त्रुटियाँ - स्टेटस का एक स्थिर सेट; नए शब्दार्थ - नई विधि/सेवा ('.v2')।

इवेंट-चालित (काफ्का/एनएटीएस/पल्सर) + एवरो/जेसन/प्रोटो

नामकरण: 'डोमेन। क्रिया। v {प्रमुख} '।

कोर बनाम समृद्ध: कोर स्थिर; संवर्धन - व्यक्तिगत प्रकार/थीम ('.enriched')।

स्कीमा संगतता मोड: अधिक बार बैकवर्ड; सीआई असंगत परिवर्तनों को अवरुद्ध करता है।

विभाजन: कुंजी (उदाहरण के लिए, 'भुगतान _ आईडी') - अनुबंध का हिस्सा; इसे बदलना - तोड़ ना।

ग्राफ़क्यूएल

फ़ील्ड/प्रकार जोड़ ना - ठीक है; '@ deprecated' और माइग्रेशन विंडो के माध्यम से/नाम बदलें।

प्रमुख के बिना "शून्य → गैर-शून्य" नहीं उठाएं।

जटिलता/गहराई - सीमा परिवर्तन = संविदा परिवर्तन की निगरानी करें।

बीसी के संरक्षण में मदद करने के लिए पैटर्न

रिवर्स पिरामिड मॉडल: कोर को स्थिर करें, वैकल्पिक रूप से विस्तार करें।

क्षमता वार्ता: क्लाइंट रिपोर्ट समर्थित क्षमताएं ('एक्स-क्षमताएं '/हैंडशेक), सर्वर समायोजित करता है।

डुअल-रन/डुअल-एमिट: प्रवास के दौरान एक ही समय में 'v1' और 'v2' रखें।

एडेप्टर्स: प्रॉक्सी/गेटवे "भारी" ग्राहकों के लिए 'v1↔v2' अनुरोधों का अनुवाद करते हैं।

विस्तार और अनुबंध (DB के लिए): पहले एक नया जोड़ें, लिखना/पढ़ना शुरू करें, तभी पुराने को हटाएं।

शासन और प्रक्रिया

1. अनुबंध कैटलॉग (स्कीमा रजिस्ट्री): संगतता नीतियों के साथ सत्य का एक एकल स्रोत।

2. CI/CD में लिंटर्स और डिफ़चेक: OpenAPI-diff, Buf-Braing, Avro/JSON स्कीमा संगतता जांच।

3. सीडीसी/उपभोक्ता-चालित अनुबंध: प्रदाता को वास्तविक उपभोक्ता अनुबंधों के लिए परीक्षण किया जाता है।

4. स्वर्ण नमूने: प्रतिगमन के लिए संदर्भ प्रश्न/प्रतिक्रियाएं/घटनाएं।

5. परिवर्तन प्रबंधन: आरएफसी/एडीआर टूटने, सूर्यास्त योजना, संचार पर।

पुराने संस्करणों को हटाना और हटाना

मार्क अप्रचलित ('@ deprecated', विवरण, हेडर 'Deprecation', 'Sunset')।

माइग्रेशन विंडो: पूर्व घोषित तारीख, परीक्षण बेंच, कोड उदाहरण।

उपयोग टेलीमेट्री: 'v1' पर और कौन है? संस्करण द्वारा खंड मेट्रिक्स/लॉग।

शून्य यातायात के लिए दोहरी दौड़, फिर हटाएँ।

अवलोकन और परिचालन मैट्रिक्स

संस्करण के अनुरोध/संदेशों का प्रतिशत।

रिलीज के बाद पुराने क्लाइंट के लिए त्रुटियों/समयसीमा का हिस्सा।

असंगत पेलोड का अनुपात (प्रवेश द्वार/स्ट्रीम फिल्टर पर योजना द्वारा सत्यापन)।

उपभोक्ता प्रवासन अंतराल ('v1' को कितने और सुनते हैं)।

पिछड़ा संगतता परीक्षण

स्कीमा-डिफ़: असफल при हटाएँ/नाम बदलें/टाइप-परिवर्तन.

अनुबंध परीक्षण: पुराने एसडीके/क्लाइंट नए कार्यान्वयन के खिलाफ दौड़।

E2E कैनरी: नए संस्करण के लिए पुराने ट्रैफ़िक का हिस्सा, p95/p99, कोड, रिट्रेज़की तुलना।

घटना रीप्ले: अनुमान बिना विसंगतियों के पुराने लॉग से नए तर्क द्वारा एकत्र किए जाते हैं।

फॉल्ट-इंजेक्शन: देरी/आंशिक प्रतिक्रियाएं - पुराने ग्राहक नहीं गिरते हैं।

उदाहरण

REST (additive)

json
{ "id": "p1", "status": "authorized" }

json
{ "id": "p1", "status": "authorized", "risk_score": 0. 12 }

पुराने ग्राहक, 'रिस्क _ स्कोर' की अनदेखी करते हुए, काम करना जारी रखते हैं।

प्रोटोबुफ (टैग)

proto message Payment {
string id = 1;
string status = 2;
optional double risk_score = 3 ;//new field, safe
}
//Tags 1 and 2 cannot be changed/deleted without v2

घटनाएँ (कोर + संवर्धन)

'भुगतान। अधिकृत। v1 '- कर्नेल (न्यूनतम तथ्य)।

'भुगतान। समृद्ध। v1 '- भागों; कोर उपभोक्ता संवर्धन पर निर्भर नहीं हैं।

एंटीपैटर्न

स्वैगर-वॉश: योजना को अपडेट किया गया है, लेकिन सेवा पुराने तरीके से (या इसके विपरीत) व्यवहार करती है।

छिपे हुए विराम: बिना संस्करण के क्षेत्र/स्थिति का अर्थ बदल दिया।

प्रोटोबुफ टैग का पुन: उपयोग: "शांत" डेटा भ्रष्टाचार।

कठिन ग्राहक: अपरिचित क्षेत्रों/एनम में गिरें; कोई सहिष्णु पाठक नहीं।

मेगा-एंडपॉइंट: एक ऑल-इन-वन - कोई भी बदलाव एक संभावित स्क्रैप बन जाता है।

प्री-रिलीज़चेकलिस्ट

• परिवर्तन योजक हैं; नाभिक (MGC) अछूता है।
• लिंटर्स/डिफ चेक पारित; कोई ब्रेकिंग झंडे नहीं हैं।
• क्लाइंट एसडीके अद्यतन किए गए हैं (या एडिटिव एक्सटेंशन के लिए आवश्यक नहीं हैं)।
• ग्राहकों के लिए सहिष्णु पाठक सक्षम; एनम-फॉलबैक की जाँच की गई।
• मेट्रिक्स/लॉग में संस्करण और क्षमता झंडे होते हैं।
• संभावित टूटने के लिए '/v2 ', डुअल-रन और सूर्यास्त योजना है।
• प्रलेखन/उदाहरण अद्यतन किए गए हैं, सुनहरे सेट हैं।

FAQ

पिछड़ा बनाम आगे - क्या अंतर है?

पिछड़े - नए सर्वर पुराने क्लाइंट के साथ काम करते हैं। फॉरवर्ड - नए ग्राहक पुराने सर्वर (सहिष्णु पाठक और साफ-सुथरे चूक के कारण) के साथ सही ढंग से काम करते हैं। पूर्ण चक्र - पूर्ण संगतता।

क्या मुझे हमेशा बड़े बदलाव के लिए '/v2 'करने की आवश्यकता है?

हां, अगर अपरिवर्तनीय/प्रकार/कुंजी/शब्दार्थ टूटते हैं। अन्यथा, लाइन रखें और अतिरिक्त रूप से विकसित करें।

एनम के बारे में क्या?

पुराने का अर्थ बदले बिना नया मान जोड़ें। ग्राहकों के पास अज्ञात मूल्य पर फॉलबैक होना चाहि

क्या होगा यदि आप पहले ही "टूट" चुके हैं?

रोलबैक, हॉट-फिक्स एडाप्टर, दोहरे रन, संचार और माइग्रेशन गाइड के साथ 'v2' रिलीज।

कुल

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