Ուղղակի համատեղելիություն

Ի՞ նչ է ուղղակի համատեղելիությունը

Ուղղակի համատեղելիությունը (forward compatibility) համակարգի կարողությունն է ճիշտ աշխատել ավելի նոր հաճախորդների կամ տվյալների հետ, քան այն, որոնց տակ այն ի սկզբանե նախագծվել է։ Ավելի հեշտ է, հին սերվերը չի կոտրվում, երբ նոր հաճախորդը գալիս է նրան։ հին սպառողը չի ընկնում, երբ հանդիպում է նոր հաղորդագրություն։

Հետադարձ պայմանագրից (երբ նոր համակարգը աջակցում է հին հաճախորդներին) forward-ը տարբերվում է պատասխանատվության ուղղությունից, մենք ստեղծում ենք արձանագրություններ և հաճախորդներ, որպեսզի «գոյատևենք» ապագա ընդլայնումները առանց ամբողջ էկոհամակարգի տոտալ ապգրեյդի։

Հիմնական սկզբունքները

1. Tolerant reader & tolerant writer

Reader անտեսում է անհայտ դաշտերը/վերնագրերը և թույլ է տալիս նոր enum արժեքներ ճիշտ fallback-ի հետ։

Writer չի ուղարկում ոչինչ, որ սերվերը ակնհայտորեն չի հայտարարել որպես աջակցվող (capabilities)։

2. Capability negotiation

Ակնհայտ հնարավորությունների փոխանակում (ֆիչի/տարբերակներ/լրատվամիջոցների տեսակներ) handshake-փուլում։ Հաճախորդը հարմարեցնում է իր վարքագիծը սերվերի պատասխանին։

3. Դեֆոլտի քայքայումը

Նոր հնարավորությունները համարվում են օբյեկտիվ. Եթե սերվերը/կոնսյումերը չեն աջակցում դրանք, սցենարը դեռ կավարտվի օգտակար նվազագույն (MGC)։

4. Կայուն միջուկը (MGC)

Նվազագույն երաշխիքային պայմանագիրը անփոփոխ է։ նորարարությունները ապրում են որպես ընդարձակումներ։

5. Սխալների պայմանագրերը որպես արձանագրության մաս

Կանխատեսելի պարամետրերը/պատճառները («ֆիչը չի աջակցվում», «մեդիա տիպը անհայտ է») թույլ են տալիս հաճախորդին ինքնաբերաբար արձագանքել աջակցվող ռեժիմին։

6. Վարկածներ առանց անակնկալների

Մագելային գծերը առանձնացված են; մինորի ընդլայնումները չեն պահանջում թարմացնել սերվերը/կոնսյումերը։

Որտե՞ ղ է դա հատկապես կարևոր

Հանրային API-ը երկար ինտեգրումներով (գործընկերներ, MSK բջջային ծրագրերում)։

Իրադարձական պլատֆորմները բազմաթիվ ռուսական կոնսուումերների հետ։

Բջջային հաճախորդները, որոնք նորարարվում են ավելի դանդաղ, քան backend-ը։

Էջ/IoT, որտեղ սարքերի այգու մի մասը հազվադեպ է։

Կատարման արտոնագրերը ըստ ոճերի <>

REST/HTTP

