Cloud Functions منطقه ای است، به این معنی که زیرساختی که عملکرد شما را اجرا می کند در مناطق خاصی قرار دارد و توسط Google مدیریت می شود تا به طور اضافی در همه مناطق در آن مناطق در دسترس باشد.
هنگام انتخاب مناطقی که توابع خود را در چه مناطقی اجرا کنید، ملاحظات اصلی شما باید تأخیر و در دسترس بودن باشد. به طور کلی می توانید مناطق نزدیک به کاربران خود را انتخاب کنید، اما باید مکان محصولات و خدمات دیگری را که برنامه شما استفاده می کند نیز در نظر بگیرید. استفاده از خدمات در چندین منطقه میتواند بر تأخیر برنامه شما و همچنین قیمتگذاری تأثیر بگذارد.
به طور پیش فرض، توابع در منطقه us-central1
اجرا می شوند. توجه داشته باشید که این ممکن است با منطقه یک منبع رویداد، مانند یک سطل Cloud Storage متفاوت باشد. نحوه تعیین منطقه ای که یک تابع در آن اجرا می شود را در ادامه این صفحه بیاموزید.
مناطق پشتیبانی شده
در لیستهای این بخش، نماد انرژی_صرفهجویی_برگ نشان میدهد که برق این منطقه با انتشار کربن کم تولید میشود. برای اطلاعات بیشتر، انرژی بدون کربن برای مناطق Google Cloud را ببینید.
Cloud Functions در مناطق زیر با قیمت سطح 1 در دسترس است:
-
asia-east1
(تایوان) -
asia-east2
(هنگ کنگ) فقط نسل اول -
asia-northeast1
(توکیو) -
asia-northeast2
(اوزاکا) -
europe-north1
(فنلاند) فقط انرژی_صرفهجویی_برگ نسل دوم -
europe-west1
(بلژیک) Energy_savings_leaf -
europe-west2
(لندن) فقط نسل اول -
us-central1
(آیووا) Energy_savings_leaf -
us-east1
(کارولینای جنوبی) -
us-east4
(ویرجینیای شمالی) -
us-west1
(اورگان) Energy_savings_leaf
Cloud Functions در مناطق زیر با قیمت گذاری سطح 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
(تورنتو) انرژی_صرفهجویی_برگ فقط نسل دوم -
southamerica-east1
(Sao Paulo) Energy_savings_leaf -
southamerica-west1
(سانتیاگو، شیلی) فقط نسل دوم -
us-west2
(لس آنجلس) -
us-west3
(سالت لیک سیتی) -
us-west4
(لاس وگاس)
توابع در یک منطقه معین در یک پروژه معین باید دارای نامهای منحصربهفرد (غیرحساس به حروف کوچک) باشند، اما توابع در سراسر مناطق یا پروژهها ممکن است نام یکسانی داشته باشند.
بهترین روش ها برای تعیین یک منطقه
به طور پیش فرض، توابع در منطقه us-central1
اجرا می شوند. توجه داشته باشید که این ممکن است با منطقه یک منبع رویداد، مانند یک سطل Cloud Storage متفاوت باشد. اگر میخواهید منطقهای را که یک تابع در آن اجرا میشود مشخص کنید، توصیههای این بخش را برای هر نوع راهانداز عملکرد دنبال کنید.
برای تنظیم منطقه ای که یک تابع در آن اجرا می شود، پارامتر region
را در تعریف تابع مطابق شکل تنظیم کنید:
Node.js
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) همراه با URL تابع جدید خود را بازگردانید. اگر مشتریان شما ریدایرکتها را به خوبی انجام نمیدهند، میتوانید با شروع یک درخواست جدید از تابع اصلی به تابع جدید، درخواست را از تابع اصلی به تابع جدید پراکسی کنید . مرحله آخر این است که اطمینان حاصل شود که همه مشتریان در حال فراخوانی تابع جدید هستند.
انتخاب مکان سمت مشتری برای توابع قابل فراخوانی
با توجه به تابع قابل فراخوانی، تنظیمات قابل فراخوانی مشتری باید از دستورالعمل های مشابه توابع HTTP پیروی کنند. کلاینت همچنین می تواند یک منطقه را مشخص کند، و اگر تابع در هر منطقه ای غیر از us-central1
اجرا شود باید این کار را انجام دهد.
برای تنظیم مناطق روی مشتری، منطقه مورد نظر را در زمان اولیه مشخص کنید:
سویفت
lazy var functions = Functions.functions(region:"europe-west1")
هدف-C
@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");
C++
firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");
وحدت
firebase.Functions.FirebaseFunctions functions;
functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");
توابع پس زمینه
توابع پس زمینه حداقل یک بار معنایی تحویل رویداد را اتخاذ می کنند، به این معنی که تحت برخی شرایط ممکن است رویدادهای تکراری دریافت کنند. بنابراین، شما باید توابع را پیاده سازی کنید تا ناتوان باشید. اگر عملکرد شما از قبل ضعیف است، میتوانید تابع را در منطقه جدید با همان راهانداز رویداد مجدداً مستقر کنید و پس از تأیید اینکه عملکرد جدید به درستی ترافیک دریافت میکند، عملکرد قدیمی را حذف کنید. در طول این انتقال، هر دو تابع رویدادها را دریافت خواهند کرد. برای دنباله دستورات توصیه شده برای تغییر ناحیه برای توابع، تغییر ناحیه یک تابع را ببینید.
اگر عملکرد شما در حال حاضر idempotent نیست، یا عدم توانایی آن فراتر از منطقه گسترش نمی یابد، توصیه می کنیم ابتدا قبل از انتقال تابع، idempotency را پیاده سازی کنید.
توصیههای منطقه بهینه براساس نوع ماشه رویداد متفاوت است:
نوع ماشه | توصیه منطقه |
---|---|
Cloud Firestore | نزدیکترین منطقه به مکان نمونه Cloud Firestore (به بخش بعدی مراجعه کنید) |
Realtime Database | همیشه us-central1 |
Cloud Storage | نزدیکترین منطقه به مکان سطل Cloud Storage (به بخش بعدی مراجعه کنید) |
دیگران | اگر در حال تعامل با یک نمونه Realtime Database ، یک نمونه Cloud Firestore یا یک سطل Cloud Storage در داخل تابع هستید، منطقه توصیه شده مانند یک تابع است که توسط یکی از آن منابع راه اندازی شده است. در غیر این صورت، از منطقه پیش فرض us-central1 استفاده کنید. توابع متصل به Firebase Hosting می توانند در هر منطقه ای باشند، اما برای توصیه ها، نمای کلی بدون سرور میزبان را ببینید. |
انتخاب مناطق بر اساس مکانهای Cloud Firestore و Cloud Storage
مناطق موجود برای توابع همیشه دقیقاً با مناطق موجود برای پایگاه داده Cloud Firestore و سطل های Cloud Storage شما مطابقت ندارند.
توجه داشته باشید که اگر عملکرد و منبع شما (نمونه پایگاه داده یا سطل Cloud Storage ) در مکانهای متفاوتی قرار دارند، بهطور بالقوه ممکن است افزایش تاخیر و هزینههای صورتحساب را تجربه کنید.
در اینجا نقشهای از نزدیکترین مناطق پشتیبانیشده از توابع برای Cloud Firestore و Cloud Storage ، برای مواردی که همان منطقه پشتیبانی نمیشود ، آمده است:
منطقه/چند منطقه برای Cloud Firestore و Cloud Storage | نزدیکترین منطقه برای توابع |
---|---|
nam5 یا us-central (چند منطقه ای) | us-central1 |
eur3 یا europe-west (چند منطقه) | europe-west1 |
europe-west4 (هلند) | europe-west1 |
asia-south1 (بمبئی) | asia-east2 |
asia-south2 (دهلی) | asia-east2 |
australia-southeast2 (ملبورن) | australia-southeast1 |