استراتژی ها و تکنیک های محدود کننده نرخ

این سند توضیح می دهد که چرا از محدود کردن نرخ استفاده می شود ، استراتژی ها و تکنیک های محدود کردن نرخ را توصیف می کند و توضیح می دهد که محدودیت نرخ برای محصولات Google Cloud در کجا مرتبط است. بخش اعظم این اطلاعات در مورد چندین لایه در پشته های فناوری اعمال می شود ، اما این سند بر محدود کردن نرخ در سطح برنامه متمرکز است.

محدود کردن نرخ به جلوگیری از فراوانی عمل بیش از برخی از محدودیت ها اشاره دارد. در سیستم های در مقیاس بزرگ ، از محدودیت نرخ معمولاً برای محافظت از خدمات و منابع اساسی استفاده می شود.

چرا از محدودیت نرخ استفاده می شود

محدودیت نرخ به طور کلی به عنوان یک اقدام دفاعی برای خدمات ایجاد می شود. خدمات مشترک برای حفظ در دسترس بودن خدمات باید خود را در برابر استفاده بیش از حد - چه در نظر گرفته شده یا ناخواسته - محافظت کنند. حتی سیستم های بسیار مقیاس پذیر باید در برخی از سطح محدودیت هایی در مصرف داشته باشند. برای عملکرد خوب سیستم ، مشتریان نیز باید با محدودیت نرخ در ذهن طراحی شوند تا احتمال خرابی آبشار را کاهش دهد. محدود کردن نرخ در هر دو طرف مشتری و سمت سرور برای به حداکثر رساندن توان و به حداقل رساندن تأخیر پایان به پایان در سیستم های بزرگ توزیع شده بسیار مهم است.

جلوگیری از گرسنگی منابع

شایع ترین دلیل برای محدود کردن نرخ ، بهبود در دسترس بودن خدمات مبتنی بر API با جلوگیری از گرسنگی منابع است. بسیاری از حوادث انکار سرویس مبتنی بر بار در سیستم های بزرگ غیر عمدی هستند-ناشی از خطاها در نرم افزار یا تنظیمات در برخی دیگر از سیستم ها-حملات مخرب نه (مانند انکار توزیع شده مبتنی بر شبکه). گرسنگی منابع که ناشی از حمله مخرب نیست ، گاهی اوقات به عنوان انکار دوستانه از خدمات (DOS) نامیده می شود.

به طور کلی ، یک سرویس محدود کردن نرخ در یک مرحله قبل از منبع محدود ، با برخی از حاشیه ایمنی هشدار دهنده پیشرفته اعمال می شود. حاشیه مورد نیاز است زیرا می تواند تاخیر در بارها وجود داشته باشد ، و محافظت از محدود کردن نرخ قبل از وقوع مشروطیت برای یک منبع ، باید وجود داشته باشد. به عنوان مثال ، یک API آرام ممکن است برای محافظت از یک پایگاه داده زیرین ، محدودیت نرخ را اعمال کند. بدون محدود کردن نرخ ، یک سرویس API مقیاس پذیر می تواند تعداد زیادی از تماس ها را به طور همزمان به پایگاه داده انجام دهد ، و این پایگاه داده ممکن است نتواند سیگنال های محدود کننده نرخ را ارسال کند.

مدیریت سیاست ها و سهمیه ها

هنگامی که ظرفیت یک سرویس بین بسیاری از کاربران یا مصرف کنندگان به اشتراک گذاشته می شود، می تواند برای استفاده منصفانه و معقول، بدون تأثیر بر سایر کاربران، محدودیت نرخ را برای هر کاربر اعمال کند. این محدودیت ها ممکن است در دوره های زمانی طولانی تری اعمال شوند، یا ممکن است برای منابعی اعمال شوند که با نرخ اندازه گیری نمی شوند، بلکه بر اساس کمیت تخصیص یافته اندازه گیری می شوند. این محدودیت های نرخ و تخصیص در مجموع به عنوان سهمیه نامیده می شوند. سهمیه ها همچنین می توانند برای بسته های درآمدزایی API یا محدودیت های ردیف رایگان اعمال شوند. برای جزئیات، به بخش سهمیه و سقف این سند مراجعه کنید.

