סקירה כללית על שמירה במטמון ועל התמדה

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

תכונות של שמירת נתונים ב-Apigee כוללות מטמונים, מפות מפתח-ערך וקבוצות מאפיינים. אם אתם משתמשים ב-Apigee hybrid, אתם יכולים להשתמש בסודות של Kubernetes כדי לשמור נתונים רגישים.

תכונה	שימוש
קובצי מטמון	באמצעות מדיניות לשמירה במטמון למטרות כלליות, אפשר לשמור אובייקטים שהפרוקסי צריך בכמה סשנים של בקשות ותגובות. אפשר גם לשמור במטמון את התגובה של משאב בקצה העורפי באמצעות מדיניות ResponseCache. שמירת תשובות במטמון מועילה במיוחד כשנתוני ה-Backend מתעדכנים רק מדי פעם. המדיניות ResponseCache יכולה להפחית את מספר הקריאות למקורות נתונים בעורף המערכת.
מפות של ערכי מפתח	מיפויים של זוגות מפתח/ערך (KVM) מספקים מאגר כללי של נתונים בזמן ריצה, שיכולים להשתנות מעת לעת. לדוגמה: נתוני סשן של משתמשים, עגלת קניות וכו'. אפשר להצפין רשומות KVM.
קבוצות נכסים	קבוצות מאפיינים מתאימות לאחסון נתוני הגדרה שלא משתנים לעיתים קרובות.
סודות ב-Kubernetes	(Apigee Hybrid בלבד) אפשר להשתמש בסודות כדי לאחסן מידע אישי רגיש כמו פרטי כניסה של משתמשים.

שמירה במטמון

משאבי מטמון בהיקף סביבה נוצרים באופן דינמי כשמדיניות מטמון מופעלת בתהליך של proxy ל-API. מדיניות המטמון כוללת את המדיניות PopulateCache,‏ המדיניות LookupCache,‏ המדיניות InvalidateCache והמדיניות ResponseCache.

פריט שנשמר במטמון נשאר בזיכרון (L1) למשך שנייה אחת. אי אפשר לשנות את ההגדרה הזו. אחרי שנייה אחת, האובייקט שנשמר במטמון ממוקם במסד נתונים (L2) שבו הוא זמין עד שהתוקף של המטמון פג. פרטים נוספים זמינים במאמר בנושא רמות של מטמון קבוע בזיכרון. אתם מנהלים את פרטי המטמון, כמו מועד תפוגה, באמצעות הגדרת מדיניות מטמון. יש API של Apigee שמאפשר לרשום ולמחוק משאבי מטמון.

כשמשתמשים במדיניות מטמון, צריך להגדיר מפתחות מטמון כדי לוודא שהמפתחות של הערכים במטמון הם ייחודיים. מפתח מטמון, יחד עם ערכים אחרים שאפשר להגדיר, מאפשר לכם לקבל את אותם נתונים שהזנתם. גודל המטמון והזמינות שלו כפופים למגבלות מסוימות.

כדאי להשתמש במטמון כדי:

• הפחתת זמן האחזור והתנועה. הבקשות נענות בזמן קצר יותר, ועם ייצוגים שעברו שימוש חוזר.
• שמירת נתונים בין עסקאות. אפשר לאחסן נתוני סשן לשימוש חוזר בעסקאות HTTP.
• תמיכה באבטחה. הגבלת הגישה לרשומות במטמון כך שניתן לגשת אליהן רק בסביבה מסוימת או באמצעות proxy ספציפי ל-API.

שמירת תשובות במטמון של ה-Backend

אפשר לשמור במטמון את התגובה של משאב בקצה העורפי באמצעות מדיניות ResponseCache.

האפשרות הזו שימושית במיוחד אם הנתונים בשרת העורפי מתעדכנים רק מדי פעם. המדיניות ResponseCache יכולה להפחית את מספר הקריאות למקורות נתונים בעורף.

באמצעות מדיניות ResponseCache, אפשר גם להגדיר ש-Apigee יבדוק כותרות מסוימות של תגובות HTTP שמאוחסנות במטמון ויבצע פעולות בהתאם להנחיות של הכותרות. לדוגמה, בתגובות מיעדי קצה בעורף המערכת, Apigee תומך בכותרת Cache-Control. אפשר להשתמש בכותרת הזו כדי לשלוט, בין היתר, בפרק הזמן המקסימלי שבו תגובה יכולה להישמר במטמון. מידע נוסף זמין במאמר בנושא תמיכה בכותרות של תגובות HTTP.

שמירה במטמון לשימוש כללי לטווח קצר

באמצעות מדיניות לשמירה במטמון לשימוש כללי, אפשר לשמור אובייקטים שהפרוקסי צריך בכמה סשנים של בקשות ותגובות.

בעזרת המדיניות PopulateCache, המדיניות LookupCache והמדיניות InvalidateCache, אפשר לאכלס נתונים שנשמרו במטמון, לאחזר אותם ולנקות את המטמון בזמן הריצה.

לדוגמה, יכול להיות שתאחסנו באופן זמני:

• מזהי סשנים לניהול סשנים.
• פרטי כניסה לקריאות יוצאות (כמו מפתחות 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 שבו יש גישה למשתני זרימה.

תרחיש נפוץ לשימוש בקבוצות נכסים הוא לספק ערכים שמשויכים לסביבה אחת או אחרת. לדוגמה, אפשר ליצור קבוצת מאפיינים בהיקף סביבה עם ערכי תצורה שספציפיים לפרוקסי שפועלים בסביבת הבדיקה, ועוד קבוצה לסביבת הייצור.

מידע נוסף מופיע במאמר בנושא שימוש בקבוצות מאפיינים.

סודות ב-Kubernetes

(Apigee hybrid בלבד) אם אתם כבר משתמשים ב-Kubernetes לניהול סודות בכספת מותאמת אישית לנתונים רגישים, כדאי לשקול שימוש ב-Kubernetes Secrets. בדומה לנתוני KVM, אפשר לגשת לנתוני הסוד של Kubernetes במשתני זרימה של שרת proxy ל-API. מידע נוסף זמין במאמר בנושא אחסון נתונים בסוד של Kubernetes.