JSON'dan Protobuf'a taşın. Buna değer mi?

23

XML veya JSON'a (WCF) hizmet verebilecek REST web servislerimiz vardır. Protobufları uygulama fikri ile oynuyorum. Niye ya?

Artıları

Sunucularda daha az yük.
Küçük mesaj boyutu - daha az trafik.
Şimdi geçmek daha sonradan daha kolaydır.

EKSİLERİ

Uygulanması gerekiyor
Hata ayıklama için iletileri gidermek / burnunu çekmek daha da zorlaşacak.
Sunucuda GZip'i etkinleştirebilirim ve JSON kadar trafik tüketecektir

Bu konuda öneri ve / veya deneyiminiz nedir?

web-services wcf serialization

— katit
kaynak

1

Wikipedia sayfasına baktım ve aslında her bir anahtar / değer çifti başına daha fazla karakter vardı, neden doz daha küçük mesajlara sahip?

— Ramzi Kahil

Serileştirme yüzünden. İkili veriler ikili olarak gelir (örneğin bayt dizileri). Ek olarak, bir mesajda özellik adlarını taşımaz. Mülkiyet sıralarına göre giderler. developers.google.com/protocol-buffers/docs/encoding#structure

— katit

10

Teknik olarak kendi sorunuzu cevapladınız, JSON'u sıkıştırdınız ve bununla bitirin. En önemlisi , bu faaliyete para ve zaman harcamak için gerçek bir iş durumundan asla bahsetmiyorsunuz .

39

Bunları uygulamanın işletme değeri maliyeti aşıyor mu?

Uygularsanız, yalnızca sunucunuzu değil, tüm istemcileri de değiştirmeniz gerekir (her iki formatı da destekleyebilir ve yalnızca gerektiği gibi istemcileri değiştirebilirsiniz). Bu doğrudan bir maliyet olan test ve zaman alacak. Ayrıca protokol arabelleklerini gerçekten anlamak için harcanan zamanı (özellikle de zorunlu veya isteğe bağlı alan yapma nedenlerini) ve protobuf derleyicisini derleme işleminize entegre etmek için harcanan zamanı hafife almayın.

Öyleyse değer bunu aşıyor mu? "Bant genişliği maliyetlerimiz gelirimizin% X'i ve bunu destekleyemeyiz" seçeneğiyle mi karşı karşıya kaldınız? Veya "JSON'u desteklemek için sunucu eklemek için 20.000 $ harcamamız gerekiyor" bile mi?

Acil bir iş gereksiniminiz olmadığı sürece, "profesyonelleriniz" gerçekten profesyonel değildir, sadece erken optimizasyon.

— parsifal
kaynak

23

protobuf eklemeden önce apis ve birisini korudum (çünkü "daha hızlıydı"). Daha hızlı olan tek şey RTT'dir, çünkü daha küçük taşıma yükü vardır ve gzipli JSON ile sabitlenebilir.

Bana tatsız olan kısım protobufu sürdüren göreceli çalışmadır (JSON ile karşılaştırıldığında). Java kullanıyorum, böylece JSON için Jackson nesne eşlemesini kullanıyoruz. Bir yanıt eklemek, bir POJO'ya alan eklemek anlamına gelir. Ancak protobuf için .proto dosyasını değiştirmem gerekiyor, ardından verileri protokol arabelleklerinin içine ve dışına ve POJO'lara taşıyan serileştirme ve seri hale getirme mantığını güncellemeliyim. Birisinin bir alan eklediği ve protokol tamponları için seri hale getirme veya seri kaldırma kodunu koymayı unuttuğu bir sürümün olması bir kereden fazla oldu.

Müşteriler protokol arabelleklerine karşı uygulandıklarına göre, bundan kaçmak neredeyse imkansız.

Bundan muhtemelen tahmin edebilirsiniz, benim tavsiyem yapma.

— Kevin
kaynak

5

Verileri POJO'ların içine / dışına taşımak için serileştirme kodu yazıyorsanız, yanlış yapıyorsunuzdur. Sadece doğrudan protobuf tarafından üretilen sınıfları kullanın.

— Marcelo Cantos

Bu durumda POJO'lara girip çıkıyordum, çünkü kod temeli hem JSON, XML hem de Protobuf isteklerini / yanıtlarını destekliyordu ve Jackson ve / veya JAXB ek açıklamalarını oluşturulan sınıflara ekleyemem ve istediğimi düşünüyorum. aynı model nesnelerini kod boyunca kullanmak için, yalnızca oluşturulan sınıfları kullanma seçeneklerine sahip olduğumu bilmiyorum. Sadece protobuf konuşan GRPC servisleri yazıyor olsaydım, bunun nasıl mümkün olacağını görebiliyorum.

— Kevin,