ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇ ದರ ಮಿತಿ: ವಿನಂತಿ ಥ್ರಾಟ್ಲಿಂಗ್‌ಗೆ ಜಾಗತಿಕ ವಿಧಾನ

ಇಂದಿನ ಅಂತರ್ಸಂಪರ್ಕಿತ ಡಿಜಿಟಲ್ ಜಗತ್ತಿನಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ವಿತರಿಸಿದ ಸೇವೆಗಳು ಮತ್ತು API ಗಳ ಅಡಿಪಾಯದ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ. ಈ ವ್ಯವಸ್ಥೆಗಳು ವಿಸ್ತರಿಸಿದಂತೆ, ಒಳಬರುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ದುರುಪಯೋಗವನ್ನು ತಡೆಯಲು ಮತ್ತು ಜಾಗತಿಕ ಬಳಕೆದಾರರಿಗೆ ಉತ್ತಮ ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಅತ್ಯಗತ್ಯವಾಗುತ್ತದೆ. ಇಲ್ಲಿಯೇ API ಗೇಟ್‌ವೇ ದರ ಮಿತಿ, ವಿಶೇಷವಾಗಿ ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇ ಲೇಯರ್‌ನಲ್ಲಿ ಅಳವಡಿಸಲಾದ ವಿನಂತಿ ಥ್ರಾಟ್ಲಿಂಗ್, ಒಂದು ನಿರ್ಣಾಯಕ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ. ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇ ದರ ಮಿತಿಯ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಅನ್ವೇಷಿಸುತ್ತದೆ, ವಿಶ್ವಾದ್ಯಂತದ ಪ್ರೇಕ್ಷಕರಿಗೆ ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ ತಂತ್ರಗಳು ಮತ್ತು ಒಳನೋಟಗಳನ್ನು ನೀಡುತ್ತದೆ.

API ಗೇಟ್‌ವೇ ದರ ಮಿತಿಯ ಅನಿವಾರ್ಯತೆ

ಒಂದು API ಗೇಟ್‌ವೇ ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಗಳಿಗೆ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳಿಗೆ ಒಂದೇ ಪ್ರವೇಶ ಬಿಂದುವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವಿನಂತಿ ನಿರ್ವಹಣೆಯನ್ನು ಕೇಂದ್ರೀಕರಿಸುವ ಮೂಲಕ, ದರ ಮಿತಿಯಂತಹ ನೀತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲು ಇದು ಸೂಕ್ತ ಸ್ಥಳವಾಗುತ್ತದೆ. ದರ ಮಿತಿಯು ನಿರ್ದಿಷ್ಟ ಸಮಯದೊಳಗೆ ಕ್ಲೈಂಟ್ ನಿಮ್ಮ API ಗೆ ಮಾಡಬಹುದಾದ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಬಳಸುವ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ಪರಿಣಾಮಕಾರಿ ದರ ಮಿತಿಯಿಲ್ಲದೆ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹಲವಾರು ಸಮಸ್ಯೆಗಳಿಗೆ ಗುರಿಯಾಗುತ್ತವೆ:

• ಸೇವಾ ನಿರಾಕರಣೆ (DoS) ಮತ್ತು ವಿತರಣಾ ಸೇವಾ ನಿರಾಕರಣೆ (DDoS) ದಾಳಿಗಳು: ದುರುದ್ದೇಶಪೂರಿತ ವ್ಯಕ್ತಿಗಳು ನಿಮ್ಮ API ಅನ್ನು ಅತಿಯಾದ ವಿನಂತಿಗಳಿಂದ ತುಂಬಿಹಾಕಬಹುದು, ಇದರಿಂದ ನಿಮ್ಮ ಸೇವೆಗಳು ಕಾನೂನುಬದ್ಧ ಬಳಕೆದಾರರಿಗೆ ಲಭ್ಯವಾಗದಂತೆ ಮಾಡಬಹುದು.
• ಸಂಪನ್ಮೂಲಗಳ ಖಾಲಿಯಾಗುವಿಕೆ: ಅನಿಯಂತ್ರಿತ ಟ್ರಾಫಿಕ್ ಸಿಪಿಯು, ಮೆಮೊರಿ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕಗಳಂತಹ ಬ್ಯಾಕೆಂಡ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು, ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುಸಿತಕ್ಕೆ ಅಥವಾ ಸಂಪೂರ್ಣ ಸೇವಾ ಸ್ಥಗಿತಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.
• ಹೆಚ್ಚಿದ ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚಗಳು: ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಪ್ರಮಾಣಗಳು ಹೆಚ್ಚಾಗಿ ಮೂಲಸೌಕರ್ಯ ವೆಚ್ಚಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ಕ್ಲೌಡ್ ಪರಿಸರದಲ್ಲಿ ಸ್ಕೇಲಿಂಗ್ ನೇರವಾಗಿ ಬಳಕೆಗೆ ಸಂಬಂಧಿಸಿರುತ್ತದೆ.
• ಕಳಪೆ ಬಳಕೆದಾರ ಅನುಭವ: API ಗಳು ಓವರ್‌ಲೋಡ್ ಆದಾಗ, ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ, ಇದು ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ನಿರಾಶಾದಾಯಕ ಅನುಭವಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಇದು ಗ್ರಾಹಕರನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಮತ್ತು ಖ್ಯಾತಿಗೆ ಹಾನಿಯಾಗಲು ಕಾರಣವಾಗಬಹುದು.
• API ದುರುಪಯೋಗ: ಕಾನೂನುಬದ್ಧ ಬಳಕೆದಾರರು ಅಜಾಗರೂಕತೆಯಿಂದ ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ, ವಿಶೇಷವಾಗಿ ಗರಿಷ್ಠ ಸಮಯದಲ್ಲಿ ಅಥವಾ ಕಳಪೆಯಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ, ಇತರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವಂತೆ ಹಲವಾರು ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಬಹುದು.

ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇ ದರ ಮಿತಿಯು ಈ ಬೆದರಿಕೆಗಳ ವಿರುದ್ಧ ನಿರ್ಣಾಯಕ ಮೊದಲ ರಕ್ಷಣಾ ರೇಖೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ನಿಮ್ಮ API ವಿಶ್ವಾದ್ಯಂತದ ಬಳಕೆದಾರರಿಗೆ ಪ್ರವೇಶಿಸಬಹುದಾದ, ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿರುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಪ್ರಮುಖ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು: ದರ ಮಿತಿ ಮತ್ತು ಥ್ರಾಟ್ಲಿಂಗ್

ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಅರ್ಥದಲ್ಲಿ ಬಳಸಲಾಗುತ್ತಿದ್ದರೂ, API ನಿರ್ವಹಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ ದರ ಮಿತಿ ಮತ್ತು ಥ್ರಾಟ್ಲಿಂಗ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸುವುದು ಮುಖ್ಯ:

• ದರ ಮಿತಿ (Rate Limiting): ಇದು ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ದರವನ್ನು ನಿಯಂತ್ರಿಸುವ ಒಟ್ಟಾರೆ ನೀತಿಯಾಗಿದೆ. ಇದು ನಿರ್ದಿಷ್ಟ ಅವಧಿಯಲ್ಲಿ ಅನುಮತಿಸಲಾದ ಗರಿಷ್ಠ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 100 ವಿನಂತಿಗಳು).
• ಥ್ರಾಟ್ಲಿಂಗ್ (Throttling): ಇದು ದರ ಮಿತಿಯನ್ನು ಜಾರಿಗೊಳಿಸುವ ನಿಜವಾದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ಮಿತಿಯನ್ನು ತಲುಪಿದಾಗ, ನಂತರದ ವಿನಂತಿಗಳನ್ನು ನಿಧಾನಗೊಳಿಸಲು ಅಥವಾ ತಿರಸ್ಕರಿಸಲು ಥ್ರಾಟ್ಲಿಂಗ್ ಕಾರ್ಯವಿಧಾನಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಸಾಮಾನ್ಯ ಥ್ರಾಟ್ಲಿಂಗ್ ಕ್ರಮಗಳು ದೋಷ ಕೋಡ್ (429 Too Many Requests ನಂತಹ) ಹಿಂತಿರುಗಿಸುವುದು, ವಿನಂತಿಗಳನ್ನು ಸರದಿಯಲ್ಲಿಡುವುದು, ಅಥವಾ ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕೈಬಿಡುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ.

