הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
תכונות של נתונים קבועים ב-Apigee כוללות מטמונים, מפות מפתח-ערך וקבוצות מאפיינים. אם אתם משתמשים ב-Apigee hybrid, אתם יכולים להשתמש בסודות של Kubernetes כדי לשמור נתונים רגישים.
| תכונה | שימוש |
|---|---|
| קובצי מטמון | באמצעות מדיניות לשמירה במטמון למטרות כלליות, אפשר לשמור אובייקטים שהפרוקסי צריך בכמה סשנים של בקשות ותגובות. אפשר גם לשמור במטמון את התגובה של משאב בקצה העורפי באמצעות
ResponseCache מדיניות. שמירת תגובות במטמון מועילה במיוחד כשנתוני ה-backend מתעדכנים רק מדי פעם. המדיניות ResponseCache יכולה להפחית את מספר הקריאות למקורות נתונים בעורף. |
| מפות של ערכי מפתח | מיפויים של צמדי מפתח/ערך (KVM) מספקים מאגר כללי של נתונים בזמן ריצה, שיכולים להשתנות מעת לעת. לדוגמה: נתוני סשן של משתמשים, עגלת קניות וכו'. אפשר להצפין רשומות של KVM. |
| קבוצות נכסים | קבוצות מאפיינים מתאימות לאחסון נתוני הגדרה שלא משתנים לעיתים קרובות. |
| סודות של Kubernetes | (Apigee hybrid בלבד) אפשר להשתמש ב-Secrets כדי לאחסן מידע אישי רגיש כמו פרטי כניסה של משתמשים. |
שמירה במטמון
משאבי מטמון בהיקף סביבה נוצרים באופן דינמי כשמדיניות מטמון מופעלת בתהליך של proxy ל-API. מדיניות המטמון כוללת את המדיניות PopulateCache, המדיניות LookupCache, המדיניות InvalidateCache והמדיניות ResponseCache.
פריט שנשמר במטמון נשאר בזיכרון (L1) למשך שנייה אחת. אי אפשר לשנות את ההגדרה הזו. אחרי שנייה אחת, האובייקט שנשמר במטמון ממוקם במסד נתונים (L2) שבו הוא זמין עד שתוקף המטמון פג. פרטים נוספים זמינים במאמר בנושא רמות של מטמון קבוע בזיכרון. אתם יכולים לנהל את פרטי המטמון, כמו זמן התפוגה, באמצעות הגדרה של מדיניות מטמון. יש API של Apigee שמאפשר לרשום ולמחוק משאבי מטמון.
כשמשתמשים במדיניות מטמון, צריך להגדיר מפתחות מטמון כדי לוודא שהמפתחות של הערכים במטמון הם ייחודיים. מפתח מטמון, יחד עם ערכים אחרים שאפשר להגדיר, מאפשר לכם לקבל את אותם נתונים שהזנתם. גודל המטמון והזמינות שלו כפופים למגבלות מסוימות.
כדאי להשתמש במטמון כדי:
- הפחתת זמן האחזור והתנועה. הבקשות נענות תוך זמן קצר יותר, ונעשה שימוש חוזר בייצוגים.
- שמירת נתונים בין עסקאות. אפשר לאחסן נתוני סשנים לשימוש חוזר בעסקאות HTTP.
- תמיכה באבטחה. הגבלת הגישה לרשומות במטמון כך שאפשר יהיה לגשת אליהן רק בסביבה מסוימת או באמצעות שרת proxy ספציפי של API.
Backend response caching
אפשר לשמור במטמון את התגובה של משאב בקצה העורפי באמצעות המדיניות ResponseCache.
האפשרות הזו שימושית במיוחד כשנתוני ה-Backend מתעדכנים רק מדי פעם. המדיניות ResponseCache
יכולה לצמצם את הקריאות למקורות נתוני ה-Backend.
באמצעות מדיניות ResponseCache, אפשר גם להגדיר ש-Apigee יבדוק כותרות מסוימות של מטמון תגובות HTTP ויבצע פעולות בהתאם להנחיות של הכותרות. לדוגמה, בתגובות מיעדי קצה בעורף המערכת, Apigee תומך בכותרת Cache-Control. אפשר להשתמש בכותרת הזו כדי לשלוט, בין היתר, בפרק הזמן המקסימלי שבו תגובה יכולה להישמר במטמון. מידע נוסף זמין במאמר בנושא תמיכה בכותרות של תגובות HTTP.
שמירה במטמון לטווח קצר לשימוש כללי
באמצעות מדיניות לשמירה במטמון למטרות כלליות, אפשר לשמור אובייקטים שהפרוקסי צריך בכמה סשנים של בקשות ותגובות.
בעזרת PopulateCache
policy, LookupCache
policy ו-InvalidateCache policy, אפשר לאכלס נתונים במטמון, לאחזר אותם ולרוקן מידע (Flush) את המטמון בזמן ריצה.
לדוגמה, יכול להיות שתאחסנו באופן זמני:
- מזהי סשנים לניהול סשנים.
- פרטי כניסה לקריאות יוצאות (כמו מפתחות API או אסימוני גישה של OAuth).
- תוכן התשובה שצריך להיות מחולק לדפים באפליקציות.
בזמן הריצה, מדיניות המטמון מעתיקה ערכים בין משתני ה-proxy לבין המטמון המוגדר שאתם מציינים. כשמציבים ערך במטמון, הוא מועתק מהמשתנה שציינתם למטמון. כשמאחזרים אותו מהמטמון, הוא מועתק למשתנה לשימוש על ידי ה-proxy.
דוגמה עם קוד מופיעה במאמר דוגמה: שמירת נתונים במטמון לשימוש כללי.
ניהול מטמון באמצעות Apigee API
אפשר להשתמש ב-caches API כדי להציג רשימה של מטמונים ולמחוק אותם.
שמירה לטווח ארוך באמצעות מפות מפתח/ערך (KVM)
כדי לאחסן נתונים מובְנים ללא הגבלת זמן, מוצפנים או לא מוצפנים, אתם יכולים ליצור מפות של צמדי מפתח/ערך (KVM) ולמלא אותן בצמדי מפתח/ערך שרירותיים. לדוגמה, יכול להיות שתאחסנו:
- מפה שיוצרת קורלציה בין כתובות IP לקודי מדינות.
- רשימה של כתובות IP שניתנה להן גישה או שנמנעה מהן גישה.
- מיפוי שבו כתובות URL ארוכות משויכות לכתובות URL מקוצרות.
- נתונים ספציפיים לסביבה, כמו מכסות וזמני תפוגה של טוקנים של OAuth.
ל-KVM יכול להיות אחד משלושת ההיקפים הבאים: organization, environment, apiproxy. לדוגמה, אם רוצים להשתמש בצמדי מפתח/ערך בכל ממשקי ה-API בארגון, צריך ליצור KVM בהיקף הארגון. אם רוצים שרק ל-proxy ל-API ספציפי תהיה גישה למפתחות ולערכים, צריך ליצור את ה-KVM בהיקף ה-apiproxy. מידע נוסף זמין במאמר בנושא עבודה עם מפות של זוגות מפתח/ערך.
קבוצות נכסים
קבוצת נכסים היא אוסף מותאם אישית של צמדי מפתח/ערך שמאחסנים נתונים. פרוקסי של API יכולים לאחזר את הנתונים האלה כשהם מופעלים.
בדרך כלל, משתמשים בקבוצות נכסים כדי לאחסן נתונים שלא פג תוקפם ושלא צריך לקודד אותם באופן קשיח בלוגיקה של proxy ל-API, כמו נתוני הגדרה. אפשר לגשת לנתונים של קבוצת נכסים בכל מקום בשרת proxy שבו יש גישה למשתני זרימה.
תרחיש נפוץ לשימוש בקבוצות נכסים הוא אספקת ערכים שמשויכים לסביבה אחת או אחרת. לדוגמה, אפשר ליצור קבוצת מאפיינים בהיקף סביבה עם ערכי תצורה שספציפיים לשרתי proxy שפועלים בסביבת הבדיקה, ועוד קבוצה לסביבת הייצור.
מידע נוסף מפורט במאמר בנושא שימוש בקבוצות מאפיינים.
סודות של Kubernetes
(רק ב-Apigee hybrid) אם אתם כבר משתמשים ב-Kubernetes לניהול סודות בכספת מותאמת אישית לנתונים רגישים, כדאי לשקול להשתמש ב-Kubernetes Secrets. בדומה לנתוני KVM, אפשר לגשת לנתוני הסוד של Kubernetes במשתני זרימה של שרת proxy ל-API. מידע נוסף זמין במאמר בנושא אחסון נתונים בסוד של Kubernetes.