Avatar
0
hieuthai642 Beginner
hieuthai642 Beginner
Thiết kế API limit rate như thế nào
Mọi người cho em hỏi, trong những sản phẩm thực tế thì có dùng API limit rate không ạ?

Nếu có thì sẽ thiết kế giải pháp như thế nào, (ngoài việc dùng API Gateway build sẵn) nếu thiết kế service riêng cho chuyện này cần làm những công việc chính gì

Em có thấy 1 bài blog của Kong về thuật toán dùng trong rate limit https://konghq.com/blog/how-to-design-a-scalable-rate-limiting-algorithm/

Em hiểu là có thể thiết kế 1 service để limit rate (single entry point), service này sẽ áp dụng thuật toán nào đó để limit rate rồi route traffic tới các service khác trong hệ thống. như vậy có đúng không?

Khi nói đến limit rate là mình chỉ giới hạn ở HTTP, hay các giao thức khác ở tầng application cũng có thể áp dụng như AMQP, MQTT, hay rộng hơn là traffic từ tầng transport (TCP, UDP) ạ

  • Answer
question
Remain: 5
2 Answers
Avatar
monkey Beginner
monkey Beginner
  1. Từ khi đi làm tới giờ anh chưa bao giờ thấy dùng rate limit kiểu này, đa phần các dự án đều dùng round robin cho phần HTTP thôi em ạ, làm như vậy mới đảm bảo được tận dụng tối đa tài nguyên của các node, không thì một node thì sấp mặt, 1 node thì ngồi chơi thì hơi dở. Và nó còn liên quan đến HA. Giả sử 1 node code tèo thì cả hệ thống cũng không sao và tỉ lệ request bị ảnh hưởng cũng thấp. Còn nếu bỏ hết request vào 1 node, mà node đó bị hỏng thì node tiếp theo cho dù được sử dụng đến nhưng cũng không thể nào khôi phục được request đã mất.
  2. Có riêng trong bài toán liên quan đến socket game, hay một số bài toàn liên quan đến live streaming, thì vì bị giới hạn về số lượng port, và các logic đòi hỏi bắt buộc user phải tìm được phòng chơi và chơi chung phòng với nhau nên áp dụng phương pháp gần giống kiểu rate này, nghĩa là cho user vào hết 1 server, đến 1 số lượng nào đó giới hạn thì cho user vào server kế tiếp.
  3. Về cơ bản là HTTP hay AMQP, MQTT ... đều có thể áp dụng được kiểu rate limit này. Tuy nhiên vẫn là liên quan đến bài toán nghiệp vụ và hạ tầng mà em có quyết định dùng hay không nhé.
  • 1
  • Reply
Em cảm ơn anh, ý số 2 và 3 thì em rõ rồi ạ.

Nhưng ý số 1 thì em chưa hiểu lắm, phần mà anh đề cập tới hình như là giai đoạn trước em 1 bước. Em có đọc thấy round robin là 1 phương pháp distribute request tới các server khác nhau, còn ý em muốn hỏi là kiểu giống ý số 2,

vd aws ses & ec2 thì giới hạn số lượng api trong 1 giây https://docs.aws.amazon.com/ses/latest/dg/quotas.html

https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html

Giả sử e muốn dựng các dịch vụ tương tự thì cách tiếp cận rate limit như thế nào a nhỉ, mình xử lý luôn trong code hay tạo 1 service để reuse lại ở nhiều nơi. Trong ví dụ về socket game & dịch vụ livestream, anh có thể chia sẻ 1 tí về cách thực hiện được không ạ

Về phần hạ tầng thì e giả sử deploy service này bằng k8s trên cluster, nginx sẽ chạy round robin để distribute request tới các pod, như vậy chắc là đúng với ý 1 của anh về HA rồi nhỉ

 –  hieuthai642 1638842393000
Avatar
tvd12 Beginner
tvd12 Beginner
  1. Anh thấy aws có dịch vụ autoscale, vậy có thể nó cũng là dạng dịch vụ dựa vào rate limit, anh chỉ đoán vậy thôi em ạ, vì anh cũng không phải chuyên gia về aws
  2. Nếu em muốn tự dựng thì anh nghĩ là em phải tự viết lại server LB, em có thể fork nginx về và viết thêm code của em vào. Em sẽ tự quản lý các node, số lượng request đến và số lượng request còn tồn (chưa được xử lý) trên các node là bao nhiêu để sẽ tiến hành các bước tiếp theo.
  3. Ví dụ về socket game thì anh có 1 bài viết, em có thể tham khảo nhé.
  4. Về phần hạ tầng thì e giả sử deploy service này bằng k8s trên cluster ... Đúng rồi em ạ
  • 1
  • Reply
Em cảm ơn anh, bài viết hay quá anh ạ, với số CCU như thế thì công ty em đang làm không bao giờ đạt đến được mất

Em đang nghiên cứu thử hướng plugin cho nginx còn modify source code có vẻ hard core quá

 –  hieuthai642 1638950566000