מיקומי ענן פונקציות

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

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

אזורים נתמכים

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

פונקציות ענן זמינות באזורים הבאים עם תמחור שכבה 1 :

• asia-east1 (טייוואן)
• asia-east2 (הונג קונג) דור ראשון בלבד
• asia-northeast1 (טוקיו)
• asia-northeast2 (אוסקה)
• europe-north1 (פינלנד) energy_savings_leaf דור שני בלבד
• europe-west1 (בלגיה) עלה_חיסכון באנרגיה
• europe-west2 (לונדון) דור ראשון בלבד
• us-central1 (איווה) energy_savings_leaf
• us-east1 (דרום קרולינה)
• us-east4 (צפון וירג'יניה)
• us-west1 (Oregon) energy_savings_leaf

פונקציות ענן זמינות באזורים הבאים עם תמחור שכבה 2 :

• asia-east2 (הונג קונג) דור שני בלבד
• asia-northeast3 (סיאול)
• asia-southeast1 (סינגפור)
• asia-southeast2 (ג'קרטה)
• asia-south1 (מומביי) דור שני בלבד
• australia-southeast1 (סידני)
• australia-southeast2 (מלבורן) דור שני בלבד
• europe-central2 (ורשה)
• europe-west2 (לונדון) דור שני בלבד
• europe-west3 (פרנקפורט)
• europe-west6 (ציריך) עלה_חיסכון_אנרגיה
• northamerica-northeast1 (מונטריאול) עלה_חיסכון באנרגיה
• northamerica-northeast2 (טורונטו) energy_savings_leaf דור שני בלבד
• southamerica-east1 (סאו פאולו) עלה_חיסכון באנרגיה
• southamerica-west1 (סנטיאגו, צ'ילה) דור שני בלבד
• us-west2 (לוס אנג'לס)
• us-west3 (סולט לייק סיטי)
• us-west4 (לאס וגאס)

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

שיטות עבודה מומלצות לציון אזור

כברירת מחדל, פונקציות פועלות באזור us-central1 . שים לב שזה עשוי להיות שונה מהאזור של מקור אירוע, כגון דלי של Cloud Storage. אם עליך לציין את האזור שבו פועלת פונקציה, עקוב אחר ההמלצות בסעיף זה עבור כל סוג מפעיל פונקציה.

כדי להגדיר את האזור שבו פועלת פונקציה, הגדר את פרמטר region בהגדרת הפונקציה כפי שמוצג:

exports.firestoreAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

אתה יכול לציין אזורים מרובים על ידי העברת מחרוזות אזורים מרובות המופרדות בפסיק region . כמו כן, שים לב שכאשר מציינים אזור עבור סוגי טריגרים רבים ברקע, תצטרך לציין את מסנן האירועים הנכון יחד עם האזור. בדוגמה למעלה, זהו document Cloud Firestore שפולט את האירוע. עבור טריגר של Cloud Storage, מסנן האירועים יכול להיות bucket ; עבור מפעיל Pub/Sub זה יהיה topic , וכן הלאה.

ראה שינוי אזור של פונקציה למידע נוסף על שינוי האזור עבור פונקציה שמטפלת בתעבורת ייצור.

HTTP ופונקציות הניתנות להתקשרות עם הלקוח

עבור HTTP ופונקציות הניתנות להתקשרות, אנו ממליצים תחילה להגדיר את הפונקציה שלך לאזור היעד, או הקרוב ביותר למקום שבו נמצאים רוב הלקוחות הצפויים, ולאחר מכן לשנות את הפונקציה המקורית שלך כדי לנתב מחדש את בקשת ה-HTTP שלה לפונקציה החדשה (יכול להיות להם אותו הדבר שֵׁם). אם לקוחות של פונקציית ה-HTTP שלך תומכים בהפניות מחדש, אתה יכול פשוט לשנות את הפונקציה המקורית שלך כדי להחזיר סטטוס הפניית HTTP (301) יחד עם כתובת האתר של הפונקציה החדשה שלך. אם הלקוחות שלך לא מטפלים היטב בהפניות מחדש, אתה יכול לשלוח את הבקשה מהפונקציה המקורית לפונקציה החדשה על ידי הפעלת בקשה חדשה מהפונקציה המקורית לפונקציה החדשה. השלב האחרון הוא לוודא שכל הלקוחות מתקשרים לפונקציה החדשה.

בחירת מיקום בצד הלקוח עבור פונקציות הניתנות להתקשרות

לגבי הפונקציה הניתנת להתקשרות, הגדרות הניתנות להתקשרות על ידי הלקוח צריכות לפעול לפי אותן הנחיות כמו פונקציות HTTP. הלקוח יכול גם לציין אזור, ועליו לעשות זאת אם הפונקציה פועלת באזור כלשהו מלבד us-central1 .

כדי להגדיר אזורים בלקוח, ציין את האזור הרצוי באתחול:

lazy var functions = Functions.functions(region:"europe-west1")

@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];

var functions = firebase.app().functions('europe-west1');

private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");

firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");

firebase.Functions.FirebaseFunctions functions;

functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");

פונקציות רקע

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

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

ההמלצות האזוריות האופטימליות שונות לפי סוג הפעלת האירוע:

בחירת אזורים על סמך מיקומי Cloud Firestore ו-Cloud Storage

האזורים הזמינים עבור פונקציות לא תמיד תואמים במדויק לאזורים הזמינים עבור מסד הנתונים שלך ב-Cloud Firestore ודלי ה-Cloud Storage שלך.

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

הנה מיפוי של האזורים הנתמכים בפונקציות הקרובות ביותר עבור Cloud Firestore ו-Cloud Storage, למקרים שבהם אותו אזור אינו נתמך: