Google is committed to advancing racial equity for Black communities. See how.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

مواقع وظائف السحاب

وظائف السحاب هي مناطق إقليمية ، مما يعني أن البنية التحتية التي تدير وظيفة السحاب الخاصة بك تقع في مناطق محددة وتديرها Google لتكون متاحة بشكل متكرر عبر جميع المناطق داخل تلك المناطق .

عند تحديد المناطق التي تريد تشغيل وظائفك فيها ، يجب أن تكون اعتباراتك الأساسية هي الكمون والتوافر. يمكنك بشكل عام تحديد مناطق قريبة من المستخدمين ، ولكن يجب عليك أيضًا مراعاة موقع المنتجات والخدمات الأخرى التي يستخدمها تطبيقك. يمكن أن يؤثر استخدام الخدمات عبر مناطق متعددة على وقت استجابة تطبيقك ، فضلاً عن الأسعار .

تتوفر وظائف السحاب في المناطق التالية:

  • us-central1 (آيوا)
  • us-east1 (ساوث كارولينا)
  • us-east4 (شمال فيرجينيا)
  • us-west2 (لوس أنجلوس)
  • us-west3 (سولت ليك سيتي)
  • us-west4 (لاس فيغاس)
  • europe-west1 (بلجيكا)
  • europe-west2 (لندن)
  • europe-west3 (فرانكفورت)
  • europe-west6 (زيورخ)
  • asia-east2 (هونج كونج)
  • asia-northeast1 (طوكيو)
  • asia-northeast2 (أوساكا)
  • northamerica-northeast1 (مونتريال)
  • southamerica-east1 (ساو باولو)
  • australia-southeast1 (سيدني)

يجب أن يكون للوظائف في منطقة معينة في مشروع معين أسماء فريدة (غير حساسة لحالة الأحرف) ، ولكن قد تشترك الوظائف عبر المناطق أو عبر المشاريع في نفس الاسم.

أفضل الممارسات لتغيير المنطقة

بشكل افتراضي ، تعمل الدالات في منطقة us-central1 . لاحظ أن هذا قد يختلف عن منطقة مصدر الحدث ، مثل مجموعة التخزين. إذا كنت بحاجة إلى تغيير المنطقة التي تعمل فيها إحدى الوظائف ، فاتبع التوصيات الواردة في هذا القسم لكل نوع من أنواع مشغلات الوظائف.

لتعيين المنطقة التي تعمل فيها دالة ، قم بتعيين معلمة region في تعريف الوظيفة كما هو موضح:

 exports.myStorageFunction = functions
    .region('europe-west1')
    .storage
    .object()
    .onFinalize((object) => {
      // ...
    });
 

يمكنك تحديد مناطق متعددة من خلال تمرير عدة سلاسل مناطق مفصولة بفواصل في functions.region() . انظر تغيير منطقة الوظيفة لمزيد من المعلومات حول الإجراءات الموصى بها.

وظائف HTTP والمتصل بها من قبل العميل

بالنسبة إلى وظائف HTTP والوظائف القابلة للاستدعاء ، نوصيك أولاً بتعيين وظيفتك على منطقة الوجهة ، أو الأقرب إلى حيث يوجد معظم العملاء المتوقعين ، ثم تغيير وظيفتك الأصلية لإعادة توجيه طلب HTTP الخاص بها إلى الوظيفة الجديدة (يمكن أن يكون لديهم نفس الوظيفة اسم). إذا كان عملاء وظيفة HTTP الخاصة بك يدعمون عمليات إعادة التوجيه ، يمكنك ببساطة تغيير وظيفتك الأصلية لإرجاع حالة إعادة توجيه HTTP (301) جنبًا إلى جنب مع عنوان URL الخاص بوظيفتك الجديدة. إذا لم يكن لزبائنك التعامل مع الموجهات بشكل جيد، يمكن الوكيل على طلب من وظيفة الأصلي إلى وظيفة جديدة من خلال الشروع في طلب جديد من وظيفة الأصلي إلى وظيفة جديدة لك. الخطوة الأخيرة هي التأكد من أن جميع العملاء يتصلون بالوظيفة الجديدة.

