Birden Fazla Source'den Erişilen API'lerde Rate Limiting'i Yönetmek

Yardım
,
1

Selamlar,
Bazen farklı servislerden aynı servise ait api’ye erişme ihtiyacı oluyor veya aynı app içinden concurrent olarak erişim ihtiyacı oluyor. Bu durumda API’de ki rate limiting’i yönetmek için nasıl bir yöntem izliyorsunuz? Rate Limiting’de retry stratejisi çok fazla app’den gidildiği zaman çok sağlıklı olmayabiliyor. Bu konuda ki tecrübelerinizi merak ettim.

Benim aklıma aslında bir proxy server atmak geliyor. Proxy server üzerinde limitleri tanımlayıp ona gelen istekleri yönlendirerek yada bekleterek işlemleri yapmayı düşündüm(Evet bir dar boğaz oluşacak farkındayım) fakat sizlerin tecrübelerini merak ediyorum.

2

Ben rack-attack ile throttling yapıyorum. Retry konusunda da şu link işini görebilir.

Benim çok işimi görüyor ama senin use case biraz farklı gibi. Bu görevi nginx’e ya da farklı bir reverse-proxy’ye vermek daha mantıklı olabilir.

3

Benim sorunum bende ki ratelimiting için değildi anlatamadım sanırım orasını benim gittiğim servislerde ki limiting. Benim tarafımdan concurrent(uygulamanın içinde de async var farklı servislerden de istekler var) olarak bir servise istekler gidiyor. Bu durumda ki karşı serviste ki limiting’i manage etmek için aslında demek istedim.

4

Bana göre concurrent bir uygulamada istek yaptığın bir servisin rate limiti yönetmek inanılmaz zor olacaktır. Shopify bu konuda leaky bucket algorithm denilen bir algoritma kullanıyor.

.NET ile entegrasyon yazarken çok zorlanacağımızı öngörüp single thread bir uygulama yazdım ve her istek arasında belirtilen süre kadar sleep atarak çözdüm.

Naçizane tavsiyem senin de benzer bir çözüm uygulaman olacaktır.

2 Beğeni
5

Ben de 3. parti bir API’yi concurrent olarak tüketme fikrinin baya uğraştıracağını düşünüyorum.

Eğer yazdığını eksik anlamadıysam aklıma ilk gelen yöntem:

  1. Concurrent kısmının sadece tek bir queue’ya atma kısmı olması.
  2. Rate limitin sorumluluğunu da queue’dan işi alıp, tüketeceğin API’ye istek atacak background job’una vermek.
1 Beğeni
6

Abi queue’ya atmak demek yanıt beklememek demek olacak kodun akışı sırasında bu isteğin yapılması ve sonucunun işleme etki etmesi gerekiyor o yüzden queue pek mümkün değil :confused:

7

Böyle bir zorunluluk olmaması gerekir. Örnek vermek gerekirse:

  1. Queue’ya at.
  2. Ya poll’la ya da callback.
  3. Sonuçlandığında UI’ı güncelle.

Paraşüt’te de banka entegrasyonlarını bu şekilde uygulamıştık. Sonuçlanana kadar da kullanıcı spinner görüyordu.

En iyi çözüm diye iddia etmiyorum ama sorunu çözüyordu. :slight_smile:

8

İşte eğer UI’lık bir şey olsa sorun yok abi ama hesaplamalarda gereken bir şey olduğu için ne yazık ki callback mantığı oturmuyor benim senaryoya :confused: O result’un sonucunda gelen şeyi hesaplamaya katılması ve diğerlerine devam edilmesi gerekliliği var bende yoksa UI değerleri olsa ne rahat olur :stuck_out_tongue:

1 Beğeni