Computer >> Máy Tính >  >> Lập trình >> Redis

Xếp hạng giới hạn các ứng dụng không có máy chủ của bạn

Một trong những điều tốt nhất về serverless là khả năng mở rộng quy mô ngay cả trong trường hợp lưu lượng truy cập tăng đột biến. Nhưng thật không may, việc mở rộng quy mô không miễn phí cả về tài chính và kỹ thuật. Đó là lý do tại sao các nhà phát triển cần kiểm soát khả năng mở rộng ứng dụng của họ. Dưới đây là những lý do chính khiến bạn cần cơ chế giới hạn tốc độ trong ứng dụng không máy chủ của mình:

1- Bảo vệ tài nguyên của bạn: Nếu bạn đang cung cấp một API công khai, lưu lượng truy cập tăng đột biến có thể làm giảm chất lượng của dịch vụ và có thể dẫn đến việc ngừng cung cấp dịch vụ cho tất cả người dùng của bạn. Bạn cần bảo vệ hệ thống của mình chống lại các lỗi xếp tầng như vậy cũng như các sự cố Ddos tự gây ra. Một lỗi trong ứng dụng của bạn có thể gây ra các vấn đề như vậy trong hệ thống của bạn. Quy trình nội bộ thử lại vô thời hạn một điểm cuối trong trường hợp bị lỗi có thể dễ dàng làm cạn kiệt tài nguyên của bạn.

2- Quản lý hạn ngạch người dùng: Bạn có thể muốn xác định hạn ngạch cho người dùng của mình để sử dụng hợp lý các dịch vụ của bạn. Ngoài ra, bạn có thể cần hạn ngạch nếu bạn cung cấp dịch vụ của mình ở các mức giá khác nhau.

3- Kiểm soát chi phí: Có rất nhiều ví dụ thực tế về cách một hệ thống không được kiểm soát có thể gây ra các hóa đơn lớn. Đây là một rủi ro khá lớn đối với các ứng dụng không có máy chủ nhờ tính chất có khả năng mở rộng cao. Giới hạn tỷ lệ sẽ giúp bạn kiểm soát các chi phí này.

Giải pháp

Có nhiều giải pháp giới hạn tỷ lệ thay thế ở các lớp khác nhau. Tôi sẽ liệt kê 3 cái chính kèm theo phân tích ưu / nhược điểm ngắn gọn.

1- Mức đồng thời của chức năng:

Các nhà cung cấp đám mây tạo nhiều vùng chứa để mở rộng quy mô thực thi chức năng không máy chủ của bạn. Bạn có thể đặt giới hạn cho số lượng tối đa các vùng chứa / phiên bản đồng thời. Mặc dù điều này có thể giúp bạn hạn chế sự đồng thời, nhưng nó không kiểm soát số lần hàm của bạn sẽ được gọi trong một giây.

Dưới đây là cách bạn có thể giới hạn đồng thời cho các Chức năng AWS Lambda và Google Cloud.

Ưu điểm:

  • Không tốn phí
  • Dễ định cấu hình

Nhược điểm:

  • Không phải là một giải pháp hoàn chỉnh. Chỉ kiểm soát đồng thời. Số lần thực thi mỗi giây không bị giới hạn.

2- Giới hạn tốc độ trên API Gateway

Nếu bạn đang truy cập các chức năng của mình thông qua API Gateway, bạn có thể áp dụng chính sách giới hạn tỷ giá của mình cho API Gateway. Cả AWS và GCP đều có hướng dẫn về cách định cấu hình các giải pháp của họ.

Ưu điểm:

  • Không tốn phí
  • Dễ định cấu hình

Nhược điểm:

  • Chỉ áp dụng nếu bạn đang sử dụng API Gateway.
  • Nó không hỗ trợ các trường hợp phức tạp hơn như hạn ngạch cho mỗi người dùng hoặc mỗi IP.

3 - Giới hạn tỷ lệ với Redis

Đây là giải pháp hoàn chỉnh và mạnh mẽ nhất. Có nhiều thư viện giới hạn tỷ lệ dựa trên Redis có sẵn. Trong bài đăng trên blog của Jeremy Daly, anh ấy từ chối Elasticache như một giải pháp khả thi, nói rằng * this adds a “non-serverless” component and another thing to manage *. Ở đây Upstash trở thành một giải pháp thay thế rất tốt với mô hình không máy chủ và định giá theo yêu cầu.

Ưu điểm:

  • Mạnh mẽ, bạn có thể triển khai logic tùy chỉnh phù hợp với mô hình người dùng của mình.
  • Giải pháp có thể mở rộng. Xem cách Github sử dụng Redis để giới hạn tốc độ
  • Hệ sinh thái phong phú, nhiều thư viện mã nguồn mở:redis_rate, redis-cell, node-ratelimiter

Nhược điểm:

  • Chi phí sử dụng Redis.

Mã:Giới hạn tỷ lệ với Redis

Nhờ các thư viện giới hạn tỷ lệ, rất dễ dàng áp dụng giới hạn tỷ lệ cho mã ứng dụng của bạn. Dưới đây là mã ví dụ giới hạn việc thực thi hàm AWS Lambda trên mỗi IP mỗi giây:

const RateLimiter = require("async-ratelimiter");
const Redis = require("ioredis");
const { getClientIp } = require("request-ip");

const rateLimiter = new RateLimiter({
  db: new Redis("YOUR_REDIS_URL"),
  max: 1,
  duration: 5_000,
});

module.exports.hello = async (event) => {
  const clientIp = getClientIp(event) || "NA";
  const limit = await rateLimiter.get({ id: clientIp });
  if (!limit.remaining) {
    return {
      statusCode: 429,
      body: JSON.stringify({
        message: "Sorry, you are rate limited. Wait for 5 seconds",
      }),
    };
  }

  return {
    statusCode: 200,
    body: JSON.stringify({
      message: "hello!",
    }),
  };
};

Truy cập hướng dẫn để biết ví dụ đầy đủ.

Danh sách Đọc

https://cloud.google.com/architecture/rate-liosystem-strategies-techniques

https://www.jeremydaly.com/throttling-third-party-api-calls-with-aws-lambda/

https://medium.com/google-cloud/rate-limit-your-api-usage-with-cloud-endpoints-quotas-1270da55d2bf

https://github.blog/2021-04-05-how-we-scaled-github-api-sharded-replicated-rate-limiter-redis/

https://redis.io/commands/incr#pattern-rate-limiter

https://stripe.com/blog/rate-limiters