اختيار الموقع من جانب العميل للوظائف القابلة للاستدعاء

فيما يتعلق بالوظيفة القابلة للاستدعاء ، يجب أن تتبع إعدادات العميل القابلة للاستدعاء نفس الإرشادات الخاصة بوظائف HTTP. يمكن للعميل أيضًا تحديد منطقة ، ويجب أن يفعل ذلك إذا تم تشغيل الوظيفة في أي منطقة بخلاف us-central1 .

لتعيين مناطق على العميل ، حدد المنطقة المطلوبة عند التهيئة:

سويفت

 lazy var functions = Functions.functions(region:"us-central1")
 

ج موضوعية

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

الويب

 
var functions = firebase.app().functions('us-central1');
 

ذكري المظهر

 private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("us-central1");
 

C ++

 firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("us-central1");
 

وحدة

 firebase.Functions.FirebaseFunctions functions;

functions = Firebase.Functions.FirebaseFunctions.GetInstance("us-central1");
 

وظائف الخلفية

تعتمد وظائف الخلفية دلالة تسليم حدث مرة واحدة على الأقل ، مما يعني أنه في بعض الظروف قد تتلقى أحداثًا مكررة. لذا ، يجب عليك تنفيذ الوظائف لتكون متعاطفة . إذا كانت وظيفتك غير صالحة بالفعل ، فيمكنك إعادة نشر الوظيفة في المنطقة الجديدة باستخدام نفس مشغل الحدث وإزالة الوظيفة القديمة بعد التحقق من أن الوظيفة الجديدة تتلقى حركة المرور بشكل صحيح. أثناء هذا الانتقال ، ستتلقى كلتا الدالتين الأحداث. انظر تغيير منطقة الوظيفة من أجل التسلسل الموصى به للأوامر لتغيير مناطق الوظائف.

إذا لم تكن وظيفتك حاليًا عاطفة ، أو لم تمتد قوة عزمها إلى ما بعد المنطقة ، فإننا نوصي بتطبيق idempotency أولاً قبل نقل الوظيفة.

تختلف توصيات المنطقة المثلى حسب نوع مشغل الحدث:

نوع الزناد توصية المنطقة
سحابة Firestore المنطقة الأقرب إلى موقع مثيل Cloud Firestore (انظر القسم التالي)
قاعدة بيانات الوقت الحقيقي دائما us-central1
تخزين المنطقة الأقرب إلى موقع دلو التخزين (انظر القسم التالي)
الآخرين إذا كنت تتفاعل مع مثيل قاعدة بيانات Realtime ، أو نسخة Cloud Firestore ، أو مجموعة تخزين داخل الوظيفة ، فإن المنطقة الموصى بها هي نفسها كما لو كان لديك وظيفة تم تشغيلها بواسطة أحد هذه الموارد. خلاف ذلك ، استخدم المنطقة الافتراضية us-central1 . لاحظ أيضًا أن الوظائف المتصلة بـ Firebase Hosting يجب أن تكون موجودة في us-central1 .

تحديد المناطق بناءً على Cloud Firestore ومواقع التخزين

لا تتطابق المناطق المتاحة للوظائف دائمًا بدقة مع المناطق المتاحة لقاعدة بيانات Cloud Firestore ودلائل التخزين السحابي.

لاحظ أنه إذا كانت وظيفتك وموردك (مثيل قاعدة البيانات أو مجموعة التخزين) في مواقع مختلفة ، فمن المحتمل أن تواجه زيادة في الكمون وتكاليف الفوترة .

وفيما يلي رسم الخرائط من أقرب المناطق بدعم ظائف لسحابة Firestore وسحابة التخزين، في الحالات التي لا يتم اعتماد نفس المنطقة:

منطقة / مناطق متعددة لـ Cloud Firestore والتخزين أقرب منطقة للوظائف
nam5 أو us-central (multi-region) us-central1
eur3 أو europe-west (متعدد المناطق) europe-west1
asia-south1 (مومباي) asia-east2