Çok sayıda küçük istek ve çok sayıda büyük istek (API Tasarımı)

Şu anda bir kuruluşla birlikte bir proje üzerinde çalışıyorum:

• İstemci - Ana sunucudan veri REST api ile alır.
• Sunucu - Üçüncü taraf API'ler aracılığıyla diğer çeşitli sunuculardan veri ister
• Üçüncü taraf API'leri - Sunucuya veri sağlayan denetimim dışındaki hizmetler (Reddit, Hackernews, Quora, vb.)

Argüman uğruna, müşterinin önce üçüncü taraf API'lerinin her birinin öğelerinden oluşan bir listeye ihtiyacı olduğunu varsayalım. Bu listeden, müşterinin, öğenin içeriğinin tamamını ve ayrıca öğeye verilen yanıtları (örneğin yorumları) görmesi gereken bir nokta seçilecektir. Üç seçenek arasında karar vermeye çalışıyorum:

Alakart

Bu yaklaşımda sunucumda 3 ayrı uç nokta olacaktı: biri öğelerin listesini almak, biri öğenin ana içeriğini almak, diğeri de öğenin yanıtlarını almak için.

• Artıları: Asla ihtiyacım olandan daha fazla istek yapmam, talepler küçük olmalı, bu yüzden genellikle daha hızlı olmalılar.
• Eksileri: Çok fazla istek yapmak zorundayım. Listeden bir öğe seçtikten sonra, kullanıcının ana içeriği görmeden önce beklemesi ve sonra yanıtları görmek için daha uzun süre beklemesi gerekebilir

Sunucu tarafı önbellek

Bu istekte, tüm kaynaklar için tüm verileri "almak" için sunucuma tek bir arama yapardım. Veriler daha sonra sunucuda önbelleğe alınır. İstemci daha sonra olduğu gibi REST bitiş noktalarına sahip olacaktı, ancak çağrılar arasında fazla beklememek dışında sunucum zaten veriye sahipti ve istemciye beslemesi gerekiyordu.

• Artıları: Müşteri tarafında uygulanması kolaydır, ancak gecikme sorunları olmadan
• Eksileri: Biraz daha fazla sunucu tarafında yer aldı ve ilk arama gerçekten çok uzun sürebilir.

İstemci tarafı önbellek

Bu senaryo öncekine benzer, ancak istemci sunucuya yalnızca bir istek yapar: bana tüm verileri verin. Buradan verileri kaydetmek ve uygun şekilde kullanmak müşterinin sorumluluğundadır.

• Artıları: Kolay sunucu uygulaması, ilk aramadan sonra çok hızlı
• Eksileri: İlk çağrı çok yavaş olacak, daha karmaşık müşteri tarafında uygulama

Hangisinin en iyi yaklaşım olduğundan emin değilim, ya da belki bariz çözümü özlüyorum Herhangi bir tavsiye çok takdir edilecektir!

Akılda tutulması gereken bir şey, müşterileriniz ve sunucunuz arasında beklenen ağ gecikmesi (ping süresi) 'dir. Aksi halde iyi bant genişliğine sahip yüksek gecikmeli bir durumda, birçok küçük istek, büyük olandan önemli ölçüde daha kötü performans gösterir .

Kısa bir süre önce, ekiplerden birinin Hindistan'da olduğu (geri kalan ABD'de) bulunan çoklu ekip veritabanı destekli bir web uygulaması projesi üzerinde işbirliği yapıyorum. ABD ofisimizde barındırılan ve geliştiricilerin yerel web sunucusu örneklerimizi birbirine bağladığı tek bir veritabanı örneğine sahibiz. Masam belki elli fit ve iki LAN veri tabanı örneğinden uzak duruyor ve performans iyi.

Hindistan'daki geliştiricilerin işlerine ilk başladığımızda, uygulamayı başlatırken ve sayfalar arasında gezinirken çok büyük bekleme süreleri yaşıyorlardı. Burada on dakikalık bekleme süresinden bahsediyoruz. Bunun sebebi, masalardan dev veritabanı sunucumuza 200ms ping süresinin veri tabanına çok sayıda kısa sorgula çarpılmasıydı. Yerel 0.5ms ping o kadar önemsizdi ki, web sunucusu ile veritabanı sunucusu arasındaki sohbet hiç önemli değildi. Web sunucusu ile veritabanı sunucusu arasında ilk kez coğrafi ayrılığımız oldu.

