التوافق إلى الأمام

ما هو التوافق إلى الأمام

التوافق الأمامي هو قدرة النظام على العمل بشكل صحيح مع العملاء أو البيانات الأحدث من تلك التي تم تصميمه من أجلها في الأصل. أبسط: لا ينكسر الخادم القديم عندما يأتي إليه عميل جديد ؛ المستهلك القديم لا يسقط عندما يواجه رسالة جديدة.

يختلف Forward عن التوافق الخلفي (عندما يدعم النظام الجديد العملاء القدامى) في اتجاه المسؤولية: نحن نصمم البروتوكولات والعملاء بطريقة «للبقاء» على قيد الحياة في الامتدادات المستقبلية دون ترقية كاملة للنظام البيئي بأكمله.

المبادئ الأساسية

1. قارئ متسامح وكاتب متسامح

يتجاهل القارئ الحقول/الرؤوس غير المعروفة ويسمح بقيم جديدة مع الاحتياطي الصحيح.
لا يرسل الكاتب أي شيء لم يعلن الخادم صراحة أنه مدعوم (قدرات).

2. التفاوض بشأن القدرات

التبادل الصريح للقدرات (السمات/الإصدارات/أنواع الوسائط) في مرحلة المصافحة. يقوم العميل بتكييف سلوكه مع استجابة الخادم.

3. التدهور الافتراضي

تعتبر الميزات الجديدة اختيارية: إذا لم يدعمها الخادم/المستهلك، فسيظل البرنامج النصي ينتهي بحد أدنى مفيد (MGC).

4. النواة المستقرة (MGC)

لم يتغير عقد الضمان الأدنى ؛ الابتكارات تعيش على أنها امتدادات.

5. عقود الخطأ كجزء من البروتوكول

تسمح الرموز/الأسباب التي يمكن التنبؤ بها («ميزة غير مدعومة»، «نوع الوسائط غير معروف») للعميل بالعودة تلقائيًا إلى الوضع المدعوم.

6. إصدارات بدون مفاجآت

فصل الخطوط الرئيسية ؛ ولا تتطلب عمليات التمديد الطفيفة ترقية الخادم/المستهلك.

حيث يهم

واجهات برمجة التطبيقات العامة ذات الاندماجات الطويلة الأمد (شركاء، SDKs في تطبيقات الهاتف المحمول).
منصات الأحداث مع العديد من المستهلكين المستقلين.
عملاء الهاتف المحمول الذين يقومون بالتحديث بشكل أبطأ من الخلف.
Edge/IoT، حيث نادرًا ما يتم وميض جزء من أسطول الجهاز.

أنماط التنفيذ حسب الأسلوب

REST/HTTP

• "قبول "/أنواع الوسائط مع المعلمات (" تطبيق/vnd. مثال على ذلك. وطلب + جسون ؛ v = 1; profile = risk ').
• "أفضل: تضمين =... من أجل كتل إختيارية
• العنوان 'X-Features: risk_score,item_details_v2'.

• يرسل الطلب في شكل أساسي، الامتدادات - فقط إذا كان الخادم لديه قدرة مؤكدة (عبر OPTIONS/desc/lead endpoint).
• عندما يتم إعادة «415/406/501» تلقائيًا إلى تنسيق/طريقة مدعومة.
• استجابة الخادم: بارامترات غير معروفة - تجاهل ؛ ويسمح بحقول إضافية ؛ شكل خطأ مستقر ('نوع/رمز/تفصيل/تتبع _ معرف').

gRPC/Protobuf

الخدمات المستقرة: طرق/مجالات جديدة - مواد مضافة ؛ الخادم القديم يتجاهل بهدوء مجالات الطلب غير المعروفة.
اكتشاف الميزة: طريقة «GetFactions ()» ترجع قوائم الميزات/الحدود. لا يتصل العميل بطريقة v2 إلا إذا أعلن الخادم ذلك.
البث: تحديد ترتيب المجموعة الدنيا من الرسائل ؛ ضع علامة على «إطارات» جديدة مع ملحقات/أنواع يتجاهلها العميل القديم.

الرسم البياني QL

صديقة للأمام: تظهر مجالات/أنواع جديدة على الخادم - العملاء القدامى ببساطة لا يطلبونها.
التخمينات ممنوعة: يجب على العميل الاحتفاظ بالنظام (الاستبطان/الكودوجين) وعدم إرسال توجيهات/متغيرات غير معروفة.
التحلل: إذا كان الخادم لا يعرف توجيه العرف/الميزة، يقوم العميل ببناء طلب بدونه.

الحدث مدفوع (كافكا/ناتس/بولسار، أفرو/جسون/بروتو)

التوافق المستقبلي للمخطط في السجل: يمكن للمستهلكين القدامى قراءة الرسائل المكتوبة بواسطة المخطط الجديد.
الحقول المضافة مع التخلف عن السداد: المنتجون الجدد لا يكسرون المستهلكين القدامى.
Core vs Enriched: تظل النواة كما هي، ويتم نشر معلومات جديدة في «.enriched» أو كمجالات اختيارية.

ممارسات التصميم

1. عقد الطلب الأدنى (MGC)

يجب أن يكون للعملية «رقبة ضيقة» ستدعمها جميع الخوادم لسنوات عديدة.

2. ميزة الأعلام على مستوى العقد

وصف الميزات بالميزات المسماة: «المخاطرة _ النتيجة»، «التسعير _ v2»، «القوة _ الخصوصية». يقوم العميل بتضمينها صراحة.

3. رموز خطأ صريحة لـ «غير مدعومة»

HTTP: «501 لم يتم تنفيذه»، «415 نوع الوسائط غير المدعومة»، детальные «مشكلة + جسون».
gRPC: 'UNIMPLED '/' FAILLED _ PRECONDITION'.
الأحداث: الطريق في DLQ مع «reason = غير مدعوم _ ميزة».

4. لا تعتمد على قوائم الطلبات/القوائم الكاملة

يجب أن يكون العميل جاهزًا لقيم جديدة، ولا حقول جديدة، وخصائص «إضافية».

5. معرفات وأشكال ثابتة

لا تغير تنسيق مفاتيح الهوية/التقسيم داخل السطر - فهذا يكسر إلى الأمام على جانب القراء.

6. وثائق «مقروءة آليا»

واصفات المضيف: OpenAPI/AsyncAPI/Proto descriptors/GraphQL SDL. يمكن للعملاء التحقق من دعم الميزة.

اختبار التوافق الأمامي

Schema-diff in FORWARD/FULL mode: المخطط الجديد يتحقق من صحة المستهلك/الخادم القديم.
اختبارات عقد العميل: يتم تنفيذ عميل جديد مقابل خادم قديم مع ميزات ممكنة/معطلة.
الطلبات الذهبية: يتم تشغيل مجموعة من الطلبات «الجديدة» من خلال الخادم «القديم» ؛ التدهور المتوقع دون أخطاء فادحة.
الفوضى/زمن الانتظار: التحقق من المهلة/إعادة الدفع - يجب على العميل الجديد النجاة بشكل صحيح من أسوأ SLAs للخادم القديم.
كناري: يعمل بعض العملاء الجدد مع إصدار الخادم السابق - نجمع القياس عن بعد للأخطاء/التحلل.

إمكانية الرصد والمقاييس التشغيلية

النسبة المئوية للطلبات/الرسائل ذات الميزات غير المدعومة والتراجع التلقائي عنها.
التوزيع حسب نسخ العملاء (المستخدم - الوكيل/البيانات الفوقية/المطالبات).
«UNIMPLENTED/501/415» أخطاء وطرق في DLQ مع «ميزة _ غير مدعومة».
وقت التحلل: p95/p99 لـ MGC مقابل الاستجابة «الموسعة».

أنماط التوافق في سجل المخطط

إلى الأمام: الإدخال الجديد متوافق مع القارئ القديم (هناك حاجة إلى التخلف عن السداد والاختيارية).
كامل: и إلى الأمام، и إلى الخلف ؛ ملائمة للعقود العامة.
التوصية: للأحداث - BACKWARD للمنتج و FORWARD للمستهلك (عبر قارئ متسامح)، لواجهات برمجة التطبيقات الخارجية - FULL.

أمثلة

REST (القدرات + التحلل)

1. يصنع العميل «GET/meta/factions' →» {«risk _ score»: خطأ، «price_v2": صحيح}».
2. في «البريد/الطلبات» ترسل الحقول الأساسية ؛ لا يطلب «risk _ score»، لأن الخادم لا يمكنه القيام بذلك.
3. إذا تم إرسال «تفضيل: تضمين = risk _ score» عن طريق الخطأ، يستجيب الخادم بـ 200 بدون حقل «risk _ score» (أو «Preference-Applied: none») - العميل لا يتعطل.

gRPC (اكتشاف)

قائمة/ميزة الطريقة المرتجعة «GetFactions ()». لا يتصل العميل بـ «CaptureV2» إذا لم يكن موجودًا - بدلاً من ذلك باستخدام «Capture» وتحويل المدخل محليًا إلى عرض مدعوم.

الأحداث (إلى الأمام في السجل)

أضاف المنتج حقل «المخاطرة _ النتيجة» (غير قابل للإلغاء مع الافتراض). المستهلك القديم يتجاهله ؛ منطقها يستخدم فقط حقول النواة المستقرة.

Antipatterns

العميل الصعب: يقوم بتصفية الاستجابة من خلال حقول القائمة البيضاء ويسقط على عقار غير مألوف.
الميزات الضمنية: يبدأ العميل في إرسال معلمة جديدة دون التحقق من القدرات.
تغيير تنسيقات الهوية/المفاتيح داخل الخط → لم تعد الخوادم/المستهلكون القدامى يفهمون الطلبات/الرسائل الجديدة.
افتراضات صلبة حول القائمة الكاملة (التبديل بدون افتراض).
تسجيل الدخول كتحكم في التدفق: تحليل سلاسل الخطأ بدلاً من رموز العقد.

قائمة التنفيذ المرجعية

• تعريف MGC ؛ تم تمييز السمات الجديدة على أنها اختيارية.
• وصف وتنفيذ عملية التفاوض بشأن القدرات (نقطة النهاية/البيانات الفوقية/المصافحة).
• يتجاهل العملاء المجالات غير المألوفة ويتعاملون بشكل صحيح مع enum (احتياطي) جديد.
• تسجيل عقود الخطأ «غير مدعوم» بشكل متوقع (HTTP/gRPC/Event).
• تم تعيين سجل المخطط على FORWARD/FULL للتحف المقابلة.
• الاختبارات الذاتية: schema-diff (FORWARD)، اختبارات عقد العميل مقابل عقد الخادم القديم، الكناري.
• المقاييس: نسخة العميل، فشل الميزة، معدل التحلل، p95 MGC.
• تنشر الوثائق/قواعد البيانات الخاصة قائمة بالميزات والأمثلة على التدهور.

الأسئلة الشائعة

كيف يختلف الأمام عن الخلف في الممارسة ؟

إلى الوراء: الخادم الجديد لا يكسر العملاء القدامى. إلى الأمام: الخادم القديم لا ينفصل عن العملاء الجدد (أو المستهلك القديم من الرسائل الجديدة). من الناحية المثالية، تصل بالكامل.

هل أحتاج دائمًا إلى دخول القدرات ؟

إذا كنت تتوقع تطورًا نشطًا بدون إصدارات متزامنة، نعم. إنه أرخص من الاحتفاظ بالعشرات من الخطوط الرئيسية.

ماذا عن الأمن ؟

يجب أن تتطلب الميزات الجديدة نطاقات/مطالبات منفصلة. إذا لم يدعمهم الخادم، فلا ينبغي للعميل تقليل الأمان، ولكن يجب التخلي عن الميزة.

هل من الممكن «تخمين» الدعم عن طريق إصدار الخادم ؟

غير مرغوب فيه. من الأفضل أن نسأل (القدرات) صراحة أو ننظر إلى نوع/مخطط الوسائط.

المجموع

قابلية التشغيل المتبادل إلى الأمام هي انضباط فرص التفاوض ومهينة بأمان. يسمح النواة المستقرة والتفاوض على القدرات والتمديدات الإضافية والأخطاء التي يمكن التنبؤ بها للعملاء الجدد والبيانات بالتوافق مع الخوادم والمستهلكين القدامى - دون الإصدارات الجماعية والهجرات الليلية.