API ಗೇಟ್‌ವೇಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ದರ ಮಿತಿಯು ತಂತ್ರವಾಗಿದೆ, ಮತ್ತು ಥ್ರಾಟ್ಲಿಂಗ್ ಅನುಷ್ಠಾನ ತಂತ್ರವಾಗಿದೆ. ಈ ಮಾರ್ಗದರ್ಶಿಯು ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇನಲ್ಲಿ ಈ ತಂತ್ರಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ.

ಸರಿಯಾದ ದರ ಮಿತಿ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು

ವಿನಂತಿ ಥ್ರಾಟ್ಲಿಂಗ್‌ಗಾಗಿ ಹಲವಾರು ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬಳಸಬಹುದು. ಆಯ್ಕೆಯು ನಿಮ್ಮ ನಿಖರತೆ, ನ್ಯಾಯಸಮ್ಮತತೆ ಮತ್ತು ಸಂಪನ್ಮೂಲ ಬಳಕೆಯ ನಿರ್ದಿಷ್ಟ ಅಗತ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಇಲ್ಲಿ ಕೆಲವು ಸಾಮಾನ್ಯವಾದವುಗಳು:

1. ಫಿಕ್ಸೆಡ್ ವಿಂಡೋ ಕೌಂಟರ್

ಪರಿಕಲ್ಪನೆ: ಇದು ಸರಳವಾದ ಅಲ್ಗಾರಿದಮ್. ಇದು ಸಮಯವನ್ನು ಸ್ಥಿರ ವಿಂಡೋಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, 60 ಸೆಕೆಂಡುಗಳು). ಪ್ರಸ್ತುತ ವಿಂಡೋದಲ್ಲಿನ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಒಂದು ಕೌಂಟರ್ ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ. ವಿಂಡೋ ಮರುಹೊಂದಿದಾಗ, ಕೌಂಟರ್ ಶೂನ್ಯಕ್ಕೆ ಮರುಹೊಂದುತ್ತದೆ. ಪ್ರತಿ ಒಳಬರುವ ವಿನಂತಿಯು ಕೌಂಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಉದಾಹರಣೆ: ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 100 ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಿ. ಒಂದು ವಿನಂತಿಯು 10:00:30 ಕ್ಕೆ ಬಂದರೆ, ಅದನ್ನು 10:00:00 - 10:00:59 ವಿಂಡೋಗೆ ಎಣಿಸಲಾಗುತ್ತದೆ. 10:01:00 ಕ್ಕೆ, ವಿಂಡೋ ಮರುಹೊಂದುತ್ತದೆ, ಮತ್ತು ಕೌಂಟರ್ ಶೂನ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಅನುಕೂಲಗಳು: ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸರಳ. ಕಡಿಮೆ ಸಂಪನ್ಮೂಲ ಬಳಕೆ.

ಅನಾನುಕೂಲಗಳು: ವಿಂಡೋದ ಆರಂಭ ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಟ್ರಾಫಿಕ್‌ನ ಸ್ಫೋಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರನು ಒಂದು ವಿಂಡೋದ ಕೊನೆಯ ಸೆಕೆಂಡಿನಲ್ಲಿ 100 ವಿನಂತಿಗಳನ್ನು ಮತ್ತು ಮುಂದಿನ ವಿಂಡೋದ ಮೊದಲ ಸೆಕೆಂಡಿನಲ್ಲಿ ಮತ್ತೊಂದು 100 ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿದರೆ, ಅವರು ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ 200 ವಿನಂತಿಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಳುಹಿಸಬಹುದು.

2. ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಕೌಂಟರ್

ಪರಿಕಲ್ಪನೆ: ಈ ಅಲ್ಗಾರಿದಮ್ ಪ್ರಸ್ತುತ ಸಮಯವನ್ನು ಪರಿಗಣಿಸುವ ಮೂಲಕ ಸ್ಥಿರ ವಿಂಡೋ ವಿಧಾನವನ್ನು ಸುಧಾರಿಸುತ್ತದೆ. ಇದು ಪ್ರಸ್ತುತ ಸಮಯದ ಚೌಕಟ್ಟಿನಲ್ಲಿನ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮತ್ತು ಹಿಂದಿನ ಸಮಯದ ಚೌಕಟ್ಟಿನಲ್ಲಿನ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು, ಹಿಂದಿನ ಸಮಯದ ಚೌಕಟ್ಟಿನ ಪ್ರಮಾಣಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ಇದು ಇತ್ತೀಚಿನ ಚಟುವಟಿಕೆಯ ಹೆಚ್ಚು ನಿಖರವಾದ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ನೀಡುತ್ತದೆ.

ಉದಾಹರಣೆ: ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 100 ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಿ. 10:00:30 ಕ್ಕೆ, ಅಲ್ಗಾರಿದಮ್ 10:00:00 ರಿಂದ 10:00:30 ರವರೆಗಿನ ವಿನಂತಿಗಳನ್ನು ಮತ್ತು ವಿಂಡೋ ದೊಡ್ಡದಾಗಿದ್ದರೆ ಹಿಂದಿನ ನಿಮಿಷದಿಂದ ಕೆಲವು ವಿನಂತಿಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತದೆ. ಇದು ವಿನಂತಿಗಳ ಸುಗಮ ವಿತರಣೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಅನುಕೂಲಗಳು: ಸ್ಥಿರ ವಿಂಡೋ ಕೌಂಟರ್‌ನ ಸ್ಫೋಟಕ ಟ್ರಾಫಿಕ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಕಾಲಾನಂತರದಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವಲ್ಲಿ ಹೆಚ್ಚು ನಿಖರ.

ಅನಾನುಕೂಲಗಳು: ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಮತ್ತು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಹೆಚ್ಚು ಮೆಮೊರಿ ಅಗತ್ಯವಿರುತ್ತದೆ.

3. ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಲಾಗ್

ಪರಿಕಲ್ಪನೆ: ಈ ಅಲ್ಗಾರಿದಮ್ ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳ ವಿಂಗಡಿಸಲಾದ ಪಟ್ಟಿಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಹೊಸ ವಿನಂತಿಯು ಬಂದಾಗ, ಪ್ರಸ್ತುತ ಸಮಯದ ವಿಂಡೋಗಿಂತ ಹಳೆಯದಾದ ಎಲ್ಲಾ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಉಳಿದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳ ಎಣಿಕೆಯನ್ನು ನಂತರ ಮಿತಿಯ ವಿರುದ್ಧ ಹೋಲಿಸಲಾಗುತ್ತದೆ.

ಉದಾಹರಣೆ: ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 100 ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಿ. ಒಂದು ವಿನಂತಿಯು 10:01:15 ಕ್ಕೆ ಬಂದರೆ, ಸಿಸ್ಟಮ್ 10:00:15 ರ ನಂತರ ದಾಖಲಾದ ಎಲ್ಲಾ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅಂತಹ 100 ಕ್ಕಿಂತ ಕಡಿಮೆ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ಅನುಮತಿಸಲಾಗುತ್ತದೆ.

ಅನುಕೂಲಗಳು: ಹೆಚ್ಚು ನಿಖರ ಮತ್ತು ಸ್ಫೋಟಕ ಟ್ರಾಫಿಕ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ತಡೆಯುತ್ತದೆ.

ಅನಾನುಕೂಲಗಳು: ಪ್ರತಿ ವಿನಂತಿಗೆ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯದಿಂದಾಗಿ ಸಂಪನ್ಮೂಲ-ತೀವ್ರ. ಮೆಮೊರಿ ಮತ್ತು ಪ್ರೊಸೆಸಿಂಗ್ ವಿಷಯದಲ್ಲಿ, ವಿಶೇಷವಾಗಿ ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ API ಗಳಿಗೆ, ದುಬಾರಿಯಾಗಬಹುದು.