درک نحوه اشتراک این سهمیه ها توسط برنامه ها و پروژه های سازمان شما بسیار مهم است. برای مثال، رهاسازی قناری سرکش در یک پروژه تولیدی می تواند سهمیه منابعی را که توسط زیرساخت های تولیدی استفاده می شود مصرف کند.

کنترل جریان

در سیستم های پیوندی پیچیده ای که حجم زیادی از داده ها و پیام ها را پردازش می کنند، می توانید از محدود کردن نرخ برای کنترل این جریان ها استفاده کنید - خواه ادغام جریان های زیادی در یک سرویس واحد یا توزیع یک جریان کاری واحد بین بسیاری از کارگران.

به عنوان مثال، می توانید با محدود کردن جریان به هر کارگر، کار را به طور یکنواخت تر بین کارگران توزیع کنید، و از تجمع یک کارگر در صفی از اقلام پردازش نشده در حالی که سایر کارگران بیکار هستند جلوگیری کنید. کنترل جریان با اطمینان از اینکه هر گره در یک سیستم فرصت برابری برای انجام کار دارد، داده های از پیش واکشی شده آماده برای پردازش محلی را متعادل می کند. برای اطلاعات بیشتر به بخش Pub/Sub: Flow Control مراجعه کنید.

جلوگیری از هزینه های اضافی

می توانید از محدودیت نرخ برای کنترل هزینه ها استفاده کنید—مثلاً، اگر یک منبع زیربنایی قادر به مقیاس بندی خودکار برای پاسخگویی به تقاضا باشد، اما بودجه برای استفاده از آن منبع محدود است. یک سازمان ممکن است از محدودیت نرخ استفاده کند تا از کنترل خارج شدن آزمایش ها و جمع آوری صورت حساب های بزرگ جلوگیری کند. این نگرانی تا حدی به این دلیل است که چرا بسیاری از سهمیه های Google Cloud با مقادیر اولیه تنظیم می شوند که در صورت درخواست می توان آن را افزایش داد. سایر محدودیت های نرخ با انگیزه هزینه ممکن است توسط سازمان هایی اعمال شود که راه حل های SaaS (نرم افزار به عنوان سرویس) با هزینه ثابت ارائه می دهند، که نیاز به مدل سازی هزینه، قیمت و حاشیه سود به ازای هر مشتری دارند.

استراتژی ها

در زنجیره ای یا مش از خدمات ، بسیاری از گره های سیستم هر دو مشتری و سرور هستند. هر قسمت از سیستم ممکن است به هیچ وجه استراتژی محدود کننده نرخ را اعمال کند ، یا ممکن است یک یا چند استراتژی را به روش های مختلف ترکیب کند ، بنابراین برای اطمینان از اینکه همه چیز بهینه کار می کند ، به نمای کل سیستم نیاز است. حتی در مواردی که محدودیت نرخ به طور کامل در سمت سرور اجرا می شود ، مشتری باید مهندسی شود تا به طور مناسب واکنش نشان دهد.

برای بیشتر شرایط ، اگر ابزار یا زیرساخت هایی که در حال اجرای استراتژی محدود کننده نرخ شما هستند ، خود ناکام یا غیرقابل دسترسی است ، خدمات شما باید باز شود و سعی کنید تمام درخواست ها را ارائه دهید. مشتریان به طور معمول فراتر از سهمیه کار نمی کنند ، و عدم موفقیت در سیستم های بزرگ نسبت به عدم بسته شدن ، کمتر از سیستم در مقیاس بزرگ مختل کننده است. عدم بسته شدن منجر به قطع کامل ، در مقابل عدم موفقیت ، که منجر به یک وضعیت تخریب شده می شود. تصمیمات مربوط به عدم موفقیت در باز یا عدم بسته شدن بیشتر در سمت سرور مرتبط است ، اما آگاهی از تکنیک های آزمایش مجدد مشتری در یک درخواست ناموفق ممکن است بر تصمیمات شما در مورد رفتار سرور تأثیر بگذارد.

محدود کردن نرخ