Bizim durumumuzdaki çözüm, veritabanı sunucusunu klonlamak ve Hindistan'da kopyasını almaktı, ancak buradaki nokta, eğer istemciniz ve sunucunuz birbirinden uzaktaysa, ağ gecikmesinin, tüm dünyadaki iletişim sayısıyla çarpılacağını aklınızda bulundurmaktır. tel. Bağlantı kurulduktan sonra bant genişliği tipik olarak kaygılardan çok daha azdır.

Bu üç seçenek birbirini dışlayan değil, hem istemci tarafı hem de sunucu tarafı önbellek kombinasyonunu kullanabilirsiniz. Bununla birlikte, yorumlar gibi bazı veriler önbellekte çok uzun süre tutulursa bayat olabilir. Durumun böyle olup olmadığını kontrol edemediğinizi göz önünde bulundurarak, muhtemelen saklamaktan kaçınmalısınız. Öte yandan, içerik genellikle büyük ölçüde değişmez, dolayısıyla gecikmeyi azaltmak için sunucu tarafında önbelleğe almanın ve ardından istemci tarafında bir kısmını önceden getirmenin bir zararı olmaz.

Verdiğiniz bilgilere dayanarak, seçenek 1, çünkü

• Tek bir müşteri isteğinde, elmaları ve portakalları karıştırırsınız ve meyve sepeti çok büyük olabilir.

• önbellekleme, performans kazandığınız ancak tutarlılığı kaybettiğinizden (eski veriler) kaybedeceğiniz bir tradeoff . Tanımlanmış performans sorunlarınız yoksa, senkronizasyon sorunları genellikle riske girmez.

Her zaman daha iyi performans gösteren ve ölçeklenebilir olmak için birkaç büyük istek buldum. Ancak, tüm yaklaşımlarda travmalar var, bu nedenle sunucunun ve müşterinin ihtiyaçlarına bağlı. Müşterinin, almak için bir veri dizisi veya veri dizisini belirtmesini sağlamak için başka bir seçenek kullanmak isteyebilirsiniz - tüm verilerin değil, tüm zamanların mevcut bant genişliğine uyması için ayarlanan bir dizi.

Ben seçenek neredeyse (indirim) 3 olur. 1 ile 2 arasında seçim yapmak iki şeye bağlıdır:

• (A) tek, toplam getirme sonucunun ne kadar büyük olduğu
• (B) sonucun detayının ne kadarının müşteri / kullanıcının tipik olarak o oturumda kullanacağı.

A ve B'nin aşırı olup olmadığına karar vermek kolaydır:

• A büyük ve B küçükse, kesinlikle seçenek 1'e (A la Carte) gidin.
• A küçük ve B büyükse, 2 (Sunucu tarafı önbellek) veya 3 bile (Müşteri tarafı önbellek) gidin.

Diğer A / B (büyük / küçük) varyasyonları için, takdir yetkisi uygulamanız gerekecektir. Farklı istemcilerden gelen farklı kullanım durumlarını karşılamak için genellikle hem kaba hem de ince uç noktalar sağlar.

Her zaman olduğu gibi programlamada, bağlıdır.

Öyleyse asıl soru şudur: A / B / C veya üçünün bir kombinasyonu için karar verirken nelere dikkat etmelisiniz?

Gerçek ayırt edici faktörlerin, tükettiğiniz 3. taraf API'lerinin uygulama ayrıntıları olduğunu söyleyebilirim. Örnek olarak, göz önünde bulundurmanız gerekenler: Hızlı mı yoksa yavaş mı? Veri sık ve beklenmedik şekilde değişiyor mu? Onlar "konuşkan" mı yoksa Dinlenme mi?

Hızlı, kolay aranan servisler durumunda, veriler o kadar sık ​​değişiyorsa, sunucu tarafı ön belleğiniz eski önbellek sorunları yaratacak, elbette, seçenek 1: daha fazla istek, önbellek yok, sadece gerektiğinde.

Harici verileriniz tahmin edilebilir bir şekilde değişecekse veya kullanımla sınırlıysanız veya sunucunuzdaki verileri önbelleğe alma konusunda daha iyi bir kullanıcı deneyimi elde ederseniz, 2 ile gidin. Ancak önbelleğin ücretsiz olmadığını unutmayın: hata ayıklama açısından maliyetleri vardır ve bazen kullanıcılar güncellemeleri görmediklerinden şikayet eder.

Seçenek 3, yalnızca verilerin çok fazla olmadığını düşünürdüm, ancak bu durumda seçenekler 1 veya 2 bile işe yarayabilir ve sunucuda daha fazla mantık tutuyorsunuz, bu yüzden 1 veya 2'ye sadık kalacağım.

Sadece benim 2c.