İleri uyumluluk
İleri uyumluluk nedir
İleri uyumluluk, bir sistemin orijinal olarak tasarlandığından daha yeni istemciler veya verilerle doğru şekilde çalışabilmesidir. Daha basit: Yeni bir istemci geldiğinde eski sunucu bozulmaz; Eski tüketici yeni bir mesajla karşılaştığında düşmez.
İleri, sorumluluk açısından geriye dönük uyumluluktan (yeni sistem eski müşterileri desteklediğinde) farklıdır: Protokolleri ve müşterileri, tüm ekosistemin toplam yükseltmesi olmadan gelecekteki uzantıları "hayatta kalacak" şekilde tasarlarız.
Temel ilkeler
1. Hoşgörülü okuyucu ve hoşgörülü yazar
Okuyucu bilinmeyen alanları/başlıkları yoksayar ve doğru geri dönüşle yeni enum değerlerine izin verir.
Writer, sunucunun açıkça desteklenen (yetenekler) olarak bildirmediği hiçbir şeyi göndermez.
2. Yetenek müzakeresi
El sıkışma aşamasında açık yetenek değişimi (özellikler/sürümler/medya türleri). İstemci, davranışını sunucu yanıtına uyarlar.
3. Varsayılan bozulma
Yeni özellikler isteğe bağlı olarak kabul edilir: Sunucu/tüketici bunları desteklemiyorsa, komut dosyası yine de yararlı bir minimum (MGC) ile bitecektir.
4. Kararlı Çekirdek (MGC)
Minimum garanti sözleşmesi değişmez; Yenilikler uzantılar olarak yaşar.
5. Protokolün bir parçası olarak hata sözleşmeleri
Öngörülebilir kodlar/nedenler ("özellik desteklenmiyor", "ortam türü bilinmiyor") istemcinin otomatik olarak desteklenen bir moda geri dönmesini sağlar.
6. Sürprizi olmayan versiyonlar
Ayrılan ana çizgiler; Küçük uzantılar bir sunucu/tüketici yükseltmesi gerektirmez.
Önemli olduğu yerde
Uzun ömürlü entegrasyonlara sahip genel API'ler (ortaklar, mobil uygulamalardaki SDK'lar).
Birçok bağımsız tüketiciyle etkinlik platformları.
Arka uçtan daha yavaş güncellenen mobil istemciler.
Cihaz filosunun bir kısmının nadiren yanıp söndüğü Edge/IoT.
Stile Göre Uygulama Desenleri
REST/HTTP
Pazarlık:- 'Accept'/parametreli ortam türleri (' application/vnd. örnek. sipariş + json; v = 1; profil = risk ').
- 'Tercih: include =... 'İsteğe bağlı bloklar için.
- Başlık 'X-Yetenekleri: risk_score,item_details_v2'.
- Temel bir formatta, uzantılarda bir istek gönderir - yalnızca sunucunun doğrulanmış yeteneği varsa (OPTIONS/desc/lead endpoint aracılığıyla).
- '415/406/501' otomatik olarak desteklenen bir formata/yönteme geri döndürüldüğünde.
- Sunucu yanıtı: bilinmeyen parametreler - görmezden gelin; Ekstra alanlara izin verilir; kararlı hata biçimi ('type/code/detail/trace _ id').
gRPC/Protobuf
Kararlı hizmetler: yeni yöntemler/alanlar - katkı maddesi; Eski sunucu bilinmeyen istek alanlarını sessizce yoksayar.
Özellik bulma: 'GetCapabilities ()' yöntemi, özelliklerin/sınırların listesini döndürür. İstemci, sunucu bildirmedikçe v2 yöntemini çağırmaz.
Akış: minimum mesaj kümesinin sırasını düzeltin; Eski istemcinin yoksaydığı uzantılar/türlerle yeni "çerçeveleri" işaretleyin.
GraphQL
İleri dostu: Sunucuda yeni alanlar/türler görünür - eski istemciler bunları istemez.
Tahminler yasaktır: Müşteri şemayı (iç gözlem/kodojen) tutmalı ve bilinmeyen direktifler/değişkenler göndermemelidir.
Bozulma: Sunucu özel/özellik yönergesini bilmiyorsa, istemci onsuz bir istek oluşturur.
Olay odaklı (Kafka/NATS/Pulsar, Avro/JSON/Proto)
Planın kayıt defterindeki FORWARD uyumluluğu: eski tüketiciler yeni program tarafından yazılan mesajları okuyabilir.
Varsayılanlarla katkı alanları: yeni üreticiler eski tüketicileri kırmaz.
Çekirdek vs Zenginleştirilmiş: Çekirdek aynı kalır, yeni bilgiler '.enriched' veya isteğe bağlı alanlar olarak yayınlanır.
Tasarım uygulamaları
1. Minimum Talep Sözleşmesi (MGC)
Operasyon, tüm sunucuların uzun yıllar boyunca destekleyeceği'dar boyuna "sahip olmalıdır.
2. Sözleşme seviyesinde özellik bayrakları
Özellikleri adlandırılmış özellikler olarak tanımlayın: 'risk _ score', 'pricing _ v2', 'strong _ idempotency'. Müşteri bunları açıkça ifade eder.
3. "Desteklenmiyor" için açık hata kodları
HTTP: '501 Uygulanmadı', '415 Desteklenmeyen Medya Türü', детальные 'problem + json'.
gRPC: 'UNIMPLEMENTED'/' FAILED _ PRECONDITION'.
Olaylar: DLQ'da 'reason = unsupported _ feature'ile rota.
4. Sipariş/tam listelere güvenmeyin
İstemci yeni enum değerlerine, yeni alanlara ve "ek" özelliklere hazır olmalıdır.
5. Kararlı tanımlayıcılar ve formatlar
Satır içindeki ID/bölümleme tuşlarının biçimini değiştirmeyin - bu okuyucuların yanında öne doğru kırılır.
6. "Makine tarafından okunabilir" belgeler
Ana bilgisayar tanımlayıcıları: OpenAPI/AsyncAPI/Proto tanımlayıcıları/GraphQL SDL. Müşteriler bu özellik için desteği doğrulayabilir.
İleri uyumluluk testi
FORWARD/FULL modunda Schema-diff: Yeni şema eski tüketici/sunucuyu doğrular.
İstemci Sözleşme Testleri: Yeni bir istemci, özellikleri etkinleştirilmiş/devre dışı bırakılmış eski bir sunucuya karşı yürütülür.
Altın istekler: bir dizi'yeni "istek'eski" sunucu üzerinden çalıştırılır; Kritik hatalar olmadan beklenen bozulma.
Kaos/gecikme: zaman aşımı/yeniden ödeme kontrolü - yeni istemci eski sunucunun en kötü SLA'larından sağ çıkmalıdır.
Kanarya: Yeni istemcilerden bazıları önceki sunucu sürümüyle çalışır - hataların/bozulmanın telemetrisini toplarız.
Gözlemlenebilirlik ve operasyonel metrikler
Desteklenmeyen özelliklere sahip isteklerin/mesajların yüzdesi ve otomatik geri dönüşleri.
İstemci sürümlerine göre dağıtım (User-Agent/metadata/claims).
DLQ'daki 'UNIMPLEMENTED/501/415' hataları ve rotaları 'unsupported _ feature'ile.
Bozulma süresi: MGC vs "genişletilmiş" yanıt için p95/p99.
Şema kayıt defterindeki uyumluluk modları
FORWARD: Yeni giriş eski okuyucu ile uyumludur (varsayılanlar gereklidir, opsiyonellik).
TAM: İLERI и, GERI и; Kamu sözleşmeleri için uygun.
Öneri: olaylar için - Üretici için GERİ ve tüketici için İLERI (toleranslı bir okuyucu aracılığıyla), harici API'ler için - TAM.
Örnekler
REST (yetenekler + bozulma)
1. İstemci 'GET/meta/capabilities' yapar - '{"risk _ score": false, "price_v2": true}'.
2. 'POST/orders' üzerinde temel alanları gönderir; 'risk _ score' istenmez, çünkü sunucu bunu yapamaz.
3. Yanlışlıkla 'Prefer: include = risk _ score' gönderilirse, sunucu 'risk _ score' alanı (veya 'Preference-Applied: none') olmadan 200 ile yanıt verir - istemci çökmez.
gRPC (keşif)
'GetCapabilities ()' döndürülen yöntem listesi/özelliği. İstemci, mevcut değilse 'CaptureV2'yi çağırmaz; bunun yerine' Capture 'kullanır ve girdiyi desteklenen bir görünüme yerel olarak dönüştürür.
Olaylar (kayıt defterinde FORWARD)
Üretici 'risk _ score' alanını ekledi (varsayılan olarak geçersiz). Eski tüketici onu görmezden gelir; Mantığı sadece kararlı çekirdek alanları kullanır.
Antipatterns
Sabit istemci: Yanıtı beyaz liste alanlarına göre filtreler ve bilinmeyen bir özelliğe düşer.
Örtük özellikler: Müşteri, yetenekleri kontrol etmeden yeni bir parametre göndermeye başlar.
Satır içinde kimlik/anahtar formatlarının değiştirilmesi - eski sunucular/tüketiciler artık yeni istekleri/mesajları anlamıyor.
Tam enum listesi hakkında kablolu varsayımlar (varsayılan olmadan geçiş).
Akış kontrolü olarak günlüğe kaydetme: sözleşme kodları yerine hata dizelerini ayrıştırma.
Uygulama kontrol listesi
- MGC tanımlı; Yeni özellikler isteğe bağlı olarak işaretlenmiştir.
- Yetenek anlaşması (endpoint/metadata/handshake) tanımlanır ve uygulanır.
- İstemciler bilinmeyen alanları görmezden gelir ve yeni enumu (geri dönüş) doğru bir şekilde ele alır.
- Hata sözleşmeleri tahmin edilebilir şekilde "desteklenmiyor" yakalar (HTTP/gRPC/Event).
- Şema kaydı, ilgili eserler için FORWARD/FULL olarak ayarlanmıştır.
- Autotests: şema-diff (FORWARD), istemci ve eski sunucu sözleşme testleri, kanarya.
- Metrikler: istemci sürümü, özellik hatası, bozulma oranı, p95 MGC.
- Dokümantasyon/SDK'lar özelliklerin bir listesini ve bozulma örneklerini yayınlar.
SSS
İleri, pratikte geri olmaktan nasıl farklıdır?
Geriye doğru: Yeni sunucu eski istemcileri kırmaz. İleri: Eski sunucu yeni istemcilerden (veya eski tüketiciden yeni iletilerden) kopmaz. İdeal olarak, tam olarak ulaşırsınız.
Her zaman yeteneklere girmek zorunda mıyım?
Eşzamanlı salımlar olmadan aktif bir evrim bekliyorsanız, evet. Düzinelerce ana hattı tutmaktan daha ucuzdur.
Peki ya güvenlik?
Yeni özellikler ayrı kapsamlar/talepler gerektirmelidir. Sunucu bunları desteklemiyorsa, istemci güvenliği azaltmamalı, ancak özelliği terk etmelidir.
Sunucu sürümüne göre desteği "tahmin etmek" mümkün mü?
İstenmeyen bir şey. Açıkça sormak (yetenekler) veya medya türüne/şemasına bakmak daha iyidir.
Toplam
İleri birlikte çalışabilirlik, fırsatları müzakere etme ve güvenli bir şekilde düşürme disiplinidir. Kararlı bir çekirdek, yetenek müzakeresi, eklemeli uzantılar ve öngörülebilir hatalar, yeni istemcilerin ve verilerin eski sunucular ve tüketicilerle toplu sürümler ve gece geçişleri olmadan birlikte çalışmasına izin verir.