مهم است که گزینه انجام محدود کردن بدون نرخ را به عنوان کف در طراحی خود در نظر بگیرید-یعنی به عنوان یک وضعیت بدترین حالت که سیستم شما باید بتواند در آن جای بگیرد. در صورت عدم موفقیت بخشی از استراتژی محدود کننده نرخ ، سیستم خود را با استفاده از خطای قوی بسازید و درک کنید که کاربران خدمات شما در آن شرایط چه چیزی را دریافت می کنند. اطمینان حاصل کنید که کدهای خطای مفیدی را ارائه می دهید و در کدهای خطا هیچ داده حساس را نشت نمی کنید. استفاده از زمان های زمانی ، مهلت ها و الگوهای قطع کننده مدار به شما کمک می کند تا در صورت عدم محدودیت نرخ ، خدمات شما قوی تر باشد.

عبور کردن

اگر خدمات شما برای انجام درخواست ها با سایر خدمات تماس می گیرد ، می توانید نحوه عبور از هر سیگنال های محدود کننده نرخ را از این سرویس ها به تماس گیرنده اصلی انتخاب کنید.

توجه: در خدمات HTTP ، متداول ترین روشی که خدمات نشان می دهد که آنها از محدود کردن نرخ استفاده می کنند ، با بازگشت کد وضعیت 429 در پاسخ HTTP است. یک پاسخ 429 می تواند جزئیات دیگری را در مورد اینکه چرا این حد اعمال می شود ارائه دهد (به عنوان مثال ، یک کاربر Freemium سهمیه کمتری دارد ، یا سیستم در حال نگهداری است).

ساده ترین گزینه این است که فقط پاسخ محدود کننده نرخ را از سرویس پایین دست به تماس گیرنده منتقل کنید. یک جایگزین برای اجرای محدودیت نرخ به نمایندگی از سرویس پایین دست و مسدود کردن تماس گیرنده است.

محدودیت نرخ

متداول ترین استراتژی محدود کننده نرخ این سرویس است که یک یا چند تکنیک را برای محدودیت نرخ نرخ اعمال کند. این محدودیت نرخ ممکن است برای محافظت مستقیم از سرویس ایجاد شود ، یا ممکن است برای محافظت از یک منبع پایین دست در صورت مشخص باشد که سرویس پایین دست توانایی محافظت از خود را ندارد. به عنوان مثال ، اگر شما یک سرویس API را اجرا می کنید که به یک سیستم پس زمینه میراث که در زیر بارهای سنگین انعطاف پذیر نیست ، متصل می شود ، سرویس API نباید با فرض اینکه سرویس میراث سیگنال های محدود کننده نرخ خود را ارائه می دهد ، از استراتژی عبور استفاده کند.

برای اجرای محدود کردن نرخ ، ابتدا درک کنید که چرا در این مورد اعمال می شود ، و سپس تعیین کنید که کدام ویژگی های درخواست به بهترین وجه مناسب هستند تا به عنوان کلید محدود کننده مورد استفاده قرار گیرند (برای مثال ، آدرس IP منبع ، کاربر ، کلید API). پس از انتخاب یک کلید محدود کننده ، یک اجرای محدود می تواند از آن برای ردیابی استفاده استفاده کند. با رسیدن به محدودیت ها ، سرویس یک سیگنال محدود کننده را برمی گرداند (معمولاً یک پاسخ 429 HTTP).

پاسخ به تعویق انداختن

اگر محاسبه یک پاسخ گران یا وقت گیر باشد ، ممکن است یک سیستم نتواند پاسخ سریع به یک درخواست ارائه دهد ، این امر باعث می شود یک سرویس برای رسیدگی به نرخ های بالای درخواست ها سخت تر شود. جایگزینی برای محدود کردن نرخ در این موارد ، درخواست درخواست ها به یک صف و بازگشت نوعی شناسه شغلی است. این امر به این سرویس اجازه می دهد تا در دسترس بودن بالاتری را حفظ کند ، و باعث کاهش تلاش محاسباتی برای مشتریانی می شود که در غیر این صورت ممکن است در حالی که منتظر پاسخ هستند ، تماس های مسدود کننده طولانی انجام دهند. چگونگی بازگشت نتیجه پاسخ معوق به تماس گیرنده ، مجموعه دیگری از گزینه ها است ، اما به طور کلی شامل نظرسنجی در مورد وضعیت شناسه شغلی یا از طریق یک سیستم کاملاً مبتنی بر رویداد است که در آن تماس گیرنده می تواند یک تماس تلفنی را ثبت کند یا در یک عضویت در آن شرکت کندکانال رویدادچنین سیستمی خارج از محدوده این سند است.