4. ಟೋಕನ್ ಬಕೆಟ್

ಪರಿಕಲ್ಪನೆ: ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಬಕೆಟ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಟೋಕನ್‌ಗಳನ್ನು ಸ್ಥಿರ ದರದಲ್ಲಿ (ರಿಫಿಲ್ ದರ) ಬಕೆಟ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿ ವಿನಂತಿಯು ಒಂದು ಟೋಕನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಬಕೆಟ್ ಖಾಲಿಯಾಗಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ ಅಥವಾ ಸರದಿಯಲ್ಲಿಡಲಾಗುತ್ತದೆ. ಬಕೆಟ್‌ಗೆ ಗರಿಷ್ಠ ಸಾಮರ್ಥ್ಯವಿದೆ, ಅಂದರೆ ಟೋಕನ್‌ಗಳು ನಿರ್ದಿಷ್ಟ ಹಂತದವರೆಗೆ ಸಂಗ್ರಹವಾಗಬಹುದು.

ಉದಾಹರಣೆ: ಒಂದು ಬಕೆಟ್ 100 ಟೋಕನ್‌ಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10 ಟೋಕನ್‌ಗಳ ದರದಲ್ಲಿ ಮರುಪೂರಣಗೊಳ್ಳುತ್ತದೆ. 20 ವಿನಂತಿಗಳು ತಕ್ಷಣವೇ ಬಂದರೆ, ಮೊದಲ 10 ಟೋಕನ್‌ಗಳನ್ನು ಬಳಸಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಮುಂದಿನ 10 ವಿನಂತಿಗಳನ್ನು ಬಕೆಟ್ ಖಾಲಿಯಾಗಿರುವುದರಿಂದ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ನಂತರ ವಿನಂತಿಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 5 ರ ದರದಲ್ಲಿ ಬಂದರೆ, ಟೋಕನ್‌ಗಳು ಮರುಪೂರಣಗೊಂಡಂತೆ ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಅನುಕೂಲಗಳು: ಸರಾಸರಿ ದರವನ್ನು ನಿರ್ವಹಿಸುವಾಗ ಅಲ್ಪಾವಧಿಯ ಟ್ರಾಫಿಕ್ ಸ್ಫೋಟಗಳನ್ನು (ಬಕೆಟ್ ಸಾಮರ್ಥ್ಯದವರೆಗೆ) ಅನುಮತಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ನ್ಯಾಯಸಮ್ಮತತೆಯ ನಡುವಿನ ಉತ್ತಮ ಸಮತೋಲನವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ.

ಅನಾನುಕೂಲಗಳು: ಬಕೆಟ್ ಗಾತ್ರ ಮತ್ತು ರಿಫಿಲ್ ದರವನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಟ್ಯೂನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇನ್ನೂ ಕೆಲವು ಸ್ಫೋಟಕತೆಯನ್ನು ಅನುಮತಿಸಬಹುದು.

5. ಲೀಕಿ ಬಕೆಟ್

ಪರಿಕಲ್ಪನೆ: ವಿನಂತಿಗಳನ್ನು ಸರದಿಗೆ (ಬಕೆಟ್) ಸೇರಿಸಲಾಗುತ್ತದೆ. ವಿನಂತಿಗಳನ್ನು ಸ್ಥಿರ ದರದಲ್ಲಿ (ಲೀಕ್ ದರ) ಸರದಿಯಿಂದ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಸರದಿ ಪೂರ್ಣವಾಗಿದ್ದರೆ, ಹೊಸ ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.

ಉದಾಹರಣೆ: ಒಂದು ಬಕೆಟ್ 100 ವಿನಂತಿಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 5 ವಿನಂತಿಗಳ ದರದಲ್ಲಿ ಸೋರುತ್ತದೆ. 50 ವಿನಂತಿಗಳು ಒಂದೇ ಬಾರಿಗೆ ಬಂದರೆ, ಅವುಗಳನ್ನು ಸರದಿಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ತಕ್ಷಣವೇ ಮತ್ತೊಂದು 10 ವಿನಂತಿಗಳು ಬಂದರೆ, ಮತ್ತು ಸರದಿಯಲ್ಲಿ ಇನ್ನೂ ಸ್ಥಳವಿದ್ದರೆ, ಅವುಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. ಸರದಿಯು ಈಗಾಗಲೇ 90 ರಲ್ಲಿದ್ದಾಗ 100 ವಿನಂತಿಗಳು ಬಂದರೆ, 10 ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತವೆ. ಸಿಸ್ಟಮ್ ನಂತರ ಸರದಿಯಿಂದ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 5 ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.

ಅನುಕೂಲಗಳು: ಟ್ರಾಫಿಕ್ ಸ್ಫೋಟಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸುಗಮಗೊಳಿಸುತ್ತದೆ, ವಿನಂತಿಗಳ ಸ್ಥಿರವಾದ ಹೊರಹರಿವನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಊಹಿಸಬಹುದಾದ ಲೇಟೆನ್ಸಿ.

ಅನಾನುಕೂಲಗಳು: ವಿನಂತಿಗಳು ಸರದಿಯಲ್ಲಿ ಕಾಯುವುದರಿಂದ ಲೇಟೆನ್ಸಿಯನ್ನು ಪರಿಚಯಿಸಬಹುದು. ತ್ವರಿತ ಸ್ಫೋಟ ನಿರ್ವಹಣೆ ಅಗತ್ಯವಿದ್ದರೆ ಸೂಕ್ತವಲ್ಲ.

ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇನಲ್ಲಿ ದರ ಮಿತಿಯನ್ನು ಅಳವಡಿಸುವುದು

ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇ ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ ದರ ಮಿತಿಯನ್ನು ಅಳವಡಿಸಲು ಸೂಕ್ತ ಸ್ಥಳವಾಗಿದೆ:

• ಕೇಂದ್ರೀಕೃತ ನಿಯಂತ್ರಣ: ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಗೇಟ್‌ವೇ ಮೂಲಕ ಹಾದು ಹೋಗುತ್ತವೆ, ಇದು ಜಾರಿಗೊಳಿಸಲು ಒಂದೇ ಬಿಂದುವನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
• ಅಮೂರ್ತತೆ: ಇದು ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಗಳನ್ನು ದರ ಮಿತಿಯ ತರ್ಕದ ಸಂಕೀರ್ಣತೆಗಳಿಂದ ರಕ್ಷಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು ವ್ಯವಹಾರ ತರ್ಕದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
• ಸ್ಕೇಲೆಬಿಲಿಟಿ: API ಗೇಟ್‌ವೇಗಳನ್ನು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಸ್ವತಂತ್ರವಾಗಿ ಸ್ಕೇಲ್ ಮಾಡಬಹುದು.
• ಹೊಂದಿಕೊಳ್ಳುವಿಕೆ: ಕ್ಲೈಂಟ್, API ಎಂಡ್‌ಪಾಯಿಂಟ್, ಅಥವಾ ಇತರ ಸಂದರ್ಭೋಚಿತ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ ವಿಭಿನ್ನ ದರ ಮಿತಿ ತಂತ್ರಗಳನ್ನು ಅನ್ವಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯ ದರ ಮಿತಿ ತಂತ್ರಗಳು ಮತ್ತು ಮಾನದಂಡಗಳು

ಪರಿಣಾಮಕಾರಿ ದರ ಮಿತಿಯು ಸಾಮಾನ್ಯವಾಗಿ ವಿವಿಧ ಮಾನದಂಡಗಳ ಆಧಾರದ ಮೇಲೆ ವಿಭಿನ್ನ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಇಲ್ಲಿ ಕೆಲವು ಸಾಮಾನ್ಯ ತಂತ್ರಗಳಿವೆ:

1. ಕ್ಲೈಂಟ್ IP ವಿಳಾಸದ ಮೂಲಕ

ವಿವರಣೆ: ನಿರ್ದಿಷ್ಟ ಸಮಯದ ಚೌಕಟ್ಟಿನೊಳಗೆ ನಿರ್ದಿಷ್ಟ IP ವಿಳಾಸದಿಂದ ಬರುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. ಇದು ಬ್ರೂಟ್-ಫೋರ್ಸ್ ದಾಳಿಗಳು ಮತ್ತು ಸಾಮಾನ್ಯ ದುರುಪಯೋಗದ ವಿರುದ್ಧ ಮೂಲಭೂತ ಆದರೆ ಪರಿಣಾಮಕಾರಿ ಕ್ರಮವಾಗಿದೆ.

ಅನುಷ್ಠಾನದ ಪರಿಗಣನೆಗಳು:

• NAT ಮತ್ತು ಪ್ರಾಕ್ಸಿಗಳು: ನೆಟ್ವರ್ಕ್ ವಿಳಾಸ ಅನುವಾದ (NAT) ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳಿಂದಾಗಿ ಅನೇಕ ಬಳಕೆದಾರರು ಒಂದೇ ಸಾರ್ವಜನಿಕ IP ವಿಳಾಸವನ್ನು ಹಂಚಿಕೊಳ್ಳಬಹುದು ಎಂಬುದನ್ನು ಗಮನದಲ್ಲಿಡಿ. ಇದು ಕಾನೂನುಬದ್ಧ ಬಳಕೆದಾರರನ್ನು ಅನ್ಯಾಯವಾಗಿ ಥ್ರಾಟ್ಲ್ ಮಾಡಲು ಕಾರಣವಾಗಬಹುದು.
• IPv6: IPv6 ನ ವಿಶಾಲ ವಿಳಾಸ ಸ್ಥಳವು IP-ಆಧಾರಿತ ಮಿತಿಯು ಕಡಿಮೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿರಬಹುದು ಅಥವಾ ಹೆಚ್ಚಿನ ಮಿತಿಗಳ ಅಗತ್ಯವಿರಬಹುದು.
• ಜಾಗತಿಕ ಸಂದರ್ಭ: ಒಂದೇ IP ಯು ಡೇಟಾಸೆಂಟರ್ ಅಥವಾ ಜಾಗತಿಕವಾಗಿ ಅನೇಕ ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಹಂಚಿಕೆಯ ನೆಟ್ವರ್ಕ್ ಮೂಲಸೌಕರ್ಯದಿಂದ ಬರಬಹುದು ಎಂದು ಪರಿಗಣಿಸಿ.

2. API ಕೀ ಅಥವಾ ಕ್ಲೈಂಟ್ ID ಮೂಲಕ

ವಿವರಣೆ: ವಿನಂತಿಗಳನ್ನು API ಕೀ ಅಥವಾ ಕ್ಲೈಂಟ್ ಐಡೆಂಟಿಫೈಯರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತದೆ. ಇದು ನಿಮ್ಮ API ಯ ಪ್ರತ್ಯೇಕ ಗ್ರಾಹಕರ ಮೇಲೆ ಸೂಕ್ಷ್ಮ ನಿಯಂತ್ರಣವನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಶ್ರೇಣೀಕೃತ ಪ್ರವೇಶ ಮತ್ತು ಬಳಕೆಯ ಕೋಟಾಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ.

ಅನುಷ್ಠಾನದ ಪರಿಗಣನೆಗಳು:

• ಸುರಕ್ಷಿತ ಕೀ ನಿರ್ವಹಣೆ: API ಕೀಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ರಚಿಸಬೇಕು, ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ರವಾನಿಸಬೇಕು.
• ಶ್ರೇಣೀಕೃತ ಯೋಜನೆಗಳು: ವಿಭಿನ್ನ ಶ್ರೇಣಿಗಳು (ಉದಾ. ಉಚಿತ, ಪ್ರೀಮಿಯಂ, ಎಂಟರ್‌ಪ್ರೈಸ್) ತಮ್ಮ ತಮ್ಮ API ಕೀಗಳಿಗೆ ವಿಭಿನ್ನ ದರ ಮಿತಿಗಳನ್ನು ಹೊಂದಿರಬಹುದು.
• ಹಿಂತೆಗೆದುಕೊಳ್ಳುವಿಕೆ: ರಾಜಿಯಾದ ಅಥವಾ ದುರುಪಯೋಗಪಡಿಸಿಕೊಂಡ API ಕೀಗಳನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳುವ ಕಾರ್ಯವಿಧಾನಗಳು ಅತ್ಯಗತ್ಯ.

3. ಬಳಕೆದಾರ ID ಮೂಲಕ (ದೃಢೀಕೃತ ಬಳಕೆದಾರರು)

ವಿವರಣೆ: ಬಳಕೆದಾರನು ದೃಢೀಕರಣಗೊಂಡ ನಂತರ (ಉದಾ. OAuth, JWT ಮೂಲಕ), ಅವರ ವಿನಂತಿಗಳನ್ನು ಅವರ ಅನನ್ಯ ಬಳಕೆದಾರ ID ಆಧಾರದ ಮೇಲೆ ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು ಮತ್ತು ಸೀಮಿತಗೊಳಿಸಬಹುದು. ಇದು ಅತ್ಯಂತ ವೈಯಕ್ತೀಕರಿಸಿದ ಮತ್ತು ನ್ಯಾಯಯುತ ದರ ಮಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಅನುಷ್ಠಾನದ ಪರಿಗಣನೆಗಳು:

• ದೃಢೀಕರಣ ಪ್ರವಾಹ: ದರ ಮಿತಿಯನ್ನು ಅನ್ವಯಿಸುವ ಮೊದಲು ದೃಢವಾದ ದೃಢೀಕರಣ ಕಾರ್ಯವಿಧಾನದ ಅಗತ್ಯವಿದೆ.
• ಸೆಷನ್ ನಿರ್ವಹಣೆ: ದೃಢೀಕೃತ ಬಳಕೆದಾರರೊಂದಿಗೆ ವಿನಂತಿಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಂಯೋಜಿಸುವುದು ನಿರ್ಣಾಯಕ.
• ಅಡ್ಡ-ಸಾಧನ/ಬ್ರೌಸರ್: ಅನೇಕ ಸಾಧನಗಳು ಅಥವಾ ಬ್ರೌಸರ್‌ಗಳಿಂದ ನಿಮ್ಮ ಸೇವೆಗೆ ಪ್ರವೇಶಿಸುವ ಬಳಕೆದಾರರನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು ಎಂದು ಪರಿಗಣಿಸಿ.

4. ಎಂಡ್‌ಪಾಯಿಂಟ್/ಸಂಪನ್ಮೂಲದ ಮೂಲಕ

ವಿವರಣೆ: ವಿಭಿನ್ನ API ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು ವಿಭಿನ್ನ ಸಂಪನ್ಮೂಲ ಅಗತ್ಯತೆಗಳನ್ನು ಅಥವಾ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿರಬಹುದು. ನೀವು ಸಂಪನ್ಮೂಲ-ತೀವ್ರ ಅಥವಾ ಸೂಕ್ಷ್ಮ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಿಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ದರ ಮಿತಿಗಳನ್ನು ಅನ್ವಯಿಸಬಹುದು.

ಅನುಷ್ಠಾನದ ಪರಿಗಣನೆಗಳು:

• ವೆಚ್ಚ ವಿಶ್ಲೇಷಣೆ: ಪ್ರತಿ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನ ಗಣನಾತ್ಮಕ ವೆಚ್ಚವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.
• ಭದ್ರತೆ: ನಿರ್ಣಾಯಕ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು (ಉದಾ. ದೃಢೀಕರಣ, ಪಾವತಿ ಪ್ರಕ್ರಿಯೆ) ಕಠಿಣ ನಿಯಂತ್ರಣಗಳೊಂದಿಗೆ ರಕ್ಷಿಸಿ.