• «Accept '/mediatips's (» application/vnd. example. order+json; v=1; profile=risk`).
• «Delfer: include =...» օպոմանիկական բլոկների համար։
• «X-Capabilities: risk _ score, item _ details _ v2»։
• Հաճախորդի վարքագիծը

Նա ուղարկում է հիմնական ձևաչափով, ընդարձակման միայն եթե սերվերը capability (OPTIONS/desc/lid-endpoint)։

«415/406/501» դեպքում ինքնաբերաբար արձագանքում է աջակցվող ձևաչափին/մեթոդին։

Սերվերի պատասխանը 'անհայտ պարամետրերը' անտեսել; ավելորդ դաշտերը թույլատրվում են. սխալի ձևաչափը («type/code/detail/trace _ id»)։

gRPC / Protobuf

Կայուն ծառայություններ 'նոր մեթոդներ/դաշտեր' ադիտիվ; հին սերվերը հանգիստ անտեսում է անհայտ հարցման դաշտերը։

Feature discovery: «GetCabilities» մեթոդը () վերադարձնում է ֆիչի/լիմիտների ցուցակները։ Հաճախորդը չի առաջացնում «v2 մեթոդ», եթե սերվերը նրան չի հայտարարել։

Սթրիմինգ 'գրանցեք հաղորդագրությունների հավաքագրման կարգը։ նոր «շրջանակները» տեղադրեք ընդարձակումներ/տեսակներ, որոնք հին հաճախորդը անտեսում է։

GraphQL

Forward-friendly: Նոր դաշտերը/տեսակները հայտնվում են սերվերի վրա, հին հաճախորդները պարզապես չեն պահանջում դրանք։

Ենթադրությունները արգելված են. Հաճախորդը պետք է պահպանի սխեման (introsport/կոդոգեն) և չուղարկի անհայտ հրահանգներ/։

Դեգրադացիա 'եթե սերվերը չգիտի կաստոմային հրահանգը/feature, հաճախորդը կառուցում է խնդրանքը առանց դրա։

Event-driven (Kafka/NATS/Pulsar, Avro/JSON/Proto)

FORWARD-ի սխեմայի համատեղելիությունը գրանցամատյանում. Հին կոնսուումերները կարող են կարդալ հաղորդագրությունները, որոնք գրված են նոր սխեմայով։

Դժոխքային դաշտերը դեֆոլտներով. Նոր արտադրողները չեն կոտրում հին վահանակները։

Divs Enriched-ը 'միջուկը մնում է նույնը, նոր տեղեկատվությունը հրապարակվում է «.enriched» կամ որպես օպոզացիոնալ դաշտեր։

Նախագծման պրակտիկա

1. Նվազագույն հարցման պայմանագիրը (MGC)

Վիրահատությունը պետք է ունենա «նեղ պարանոց», որը կպահանջի բոլոր սերվերները երկար տարիներ։

2. Ֆիչա դրոշները պայմանագրի մակարդակում

Օգտագործեք ֆիչիները որպես անվանված հնարավորություններ '«risk _ score», «pricing _ v2», «strong _ idempotency»։ Հաճախորդը ներառում է դրանք հստակ։

3. Ակնհայտ սխալներ «չի աջակցվում»

HTTP: `501 Not Implemented`, `415 Unsupported Media Type`, детальные `problem+json`.
gRPC: `UNIMPLEMENTED`/`FAILED_PRECONDITION`.

Events: DLQ-ի երթուղին '«reason = unsuperted _ feature» -ի հետ։

4. Չապավինել կարգի/ամբողջական ցուցակների

Հաճախորդը պետք է պատրաստ լինի նոր արժեքներին enum, նոր դաշտերի բացակայությանը և «ավելացված» հատկություններին։

5. Կայուն ցուցանիշներ և կայունություններ

Մի փոխեք ID/www.orld-ը գծի մեջ, դա կոտրում է forward-ը ընթերցողների կողմից։

6. Մոսկվան «մեքենայացված»

Դասագրքեր ՝ OpenAPI/AsyncAPI/Descriptors/GraphQL SYL։ Հաճախորդները կարող են նվազեցնել ֆիչի աջակցությունը։

Forward-2019 փորձարկումը

Schema-diff-ը FORWARD/FOX-ի ռեժիմում. Նոր սխեման առաջնորդում է հին սպառողին/սերվերին։

Հաճախորդի պայմանագրային թեստերը 'նոր հաճախորդը կատարվում է հին սերվերի դեմ' միացված/անջատված ավարտներով։

Golden reques.ru-ը '«նոր» հարցումների հավաքածու, անցնում է «հին» տերմինով։ ակնկալվում է առանց կրիտիկական սխալների։

Chaos/latency: Թայմաուտների/ռետրերի ստուգումը, նոր հաճախորդը պետք է ճիշտ գոյատևի հին սերվերի ամենավատ SLA-ը։

Կանարի 'նոր հաճախորդների մի մասը աշխատում է նախորդ սերվերային տարբերակի հետ' հավաքում ենք սխալների/դեգրադացիայի հեռաչափություն։

Դիտարկումը և վիրահատական չափումները

Հարցումների/հաղորդագրությունների մասնաբաժինը չպահպանված եզրափակիչներով և նրանց ավտոմատ արձագանքներով։

Հաճախորդների տարբերակներով բաշխումը (User-Agent/մետատվեներ/claims)։

Սխալները 'UNIMPLEMENTED/501/415 "և DLQ-ի երթուղիները'" unsupronted _ feature "։

Քայքայման ժամանակը 'p95/p99 MGC-ի համար «ընդլայնված» պատասխանը։

Ռեժիմները տեղադրված են ֆայլային սխեմաներում

FORWARD: Նոր ձայնագրությունը համատեղելի է հին ընթերցողի հետ (անհրաժեշտ է դեֆոլտներ, օբյեկտիվություն)։

FULL: и FORWARD, и BACKWARD; հարմար է հանրային տարածքների համար։

Առաջարկություն 'իրադարձությունների համար - BACKWARD արտադրողի և FORWARD-ի մոտ կոնսյուտերի (toler.reader), արտաքին API-ի համար - FBS-ի համար։

Օրինակներ

REST (capabilities + քայքայումը)

1. Հաճախորդը անում է "GET/meta/capabilities" com "risk _ score": false, "price _ v2": www.com "։

2. «POST/orders» -ի վրա ուղարկում է հիմնական դաշտերը, «risk _ score» -ը չի պահանջում, որովհետև սերվերը չգիտի ինչպես։

3. Եթե պատահականորեն ուղարկեց «Disfer: include = risk _ score», սերվերը համապատասխանում է 200-ին առանց «risk _ score» (կամ «Disference-Appied: none») - հաճախորդը չի ընկնում։

gRPC (discovery)

«GetCabilities ()» վերադարձրեց մեթոդների/ֆիչի ցանկը։ Հաճախորդը չի առաջացնում «Captom V2», եթե ոչ, փոխարենը օգտագործում է «Capture» և տեղական վերածում է մուտքային տվյալները մինչև աջակցված տեսակը։

Events (FORWARD 1922)

Արտադրողը ավելացրեց «risk _ score» դաշտը (nullable հետ)։ Հին կոնսյումերը անտեսում է այն։ նրա տրամաբանությունը օգտագործում է միայն կայուն միջուկի դաշտերը։

Antipatterny

Կոշտ հաճախորդը 'ֆիլտրում է պատասխանը whitelist-210 մ-ով և ընկնում անծանոթ հատկության վրա։

Ակնհայտ ֆիչին 'հաճախորդը սկսում է ուղարկել նոր պարամետրեր առանց ստուգելու capabilities։

ID/105 ձևաչափերի փոփոխությունը ստանդարտ հին սերվերների/կոնսյուրմերների սահմաններում դադարում է հասկանալ նոր հարցումները/հաղորդագրությունները։

Պարզ ենթադրություններ enum ամբողջական ցուցակի մասին (switch առանց ռուսական)։

Լոգավորումը որպես հոսքի վերահսկողություն 'սխալների տողերի պարսինգը պայմանագրային շարժիչների փոխարեն։

Ներդրման թուղթ

• Peter MGC; նոր հնարավորությունները նշվում են որպես օբյեկտիվ։
• Մոսկվան իրականացվել է capability negotiation (endpoint/metranten/handshake)։
• Հաճախորդները անտեսում են անծանոթ դաշտերը և ճիշտ կերպով մշակում նոր enum (fallback)։
• Սխալների պայմանագրերը «չեն աջակցվում» կանխատեսելի (HTTP/gRPC/Event)։
• Ֆայլային սխեմաները տրամադրված են FORWARD/FOX-ում համապատասխան արտեֆակտների համար։
• Avtotests: schema-diff (FORWARD), հաճախորդի պայմանագրային թեստեր հին սերվերի դեմ, canary։
• Metriki: Հաճախորդի տարբերակը, հրաժարվելը, քայքայման մասը, p95 MGC։
• System/MSK-ը հրապարակում են ֆիգերի ցուցակը և դեգրադացիայի օրինակները։

FAQ

Ինչպե՞ ս է forward տարբերվում backward գործնականում։

Backward: Նոր սերվերը չի կոտրում հին հաճախորդներին։ Forward: Հին սերվերը չի կոտրվում նոր հաճախորդներից (կամ հին կոնսյումերից 'նոր հաղորդագրություններից)։ Իդեալում դուք հասնում եք fox-ի։

Պե՞ տք է արդյոք միշտ ներմուծենք capabilities։

Եթե ակնկալում եք ակտիվ էվոլյուցիա առանց սինխրոն խառնուրդների, այո։ Սա ավելի էժան է, քան տասնյակ major գծեր պահել։

Ինչպե՞ ս կարող ենք ապահով լինել։

Նոր ֆիչիները պետք է պահանջեն առանձին scopes/claims։ Եթե սերվերը չի աջակցում նրանց, հաճախորդը չպետք է նվազեցնի անվտանգությունը, այլ պետք է հրաժարվի ֆիչիից։

Կարո՞ ղ եք «կռահել» աջակցությունը սերվերի տարբերակով։

Անցանկալի է։ Ավելի լավ է հստակ հարցնել (capabilities) կամ նայել մեդիա/սխեմային։

Արդյունքը

Ուղղակի համատեղելիությունը կարգապահությունն է պայմանավորվել հնարավորությունների և անվտանգ քայքայման մասին։ Կայուն միջուկը, capability negotiation, addiment ընդարձակումը և կանխատեսելի սխալները թույլ են տալիս նոր հաճախորդներին և տվյալները ընթանալ հին բաժնետերերի և սպառողների հետ 'առանց զանգվածային ֆորումների և գիշերային միգրացիաների։