الگوی پاسخ معوق آسان تر است که پاسخ فوری به یک درخواست هیچ اطلاعات واقعی نداشته باشد. اگر این الگوی بیش از حد مورد استفاده قرار گیرد ، می تواند حالت های پیچیدگی و خرابی سیستم شما را افزایش دهد.

استراتژی های سمت مشتری

استراتژی های شرح داده شده تاکنون برای محدود کردن نرخ در سمت سرور اعمال می شود. با این حال ، این استراتژی ها می توانند از طراحی مشتری مطلع شوند ، به ویژه هنگامی که شما در نظر دارید که بسیاری از مؤلفه های یک سیستم توزیع شده هم مشتری و هم سرور هستند.

درست همانطور که هدف اصلی یک سرویس در استفاده از محدودیت نرخ محافظت از خود و حفظ در دسترس است ، هدف اصلی مشتری تحقق درخواستی است که به یک سرویس ارائه می دهد. یک سرویس ممکن است به دلایل مختلف از جمله موارد زیر نتواند درخواست مشتری را انجام دهد:

• این سرویس به دلیل شرایط شبکه غیرقابل دسترسی است.
• این سرویس خطای غیر اختصاصی را برگرداند.
• این سرویس به دلیل عدم تأیید اعتبار یا مجوز ، درخواست را رد می کند.
• درخواست مشتری نامعتبر یا ناقص است.
• نرخ سرویس محدود به تماس گیرنده است و یک سیگنال فشار خون را ارسال می کند (معمولاً یک پاسخ 429).

توصیه می کنیم مشتری ها را طراحی کنید تا در برابر این نوع مشکلات مقاومت کنید. کتابخانه های مشتری ارائه شده با Google دارای بسیاری از ویژگی های داخلی هستند که سناریوهای فوق را تشخیص می دهند.

در پاسخ به خطاهای محدود کننده نرخ ، متناوب یا غیر اختصاصی ، مشتری معمولاً باید درخواست را پس از تأخیر دوباره امتحان کند. این بهترین روش برای این تأخیر است که پس از هر درخواست ناموفق ، که از آن به عنوان پشتیبان نمایی یاد می شود ، به صورت تصاعدی افزایش می یابد. هنگامی که بسیاری از مشتری ها ممکن است درخواست های مبتنی بر برنامه (مانند واکشی نتایج هر ساعت) را انجام دهند ، باید زمان تصادفی اضافی (jitter) برای زمان بندی درخواست ، دوره بازپرداخت یا هر دو اعمال شود تا اطمینان حاصل شود که این موارد متعدد مشتری تبدیل نمی شوندگله رعد و برق دوره ای ، و خودشان نوعی DDO را ایجاد می کنند.

یک برنامه تلفن همراه را با بسیاری از کاربران تصور کنید که دقیقاً ظهر هر روز با یک API وارد می شود و همان منطق پشتیبان قطعی را اعمال می کند. ظهر ، بسیاری از مشتری ها با سرویس تماس می گیرند ، که محدود کردن نرخ و بازگرداندن پاسخ ها با کد وضعیت 429. مشتری ها پس از آن به طرز شجاعانه عقب می روند و منتظر مدت زمان مشخصی (تأخیر قطعی) دقیقاً 60 ثانیه هستند ، و سپس در ساعت 12:01 سرویس مجموعه بزرگ دیگری از درخواست ها را دریافت می کند. با افزودن یک افست تصادفی (jitter) به زمان درخواست اولیه یا به زمان تأخیر ، درخواست ها و ترمیم ها می توانند به طور مساوی توزیع شوند و به این سرویس فرصت بهتری برای انجام درخواست ها می دهند.

در حالت ایده آل ، می توان درخواست های غیر آمپول را در زمینه یک معامله کاملاً سازگار انجام داد ، اما همه درخواست های خدمات نمی توانند چنین ضمانت هایی را ارائه دهند ، بنابراین مجدداً از این طریق مجدداً داده می شود که داده های جهش یافته باید پیامدهای عمل تکراری را در نظر بگیرند.

برای موقعیت هایی که توسعه دهنده مشتری می داند سیستمی که تماس می گیرد در برابر بارهای استرس زا مقاوم نیست و سیگنال های محدودکننده نرخ (فشار برگشتی) را پشتیبانی نمی کند، توسعه دهنده کتابخانه مشتری یا توسعه دهنده برنامه مشتری می تواند انتخاب کند که از خود تحمیلی استفاده کند. throttling، با استفاده از تکنیک های مشابه برای اعمال محدودیت های نرخ که می تواند در سمت سرور استفاده شود.

برای کلاینت های APIهایی که پاسخ را با شناسه عملیات طولانی مدت ناهمزمان به تعویق می اندازند، مشتری می تواند انتخاب کند که یک حلقه مسدود کردن وضعیت پاسخ معوق را وارد کند و این پیچیدگی را از کاربر کتابخانه سرویس گیرنده حذف کند.

تکنیک های اعمال محدودیت نرخ

به طور کلی، نرخ یک شمارش ساده از رخدادها در طول زمان است. با این حال، چندین تکنیک مختلف برای اندازه گیری و محدود کردن نرخ ها وجود دارد که هر کدام کاربردها و پیامدهای خاص خود را دارند.

• سطل توکن: یک سطل توکن، بودجه استفاده از رول و انباشته را به عنوان تعادل توکن ها حفظ می کند. این تکنیک تشخیص می دهد که همه ورودی های یک سرویس با درخواست ها مطابقت ندارند. یک سطل توکن توکن ها را با نرخی اضافه می کند. هنگامی که یک درخواست سرویس ارائه می شود، سرویس تلاش می کند تا یک توکن (با کاهش تعداد توکن ها) برای انجام درخواست برداشت کند. اگر توکنی در سطل وجود نداشته باشد، سرویس به حد مجاز خود رسیده است و با فشار برگشتی پاسخ می دهد. به عنوان مثال، در یک سرویس GraphQL، یک درخواست واحد ممکن است منجر به چندین عملیات شود که در یک نتیجه ترکیب می شوند. این عملیات ممکن است هر کدام یک توکن داشته باشد. به این ترتیب، سرویس می تواند ظرفیتی را که برای محدود کردن استفاده از آن نیاز دارد، پیگیری کند، نه اینکه تکنیک محدودکننده نرخ را مستقیماً با درخواست ها مرتبط کند.
• سطل نشتی: سطل نشتی شبیه به سطل توکن است، اما میزان آن محدود به مقداری است که می تواند چکه کند یا از سطل نشت کند. این تکنیک تشخیص می دهد که سیستم درجاتی از ظرفیت محدود برای نگه داشتن یک درخواست تا زمانی که سرویس بتواند بر اساس آن عمل کند، دارد. هر اضافی به سادگی روی لبه می ریزد و دور ریخته می شود. این مفهوم از ظرفیت بافر (اما نه لزوماً استفاده از سطل های نشتی) برای اجزای مجاور سرویس شما، مانند متعادل کننده های بار و بافرهای ورودی/خروجی دیسک نیز صدق می کند.
• پنجره ثابت: محدودیت های پنجره ثابت - مانند 3000 درخواست در ساعت یا 10 درخواست در روز - به راحتی قابل بیان است، اما به عنوان بازنشانی سهمیه موجود، در لبه های پنجره قرار دارند. به عنوان مثال، محدودیت 3000 درخواست در ساعت را در نظر بگیرید، که همچنان اجازه می دهد تا 3000 درخواست در اولین دقیقه ساعت انجام شود، که ممکن است سرویس را تحت الشعاع قرار دهد.
• پنجره کشویی: پنجره های کشویی مزایای یک پنجره ثابت را دارند، اما پنجره غلتشی زمان ترکیدن را صاف می کند. سیستم هایی مانند Redis این تکنیک را با کلیدهای در حال انقضا تسهیل می کنند.

هنگامی که تعداد زیادی نمونه از یک سرویس (مانند توابع ابری) در یک سیستم توزیع شده به طور مستقل در حال اجرا هستید، و سرویس باید به طور کلی محدود شود، باید از یک سریع، منطقی جهانی (جهانی برای همه عملکردهای در حال اجرا، نه جهانی) استفاده کنید. لزوماً از نظر جغرافیایی جهانی) مقادیر کلیدی مانند Redis را برای همگام سازی شمارنده های محدود مختلف ذخیره کنید.

ویژگی های محدودکننده نرخ در Google Cloud

هر API Google (داخلی و خارجی) درجاتی از محدودیت یا سهمیه نرخ را اعمال می کند. این یک اصل اساسی در طراحی خدمات در گوگل است. این بخش به این موضوع می پردازد که چگونه این سرویس ها محدودیت نرخ را به عنوان ویژگی ای که می توانید هنگام ساخت در Google Cloud استفاده کنید، نشان می دهند.

سهمیه و سقف

Google Cloud سهمیه هایی را اعمال می کند که میزان استفاده از یک منبع Google Cloud خاص را محدود می کند. سهمیه های نرخ مشخص می کنند که چه مقدار از یک منبع می تواند در یک زمان معین استفاده شود، مانند درخواست های API در روز. شما همچنین می توانید محدودیت های خود را در مورد میزان استفاده از یک منبع در یک زمان معین تعیین کنید. به چنین محدودیت های سفارشی caps می گویند.

برای جزئیات در مورد سهمیه ها و سقف ها، از جمله اطلاعات در مورد نحوه تعیین سقف و درخواست افزایش سهمیه، به کار با سهمیه مراجعه کنید.

هر محصول Google Cloud صفحه ای دارد که محدودیت های خدمات (مانند حداکثر اندازه پیام) و سهمیه های مبتنی بر نرخ (مانند حداکثر تعداد درخواست ها در ثانیه برای یک API خاص) را فهرست می کند. این صفحات همچنین توجه دارند که آیا می توانید درخواست افزایش دهید یا خیر. برای یافتن این صفحات، با این جستجو شروع کنید.

به طور کلی، سهمیه Google Cloud برای هر پروژه است و پنجره ها در هر ثانیه یا در دقیقه هستند. هنگامی که چندین بخش از راه حل خود را در یک پروژه اجرا می کنید، مهم است که توجه داشته باشید که آنها این سهمیه ها را به اشتراک می گذارند.

شما می توانید نحوه مصرف سهمیه شما را رصد کنید و حتی در مورد تغییر در نحوه استفاده از سهمیه ، یا هنگامی که استفاده از مقدار مشخصی بیشتر است ، هشدارهایی را تعیین کنید. شما می توانید کلاه خود را در استفاده از API تنظیم کرده و از هشدارهای بودجه برای کنترل هزینه های مرتبط با استفاده از API استفاده کنید.

کارهای ابری

Cloud Tasks یک سرویس کاملاً مدیریت شده است که می توانید برای مدیریت اجرای ، اعزام و تحویل تعداد زیادی از کارهای توزیع شده از آن استفاده کنید. با استفاده از وظایف ابری ، می توانید به طور غیر همزمان کار را در خارج از درخواست کاربر انجام دهید. وظایف ابری به شما امکان می دهد تا هر دو میزان نرخ و همزمانی را تعیین کنید. Cloud Tasks از تکنیک سطل توکن استفاده می کند تا درجه ای از پشت سر هم در نحوه تحویل پیام ها در این محدوده فراهم شود.

توابع ابری

توابع ابر یک راه حل محاسبات سبک برای توسعه دهندگان برای ایجاد توابع یک منظوره و مستقل است که بدون نیاز به مدیریت یک سرور یا محیط زمان اجرا ، به رویدادهای ابری پاسخ می دهند. توابع ابر به طور پیش فرض بدون تابعیت و بسیار مقیاس پذیر است: زیرساخت های مدیریت شده Google به طور خودکار نمونه های عملکردی را برای رسیدگی به بار درخواست ورودی ایجاد می کند. به دلیل این رفتار مقیاس پذیر ، توابع می توانند به هدف نرخ بالایی از درخواست ها تبدیل شوند و اگر این توابع با خدمات پایین دست تماس بگیرند ، توابع می توانند به منبع DOS ناخواسته در آن سرویس های پایین دست تبدیل شوند.