5. ಜಾಗತಿಕ ದರ ಮಿತಿ

ವಿವರಣೆ: ಒಳಬರುವ ಎಲ್ಲಾ ವಿನಂತಿಗಳಿಗೆ, ಅವುಗಳ ಮೂಲವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಅನ್ವಯಿಸಲಾದ ಜಾಗತಿಕ ಮಿತಿ. ಇದು ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯು ಮುಳುಗದಂತೆ ತಡೆಯಲು ಅಂತಿಮ ಸುರಕ್ಷತಾ ಜಾಲವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಅನುಷ್ಠಾನದ ಪರಿಗಣನೆಗಳು:

• ಆಕ್ರಮಣಕಾರಿ ಟ್ಯೂನಿಂಗ್: ಕಾನೂನುಬದ್ಧ ಟ್ರಾಫಿಕ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ ಜಾಗತಿಕ ಮಿತಿಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಹೊಂದಿಸಬೇಕಾಗಿದೆ.
• ವೀಕ್ಷಣೆ: ಜಾಗತಿಕ ಮಿತಿಗಳು ಯಾವಾಗ ಮತ್ತು ಏಕೆ ತಲುಪುತ್ತಿವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಕಟ ಮೇಲ್ವಿಚಾರಣೆ ಅಗತ್ಯ.

API ಗೇಟ್‌ವೇ ತಂತ್ರಜ್ಞಾನಗಳೊಂದಿಗೆ ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ

ಅನೇಕ ಆಧುನಿಕ API ಗೇಟ್‌ವೇ ಪರಿಹಾರಗಳು ಅಂತರ್ನಿರ್ಮಿತ ದರ ಮಿತಿ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೀಡುತ್ತವೆ. ಜನಪ್ರಿಯ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಹೇಗೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಇಲ್ಲಿ ನೋಡೋಣ:

1. Nginx ಜೊತೆಗೆ `ngx_http_limit_req_module`

Nginx ಒಂದು ಉನ್ನತ-ಕಾರ್ಯಕ್ಷಮತೆಯ ವೆಬ್ ಸರ್ವರ್ ಮತ್ತು ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯಾಗಿದ್ದು, ಇದನ್ನು API ಗೇಟ್‌ವೇ ಆಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. `ngx_http_limit_req_module` ಮಾಡ್ಯೂಲ್ ದರ ಮಿತಿ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ.

            # Example Nginx Configuration Snippet

http {
    # ... other configurations ...

    # Define rate limits using zone directive
    # zone=mylimit:10m rate=10r/s;
    #  - zone=mylimit: Zone name and shared memory zone size (10 megabytes)
    #  - rate=10r/s: Allow 10 requests per second
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/m;

    server {
        listen 80;

        location /api/v1/ { # Apply to all requests under /api/v1/
            limit_req zone=api_limit burst=20 nodelay;
            #  - zone=api_limit: Use the defined zone
            #  - burst=20: Allow a burst of 20 requests
            #  - nodelay: Don't delay requests, reject immediately if limit exceeded
            proxy_pass http://backend_services;
        }
    }
}

            

              
                Copy
              
            
          

ವಿವರಣೆ:

• limit_req_zone: ದರ ಮಿತಿಯ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಹಂಚಿಕೆಯ ಮೆಮೊರಿ ವಲಯವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. $binary_remote_addr ಎಂಬುದು ಕೀ, ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಲೈಂಟ್‌ನ IP ವಿಳಾಸ. rate=100r/m ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 100 ವಿನಂತಿಗಳ ಮಿತಿಯನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ.
• limit_req: location ಬ್ಲಾಕ್ ಒಳಗೆ ಅನ್ವಯಿಸಲಾಗಿದೆ. zone=api_limit ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ವಲಯವನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ. burst=20 ಸರಾಸರಿ ದರವನ್ನು ಮೀರಿ 20 ವಿನಂತಿಗಳ ಸ್ಫೋಟವನ್ನು ಅನುಮತಿಸುತ್ತದೆ. nodelay ಎಂದರೆ ಮಿತಿಯನ್ನು ಮೀರಿದ ವಿನಂತಿಗಳನ್ನು ತಕ್ಷಣವೇ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ (503 Service Unavailable ಹಿಂತಿರುಗಿಸುತ್ತದೆ). delay=... ಬಳಸುವುದರಿಂದ ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸುವ ಬದಲು ವಿಳಂಬಗೊಳಿಸುತ್ತದೆ.

2. Kong API ಗೇಟ್‌ವೇ

Kong ಎಂಬುದು Nginx ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಜನಪ್ರಿಯ ಓಪನ್-ಸೋರ್ಸ್ API ಗೇಟ್‌ವೇ. ಇದು ಪ್ಲಗಿನ್-ಆಧಾರಿತ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ನೀಡುತ್ತದೆ, ಇದರಲ್ಲಿ ದೃಢವಾದ ದರ ಮಿತಿ ಪ್ಲಗಿನ್ ಸೇರಿದೆ.

Kong Admin API ಮೂಲಕ ಕಾನ್ಫಿಗರೇಶನ್ (ಉದಾಹರಣೆ):

            # Create a rate limiting plugin configuration for a service
curl -X POST http://localhost:8001/plugins \
    --data "name=rate-limiting" \
    --data "service.id=YOUR_SERVICE_ID" \
    --data "config.minute=100" \
    --data "config.policy=local" \
    --data "config.limit_by=ip" \
    --data "config.error_message='You have exceeded the rate limit.'"

# Example using Lua script for more complex rules
# (This requires the 'lua-resty-limit-req' library or similar)

            

              
                Copy
              
            
          

ವಿವರಣೆ:

• name=rate-limiting: ದರ ಮಿತಿ ಪ್ಲಗಿನ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• service.id: ಈ ಪ್ಲಗಿನ್ ಅನ್ವಯವಾಗುವ ಸೇವೆಯ ID.
• config.minute=100: ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 100 ವಿನಂತಿಗಳ ಮಿತಿಯನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ.
• config.policy=local: ದರ ಮಿತಿಗಾಗಿ ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಯನ್ನು ಬಳಸುತ್ತದೆ (ಒಂದೇ Kong ನೋಡ್‌ಗಳಿಗೆ ಸೂಕ್ತ). ವಿತರಿಸಿದ ಸೆಟಪ್‌ಗಳಿಗಾಗಿ, redis ಒಂದು ಸಾಮಾನ್ಯ ಆಯ್ಕೆಯಾಗಿದೆ.
• config.limit_by=ip: ಕ್ಲೈಂಟ್‌ನ IP ವಿಳಾಸದ ಆಧಾರದ ಮೇಲೆ ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಇತರ ಆಯ್ಕೆಗಳು key-auth (API ಕೀ) ಅಥವಾ consumer ಅನ್ನು ಒಳಗೊಂಡಿವೆ.

Kong ನ ದರ ಮಿತಿ ಪ್ಲಗಿನ್ ಹೆಚ್ಚು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚು ಅತ್ಯಾಧುನಿಕ ಸನ್ನಿವೇಶಗಳಿಗಾಗಿ ಕಸ್ಟಮ್ Lua ತರ್ಕದೊಂದಿಗೆ ವಿಸ್ತರಿಸಬಹುದು.

3. Apigee (Google Cloud)

Apigee ತನ್ನ UI ಅಥವಾ API ಮೂಲಕ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಅತ್ಯಾಧುನಿಕ ದರ ಮಿತಿ ನೀತಿಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಸುಧಾರಿತ API ನಿರ್ವಹಣಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೀಡುತ್ತದೆ.

ಉದಾಹರಣೆ ನೀತಿ ಕಾನ್ಫಿಗರೇಶನ್ (ಪರಿಕಲ್ಪನಾತ್ಮಕ):

Apigee ಯಲ್ಲಿ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ API ಪ್ರಾಕ್ಸಿಯ ವಿನಂತಿ ಪ್ರವಾಹಕ್ಕೆ Spike Arrest ನೀತಿಯನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಈ ನೀತಿಯು ನಿಮಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲು ಅನುಮತಿಸುತ್ತದೆ:

• ಗರಿಷ್ಠ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ: ನಿರ್ದಿಷ್ಟ ಸಮಯದ ಅಂತರದಲ್ಲಿ ಅನುಮತಿಸಲಾದ ಒಟ್ಟು ವಿನಂತಿಗಳು.
• ಸಮಯದ ಅಂತರ: ಅಂತರದ ಅವಧಿ (ಉದಾ. ಪ್ರತಿ ನಿಮಿಷ, ಪ್ರತಿ ಗಂಟೆಗೆ).
• ವಿವರ: IP ವಿಳಾಸ, API ಕೀ, ಅಥವಾ ಬಳಕೆದಾರರ ಪ್ರಕಾರ ಮಿತಿಗಳನ್ನು ಅನ್ವಯಿಸಬೇಕೇ.
• ಉಲ್ಲಂಘನೆಯ ಮೇಲೆ ಕ್ರಮ: ಮಿತಿಯನ್ನು ಮೀರಿದಾಗ ಏನಾಗುತ್ತದೆ (ಉದಾ. ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸುವುದು, ವಿಭಿನ್ನ ಪ್ರವಾಹವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು).

Apigee Quota ನೀತಿಗಳನ್ನು ಸಹ ಬೆಂಬಲಿಸುತ್ತದೆ, ಇದು ಇದೇ ರೀತಿಯದ್ದಾಗಿದೆ ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ದೀರ್ಘಾವಧಿಯ ಬಳಕೆಯ ಟ್ರ್ಯಾಕಿಂಗ್‌ಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ (ಉದಾ. ಮಾಸಿಕ ಕೋಟಾಗಳು).

4. AWS API ಗೇಟ್‌ವೇ

AWS API ಗೇಟ್‌ವೇ ನಿಮಗೆ ಖಾತೆ ಮಟ್ಟದಲ್ಲಿ ಮತ್ತು API ಹಂತದ ಮಟ್ಟದಲ್ಲಿ ಥ್ರಾಟ್ಲಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ನೀವು ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ಮಿತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲು API ಕೀಗಳೊಂದಿಗೆ ಬಳಕೆಯ ಯೋಜನೆಗಳನ್ನು ಸಹ ಹೊಂದಿಸಬಹುದು.

AWS ಕನ್ಸೋಲ್ ಅಥವಾ SDK ಮೂಲಕ ಕಾನ್ಫಿಗರೇಶನ್:

• ಥ್ರಾಟ್ಲಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು: ಪ್ರತಿ API ಗೆ, ನೀವು ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಅನ್ವಯವಾಗುವ ಡೀಫಾಲ್ಟ್ ಥ್ರಾಟ್ಲಿಂಗ್ ಮಿತಿಗಳನ್ನು (ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳು ಮತ್ತು ಬರ್ಸ್ಟ್ ಮಿತಿ) ಹೊಂದಿಸಬಹುದು.
• ಬಳಕೆಯ ಯೋಜನೆಗಳು: ಒಂದು ಬಳಕೆಯ ಯೋಜನೆಯನ್ನು ರಚಿಸಿ, ದರ (ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳು) ಮತ್ತು ಬರ್ಸ್ಟ್ (ಏಕಕಾಲೀನತೆ) ಮಿತಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ, API ಕೀಗಳನ್ನು ಯೋಜನೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ, ತದನಂತರ ಬಳಕೆಯ ಯೋಜನೆಯನ್ನು API ಹಂತದೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ.

ಉದಾಹರಣೆ: ಒಂದು ಬಳಕೆಯ ಯೋಜನೆಯು ನಿರ್ದಿಷ್ಟ API ಕೀಗೆ ಸಂಬಂಧಿಸಿದಂತೆ 1000 ವಿನಂತಿಗಳ ಬರ್ಸ್ಟ್‌ನೊಂದಿಗೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಬಹುದು.

5. Azure API ನಿರ್ವಹಣೆ

Azure API ನಿರ್ವಹಣೆ (APIM) ನೀತಿಗಳ ಮೂಲಕ ದೃಢವಾದ ದರ ಮಿತಿ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಒಳಗೊಂಡಂತೆ API ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಮಗ್ರ ಸಾಧನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಉದಾಹರಣೆ ನೀತಿ ತುಣುಕು (XML):

            <policies>
    <inbound>
        <base />
        <rate-limit calls="100" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
        <!-- For API key based limiting: -->
        <!-- <rate-limit calls="1000" renewal-period="3600" counter-key="@(context.Subscription.Key)" /> -->
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
</policies>

            

              
                Copy
              
            
          

ವಿವರಣೆ:

• rate-limit: ನೀತಿಯೇ.
• calls="100": 100 ಕರೆಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
• renewal-period="60": 60-ಸೆಕೆಂಡುಗಳ ಅವಧಿಯೊಳಗೆ.
• counter-key="@(context.Request.IpAddress)": ವಿನಂತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಕ್ಲೈಂಟ್‌ನ IP ವಿಳಾಸವನ್ನು ಕೀಲಿಯಾಗಿ ಬಳಸುತ್ತದೆ. ನೀವು API ಕೀ-ಆಧಾರಿತ ಮಿತಿಗಾಗಿ context.Subscription.Key ನಂತಹ ಇತರ ಕೀಗಳನ್ನು ಬಳಸಬಹುದು.

ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ಸುಧಾರಿತ ದರ ಮಿತಿ ಪರಿಗಣನೆಗಳು

ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ದರ ಮಿತಿಯನ್ನು ಅಳವಡಿಸಲು ಹಲವಾರು ಅನನ್ಯ ಸವಾಲುಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ:

1. ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಲೇಟೆನ್ಸಿ

ವಿತರಿಸಿದ API ಗೇಟ್‌ವೇ ಸೆಟಪ್‌ನಲ್ಲಿ (ಉದಾ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಹಿಂದೆ ಅನೇಕ ಗೇಟ್‌ವೇ ನಿದರ್ಶನಗಳು, ಅಥವಾ ವಿವಿಧ ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳಲ್ಲಿ), ಸ್ಥಿರವಾದ ದರ ಮಿತಿ ಸ್ಥಿತಿಯನ್ನು ನಿರ್ವಹಿಸುವುದು ನಿರ್ಣಾಯಕ. Redis ಅಥವಾ ವಿತರಿಸಿದ ಡೇಟಾಬೇಸ್‌ನಂತಹ ಹಂಚಿಕೆಯ ಸಂಗ್ರಹವನ್ನು ಬಳಸುವುದು ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಲಾಗ್ ಅಥವಾ ಟೋಕನ್ ಬಕೆಟ್‌ನಂತಹ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಎಲ್ಲಾ ನಿದರ್ಶನಗಳಲ್ಲಿ ನಿಖರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅತ್ಯಗತ್ಯ.

2. ಭೂ-ವಿತರಿಸಿದ ಗೇಟ್‌ವೇಗಳು

ಜಾಗತಿಕ ಬಳಕೆದಾರರಿಗೆ ಲೇಟೆನ್ಸಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಅನೇಕ ಭೌಗೋಳಿಕ ಸ್ಥಳಗಳಲ್ಲಿ API ಗೇಟ್‌ವೇಗಳನ್ನು ನಿಯೋಜಿಸುವಾಗ, ಪ್ರತಿ ಗೇಟ್‌ವೇ ನಿದರ್ಶನಕ್ಕೆ ತನ್ನದೇ ಆದ ದರ ಮಿತಿ ಸಂದರ್ಭ ಬೇಕಾಗಬಹುದು, ಅಥವಾ ಅವರು ತಮ್ಮ ಮಿತಿಗಳನ್ನು ಜಾಗತಿಕವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕಾಗಬಹುದು. ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಹೆಚ್ಚಾಗಿ ಆದ್ಯತೆ ನೀಡಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಬಳಕೆದಾರರು ಪ್ರತಿಯೊಂದು ಪ್ರಾದೇಶಿಕ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಸ್ವತಂತ್ರವಾಗಿ ಮಿತಿಗಳನ್ನು ತಲುಪುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಇದು ಒಟ್ಟಾರೆ ಅತಿಯಾದ ಬಳಕೆಗೆ ಕಾರಣವಾಗಬಹುದು.