یک نوع DOS ، فرسودگی اتصال در پایگاه داده ها است. اگر هر نمونه عملکرد یک اتصال بانک اطلاعاتی را به یک باطن ایجاد کند ، ممکن است یک سنبله ترافیک منجر به مقیاس بندی خودکار بسیاری از موارد و در نتیجه ، از بین بردن ظرفیت اتصال موجود در سرورهای پایگاه داده شود. برای جلوگیری از مقیاس بندی توابع فراتر از تعداد مشخصی از نمونه ها ، این سرویس تنظیمات حداکثر در هر عملکرد را ارائه می دهد.

برای توابع پس زمینه ، Google Cloud عملکرد شما را با بار و زمینه رویداد فراخوانی می کند. شما می توانید مشخص کنید که آیا می خواهید سیستم در صورت عدم موفقیت عملکرد شما ، سیستم را دوباره امتحان کند یا قادر به پردازش این رویداد نیست-شاید ، زیرا این امر توسط چیزی در پایین دست محدود شده است.

اگرچه تنظیمات حداکثر می تواند به شما در محدود کردن همزمانی کمک کند ، اما کنترل مستقیم بر چند بار در ثانیه عملکرد شما را می توان کنترل کرد. بخش بعدی را برای آموزش ها نشان می دهد که نحوه استفاده از Redis برای هماهنگی سطح جهانی محدود کردن در دعوت های عملکرد را مشاهده کنید.

pub/sub: کنترل جریان

Pub/Sub یک سرویس پیام رسانی کاملاً مدیریت شده در زمان واقعی است که به شما امکان می دهد پیام های بین برنامه های مستقل را ارسال و دریافت کنید. هنگام جابجایی تعداد زیادی از پیام ها از طریق مباحث میخانه/زیر ، ممکن است نیاز به تنظیم نرخ نحوه پردازش پیام ها در مصرف مشتری داشته باشید تا مصرف کنندگان کار به صورت موازی مؤثر باشند و پیام های برجسته زیادی را در اختیار نداشته باشند و بر تأخیر کلی پردازش تأثیر بگذارند. برای تنظیم این رفتار ، میخانه/زیر مشتری چندین تنظیم کنترل جریان را در معرض نمایش قرار می دهند.

ابر ابر

Cloud Run یک بستر محاسباتی مدیریت شده است که به شما امکان می دهد ظروف بدون تابعیت را که از طریق درخواست های HTTP قابل استفاده هستند ، اجرا کنید. بر خلاف توابع ابر ، یک نمونه کانتینر واحد می تواند چندین درخواست را به طور همزمان پردازش کند اگر توسط پشته سرو در ظرف پشتیبانی شود.

اتیو

ISTIO یک سرویس مستقل از منبع باز است که اصول لازم را برای اجرای موفقیت آمیز معماری توزیع شده میکروسرویس فراهم می کند. یک معماری Microservice انعطاف پذیر نیاز به خدمات دفاعی در برابر خدمات Rogue Peer دارد ، بنابراین ISTIO نرخ محدود کننده نرخ را مستقیماً در مش خدمات فراهم می کند.

نقاط پایانی ابر

Cloud Endpoints یک سیستم مدیریت API است که به شما کمک می کند تا با استفاده از همان زیرساخت هایی که Google برای API های خاص خود از آن استفاده می کند ، در API های خود ایمن ، نظارت ، تجزیه و تحلیل و تنظیم سهمیه در API های خود کنید. به عنوان خدمتی که برای کمک به شما در افشای خدمات به دنیای خارجی طراحی شده است ، امکان پیکربندی سهمیه های شخصی شما ، از جمله سیاست های مبتنی بر نرخ را فراهم می کند.

قصور

Apigee بستری برای توسعه و مدیریت پروکسی های API است. پروکسی API رابط شما با توسعه دهندگان است که می خواهند از خدمات باطن شما استفاده کنند. آنها به جای اینکه مستقیماً آن خدمات را مصرف کنند ، به یک پروکسی APIGEE API که ایجاد می کنید دسترسی پیدا می کنند. معمول است که Apigee را در مقابل سرویس های باطن قرار دهید که ممکن است قابلیت محدود کننده نرخ خود را نداشته باشند ، بنابراین محدود کردن نرخ ویژگی داخلی Apigee است.

Google Cloud Armor

Google Cloud Armor از زیرساخت های جهانی و سیستم های امنیتی Google برای دفاع در برابر حملات توزیع شده خدمات (DDOS) علیه زیرساخت ها و برنامه ها استفاده می کند. این شامل منطق داخلی در مورد سنبله های مخرب و بارهای با نرخ بالا به خدمات محافظت شده شما است.