3. ಸಮಯ ವಲಯಗಳು ಮತ್ತು ಡೇಲೈಟ್ ಸೇವಿಂಗ್

ನಿಮ್ಮ ದರ ಮಿತಿ ನೀತಿಗಳು ಸಮಯ-ಆಧಾರಿತವಾಗಿದ್ದರೆ (ಉದಾ. ಪ್ರತಿ ದಿನ, ಪ್ರತಿ ವಾರ), ಜಗತ್ತಿನಾದ್ಯಂತ ವಿವಿಧ ಸ್ಥಳೀಯ ಸಮಯ ವಲಯಗಳು ಮತ್ತು ಡೇಲೈಟ್ ಸೇವಿಂಗ್ ಸಮಯ ಬದಲಾವಣೆಗಳಿಂದ ಉಂಟಾಗುವ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಅವುಗಳನ್ನು UTC ಅಥವಾ ಸ್ಥಿರ ಸಮಯ ವಲಯವನ್ನು ಬಳಸಿ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

4. ಕರೆನ್ಸಿ ಮತ್ತು ಬೆಲೆ ಶ್ರೇಣಿಗಳು

ಶ್ರೇಣೀಕೃತ ಪ್ರವೇಶ ಅಥವಾ ಹಣಗಳಿಕೆಯನ್ನು ನೀಡುವ API ಗಳಿಗೆ, ದರ ಮಿತಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನೇರವಾಗಿ ಬೆಲೆಗೆ ಸಂಬಂಧಿಸಿರುತ್ತವೆ. ವಿವಿಧ ಪ್ರದೇಶಗಳಲ್ಲಿ ಈ ಶ್ರೇಣಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸ್ಥಳೀಯ ಕರೆನ್ಸಿಗಳು, ಕೊಳ್ಳುವ ಶಕ್ತಿ ಮತ್ತು ಚಂದಾದಾರಿಕೆ ಮಾದರಿಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಪರಿಗಣಿಸಬೇಕಾಗುತ್ತದೆ. ನಿಮ್ಮ API ಗೇಟ್‌ವೇಯ ದರ ಮಿತಿ ಕಾನ್ಫಿಗರೇಶನ್ ಈ ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳುವಷ್ಟು ಹೊಂದಿಕೊಳ್ಳುವಂತಿರಬೇಕು.

5. ನೆಟ್ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳು ಮತ್ತು ಇಂಟರ್ನೆಟ್ ವ್ಯತ್ಯಾಸ

ವಿಶ್ವದ ವಿವಿಧ ಭಾಗಗಳ ಬಳಕೆದಾರರು ವಿಭಿನ್ನ ನೆಟ್ವರ್ಕ್ ವೇಗಗಳು ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಅನುಭವಿಸುತ್ತಾರೆ. ದರ ಮಿತಿಯು ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವುದರ ಬಗ್ಗೆಯಾಗಿದ್ದರೂ, ಇದು ಊಹಿಸಬಹುದಾದ ಸೇವೆಯನ್ನು ಒದಗಿಸುವುದರ ಬಗ್ಗೆಯೂ ಆಗಿದೆ. 429 Too Many Requests ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸುವುದು ನಿಧಾನಗತಿಯ ಸಂಪರ್ಕ ಹೊಂದಿರುವ ಬಳಕೆದಾರರಿಂದ ನೀತಿ ಜಾರಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಯೆಂದು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳಬಹುದು. ಸ್ಪಷ್ಟ ದೋಷ ಸಂದೇಶಗಳು ಮತ್ತು ಹೆಡರ್‌ಗಳು ಅತ್ಯಗತ್ಯ.

6. ಅಂತರರಾಷ್ಟ್ರೀಯ ನಿಯಮಗಳು ಮತ್ತು ಅನುಸರಣೆ

ನಿಮ್ಮ ಉದ್ಯಮ ಮತ್ತು ನೀವು ಸೇವೆ ಸಲ್ಲಿಸುವ ಪ್ರದೇಶಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಡೇಟಾ ಬಳಕೆ, ಗೌಪ್ಯತೆ ಮತ್ತು ನ್ಯಾಯಯುತ ಪ್ರವೇಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ನಿಯಮಗಳು ಇರಬಹುದು. ನಿಮ್ಮ ದರ ಮಿತಿ ತಂತ್ರಗಳು ಈ ಅನುಸರಣೆ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಅನುಗುಣವಾಗಿವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇ ದರ ಮಿತಿಯನ್ನು ಅಳವಡಿಸಲು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

ನಿಮ್ಮ ದರ ಮಿತಿ ಅನುಷ್ಠಾನದ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು, ಈ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಪರಿಗಣಿಸಿ:

• ಸರಳವಾಗಿ ಪ್ರಾರಂಭಿಸಿ, ಪುನರಾವರ್ತಿಸಿ: ಮೂಲಭೂತ ದರ ಮಿತಿಯೊಂದಿಗೆ (ಉದಾ. IP-ಆಧಾರಿತ) ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಮಾದರಿಗಳ ಬಗ್ಗೆ ನಿಮ್ಮ ತಿಳುವಳಿಕೆ ಬೆಳೆದಂತೆ ಕ್ರಮೇಣ ಹೆಚ್ಚು ಅತ್ಯಾಧುನಿಕ ನಿಯಮಗಳನ್ನು ಪರಿಚಯಿಸಿ.
• ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ ಮತ್ತು ವಿಶ್ಲೇಷಿಸಿ: ನಿಮ್ಮ API ಟ್ರಾಫಿಕ್ ಮತ್ತು ದರ ಮಿತಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ಯಾರು ಮಿತಿಗಳನ್ನು ತಲುಪುತ್ತಿದ್ದಾರೆ, ಏಕೆ, ಮತ್ತು ಯಾವ ದರದಲ್ಲಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಮಿತಿಗಳನ್ನು ಟ್ಯೂನ್ ಮಾಡಲು ಈ ಡೇಟಾವನ್ನು ಬಳಸಿ.
• ಮಾಹಿತಿಯುಕ್ತ ದೋಷ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಬಳಸಿ: ವಿನಂತಿಯನ್ನು ಥ್ರಾಟ್ಲ್ ಮಾಡಿದಾಗ, ಸ್ಪಷ್ಟ ಮತ್ತು ಮಾಹಿತಿಯುಕ್ತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸಿ, ಸಾಮಾನ್ಯವಾಗಿ HTTP ಸ್ಟೇಟಸ್ ಕೋಡ್ 429 Too Many Requests. ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಯಾವಾಗ ಮರುಪ್ರಯತ್ನಿಸಬಹುದೆಂದು ಹೇಳಲು Retry-After ನಂತಹ ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸಿ, ಮತ್ತು ಅವರ ಪ್ರಸ್ತುತ ಮಿತಿಗಳ ಬಗ್ಗೆ ಸಂದರ್ಭವನ್ನು ಒದಗಿಸಲು X-RateLimit-Limit, X-RateLimit-Remaining, ಮತ್ತು X-RateLimit-Reset ಅನ್ನು ಸೇರಿಸಬಹುದು.
• ಜಾಗತಿಕ ಮತ್ತು ಸೂಕ್ಷ್ಮ ಮಿತಿಗಳನ್ನು ಅಳವಡಿಸಿ: ಉತ್ತಮ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ಜಾಗತಿಕ ದರ ಮಿತಿಯನ್ನು ಫೇಲ್‌ಸೇಫ್ ಆಗಿ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಮಿತಿಗಳೊಂದಿಗೆ (ಪ್ರತಿ ಬಳಕೆದಾರ, ಪ್ರತಿ API ಕೀ, ಪ್ರತಿ ಎಂಡ್‌ಪಾಯಿಂಟ್) ಸಂಯೋಜಿಸಿ.
• ಬರ್ಸ್ಟ್ ಸಾಮರ್ಥ್ಯವನ್ನು ಪರಿಗಣಿಸಿ: ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ನಿಯಂತ್ರಿತ ವಿನಂತಿಗಳ ಸ್ಫೋಟವನ್ನು ಅನುಮತಿಸುವುದು ಬ್ಯಾಕೆಂಡ್ ಸ್ಥಿರತೆಯ ಮೇಲೆ ಗಮನಾರ್ಹವಾಗಿ ಪರಿಣಾಮ ಬೀರದೆ ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಸುಧಾರಿಸಬಹುದು. ಬರ್ಸ್ಟ್ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಟ್ಯೂನ್ ಮಾಡಿ.
• ಸರಿಯಾದ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ: ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಅಗತ್ಯಗಳಿಗಾಗಿ ನಿಖರತೆ, ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಸಮತೋಲನಗೊಳಿಸುವ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. ಟೋಕನ್ ಬಕೆಟ್ ಮತ್ತು ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಲಾಗ್ ಅತ್ಯಾಧುನಿಕ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ಉತ್ತಮ ಆಯ್ಕೆಗಳಾಗಿವೆ.
• ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಿ: ನಿಮ್ಮ ದರ ಮಿತಿಯು ನಿರೀಕ್ಷೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಕಾನೂನುಬದ್ಧ ಬಳಕೆದಾರರನ್ನು ಅಜಾಗರೂಕತೆಯಿಂದ ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಸನ್ನಿವೇಶಗಳು ಮತ್ತು ಎಡ್ಜ್ ಕೇಸ್‌ಗಳನ್ನು ಅನುಕರಿಸಿ.
• ನಿಮ್ಮ ಮಿತಿಗಳನ್ನು ದಾಖಲಿಸಿ: ಗ್ರಾಹಕರಿಗಾಗಿ ನಿಮ್ಮ API ದರ ಮಿತಿಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದಾಖಲಿಸಿ. ಇದು ಅವರ ಬಳಕೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ಥ್ರಾಟ್ಲಿಂಗ್ ಅನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
• ಎಚ್ಚರಿಕೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ: ದರ ಮಿತಿಗಳನ್ನು ಆಗಾಗ್ಗೆ ತಲುಪಿದಾಗ ಅಥವಾ ಥ್ರಾಟ್ಲ್ ಮಾಡಿದ ವಿನಂತಿಗಳಲ್ಲಿ ಹಠಾತ್ ಏರಿಕೆಗಳಾದಾಗ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹೊಂದಿಸಿ.

ವೀಕ್ಷಣೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ

ಪರಿಣಾಮಕಾರಿ ದರ ಮಿತಿಯು ವೀಕ್ಷಣೆಯೊಂದಿಗೆ ಆಳವಾಗಿ ಹೆಣೆದುಕೊಂಡಿದೆ. ನಿಮಗೆ ಈ ಕೆಳಗಿನವುಗಳ ಬಗ್ಗೆ ದೃಷ್ಟಿ ಬೇಕು:

• ವಿನಂತಿ ಪ್ರಮಾಣ: ನಿಮ್ಮ API ಮತ್ತು ಅದರ ವಿವಿಧ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಿಗೆ ಒಟ್ಟು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.
• ಥ್ರಾಟ್ಲ್ ಮಾಡಿದ ವಿನಂತಿಗಳು: ದರ ಮಿತಿಗಳಿಂದಾಗಿ ಎಷ್ಟು ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತಿದೆ ಅಥವಾ ವಿಳಂಬಗೊಳಿಸಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ.
• ಮಿತಿ ಬಳಕೆ: ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮ ನಿಗದಿತ ಮಿತಿಗಳನ್ನು ತಲುಪಲು ಎಷ್ಟು ಹತ್ತಿರದಲ್ಲಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.
• ದೋಷ ದರಗಳು: ದರ ಮಿತಿ ಘಟನೆಗಳನ್ನು ಒಟ್ಟಾರೆ API ದೋಷ ದರಗಳೊಂದಿಗೆ ಪರಸ್ಪರ ಸಂಬಂಧಿಸಿ.
• ಕ್ಲೈಂಟ್ ನಡವಳಿಕೆ: ನಿರಂತರವಾಗಿ ದರ ಮಿತಿಗಳನ್ನು ತಲುಪುತ್ತಿರುವ ಕ್ಲೈಂಟ್‌ಗಳು ಅಥವಾ IP ವಿಳಾಸಗಳನ್ನು ಗುರುತಿಸಿ.

Prometheus, Grafana, ELK ಸ್ಟಾಕ್ (Elasticsearch, Logstash, Kibana), Datadog, ಅಥವಾ ಕ್ಲೌಡ್-ನಿರ್ದಿಷ್ಟ ಮೇಲ್ವಿಚಾರಣಾ ಪರಿಹಾರಗಳು (CloudWatch, Azure Monitor, Google Cloud Monitoring) ನಂತಹ ಸಾಧನಗಳು ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು, ದೃಶ್ಯೀಕರಿಸಲು ಮತ್ತು ಎಚ್ಚರಿಸಲು ಅಮೂಲ್ಯವಾಗಿವೆ. ನಿಮ್ಮ API ಗೇಟ್‌ವೇ ಥ್ರಾಟ್ಲ್ ಮಾಡಿದ ವಿನಂತಿಗಳ ಬಗ್ಗೆ, ಕಾರಣ ಮತ್ತು ಕ್ಲೈಂಟ್ ಐಡೆಂಟಿಫೈಯರ್ ಸೇರಿದಂತೆ ವಿವರವಾದ ಮಾಹಿತಿಯನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ತೀರ್ಮಾನ

ಫ್ರಂಟ್ಎಂಡ್ API ಗೇಟ್‌ವೇ ದರ ಮಿತಿಯು ಕೇವಲ ಭದ್ರತಾ ವೈಶಿಷ್ಟ್ಯವಲ್ಲ; ಇದು ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ದೃಢವಾದ, ಸ್ಕೇಲೆಬಲ್, ಮತ್ತು ಬಳಕೆದಾರ-ಸ್ನೇಹಿ API ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಮೂಲಭೂತ ಅಂಶವಾಗಿದೆ. ಸೂಕ್ತವಾದ ದರ ಮಿತಿ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಆಯ್ಕೆ ಮಾಡುವ ಮೂಲಕ, ಅವುಗಳನ್ನು ಗೇಟ್‌ವೇ ಲೇಯರ್‌ನಲ್ಲಿ ಕಾರ್ಯತಂತ್ರವಾಗಿ ಅಳವಡಿಸುವ ಮೂಲಕ, ಮತ್ತು ಅವುಗಳ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮೂಲಕ, ನೀವು ನಿಮ್ಮ ಸೇವೆಗಳನ್ನು ದುರುಪಯೋಗದಿಂದ ರಕ್ಷಿಸಬಹುದು, ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ನ್ಯಾಯಯುತ ಪ್ರವೇಶವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು, ಮತ್ತು ಉನ್ನತ ಮಟ್ಟದ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಲಭ್ಯತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಬಹುದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ವಿಕಸನಗೊಂಡಂತೆ ಮತ್ತು ಅದರ ಬಳಕೆದಾರರ ನೆಲೆಯು ವೈವಿಧ್ಯಮಯ ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳು ಮತ್ತು ತಾಂತ್ರಿಕ ಪರಿಸರಗಳಲ್ಲಿ ವಿಸ್ತರಿಸಿದಂತೆ, ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ದರ ಮಿತಿ ತಂತ್ರವು ನಿಮ್ಮ API ನಿರ್ವಹಣಾ ಯಶಸ್ಸಿನ ಮೂಲಾಧಾರವಾಗಿರುತ್ತದೆ.