سپر پروژه

اگرچه یک سرویس Google Cloud نیست ، Project Shield از زیرساخت های Google برای محافظت از سایت های واجد شرایط در برابر حملات DDOS استفاده می کند.

تکنیک های اضافی برای مقاومت بیشتر

محدود کردن نرخ در سطح برنامه می تواند با افزایش مقاومت ، خدمات را ارائه دهد ، اما با ترکیب محدود کردن نرخ سطح برنامه با سایر تکنیک ها می توان مقاومت را بیشتر بهبود بخشید:

ذخیره سازی: ذخیره سازی نتایج که برای محاسبه کند است ، باعث می شود که یک سرویس بتواند نرخ درخواست های بالاتری را پردازش کند ، که ممکن است باعث شود فشار محدود کننده نرخ کمتر برای مشتری اعمال شود.

شکستن مدار: شما می توانید شبکه های خدماتی را نسبت به مشکلات ناشی از انتشار خطاهای مکرر با ایجاد قطعاتی از سیستم به طور موقت به حالت آرام ، مقاوم تر کنید. برای اجرای مثال ، به بخش شکستن مدار مستندات ISTIO مراجعه کنید.

اولویت بندی: همه کاربران یک سیستم از اولویت برابر نیستند. عوامل دیگری را در طراحی کلیدهای محدود کننده نرخ در نظر بگیرید تا اطمینان حاصل شود که به مشتریان با اولویت بالاتر ارائه می شود. برای از بین بردن بار ترافیک اولویت پایین از سیستم ها می توانید از ریختن بار استفاده کنید.

محدود کردن نرخ در چندین لایه: اگر رابط شبکه دستگاه یا هسته سیستم عامل شما تحت الشعاع قرار می گیرد ، ممکن است محدود کردن نرخ برنامه کاربردی حتی ممکن است حتی فرصتی برای شروع نداشته باشد. شما می توانید محدودیت های نرخ را در لایه 3 در iptables اعمال کنید ، یا لوازم خانگی می توانند در لایه 4 محدود شوند. شما همچنین ممکن است در معرض محدودیت های قابل تنظیم قرار بگیرید که برای I/O سیستم خود برای مواردی مانند دیسک و بافر شبکه اعمال می شود.

نظارت: این مهم است که پرسنل سیستم های عملیاتی بدانند که هنگام وقوع پرتاب ، می دانند. نظارت بر نرخ هایی که بیش از سهمیه است برای مدیریت حادثه و گرفتن رگرسیون در نرم افزار بسیار مهم است. ما توصیه می کنیم چنین مانیتورینگ را هم برای مشتری و هم برای سرور خدمات ارائه دهید. همه وقایع محدود کننده نرخ نباید باعث هشدارهایی شود که نیاز به توجه فوری پرسنل عملیات داشته باشد. در موارد غیر خارج از کشور ، می توانید بعداً به عنوان بخشی از ارزیابی روتین و نگهداری سیستم خود به سیگنال های محدود کننده نرخ پاسخ دهید. شما می توانید از سیاهههای مربوط استفاده کنید که محدودیت نرخ به عنوان سیگنالی برای ایجاد تغییرات وجود دارد ، مانند افزایش ظرفیت یک مؤلفه ، درخواست افزایش سهمیه یا اصلاح یک خط مشی.

چه بعدی

کتابهای SRE برای طراحی سیستم های پیچیده نکات بسیار خوبی دارند.

این پست های وبلاگ از سازمان های دیگر ، محدودیت نرخ را بررسی می کنند:

این آموزش ها دستورالعمل های گام به گام را برای تکنیک های محدود کننده نرخ ارائه می دهند:

به جز آنچه در غیر این صورت ذکر شد ، محتوای این صفحه تحت مجوز Creative Commons Attribution 4. 0 مجوز دارد و نمونه های کد تحت مجوز Apache 2. 0 مجوز دارند. برای جزئیات بیشتر ، به سیاست های سایت Google Developers مراجعه کنید. جاوا یک علامت تجاری ثبت شده اوراکل و/یا شرکت های وابسته به آن است.