Cloud Functions bölgeseldir. Diğer bir deyişle, işlevinizi çalıştıran altyapı belirli bölgelerde bulunur ve Google tarafından bu bölgelerdeki tüm alt bölgelerde yedek olarak kullanılabilir olmak üzere yönetilir.
İşlevlerinizi hangi bölgelerde çalıştıracağınızı seçerken göz önünde bulundurmanız gereken başlıca noktalar gecikme ve kullanılabilirlik olmalıdır. Genellikle kullanıcılarınıza yakın bölgeleri seçebilirsiniz ancak uygulamanızda kullanılan diğer ürün ve hizmetlerin konumunu da göz önünde bulundurmalısınız. Hizmetlerin birden fazla bölgede kullanılması, uygulamanızın gecikmesini ve fiyatlandırmayı etkileyebilir.
Varsayılan olarak, işlevler us-central1
bölgesinde çalışır. Bunun, Cloud Storage paketi gibi bir etkinlik kaynağının bölgesinden farklı olabileceğini unutmayın.
Bu sayfanın ilerleyen bölümlerinde bir işlevin çalıştırıldığı bölgenin nasıl belirtileceğini öğrenin.
Desteklenen bölgeler
Bu bölümdeki listelerde yer alan energy_savings_leaf simgesi, söz konusu bölgede elektriğin düşük karbon emisyonu ile üretildiğini gösterir. Daha fazla bilgi için Google Cloud bölgeleri için karbonsuz enerji bölümüne bakın.
Cloud Functions, aşağıdaki bölgelerde 1. Katman fiyatlandırması ile kullanılabilir:
asia-east1
(Tayvan)asia-east2
(Hong Kong) yalnızca 1. nesilasia-northeast1
(Tokyo)asia-northeast2
(Osaka)europe-north1
(Finlandiya) energy_savings_leaf yalnızca 2. nesileurope-west1
(Belçika) energy_savings_leafeurope-west2
(Londra) yalnızca 1. nesilus-central1
(Iowa) energy_savings_leafus-east1
(Güney Carolina)us-east4
(Kuzey Virginia)us-west1
(Oregon) energy_savings_leaf
Cloud Functions, aşağıdaki bölgelerde 2. Katman fiyatlandırması ile kullanılabilir:
- Yalnızca
asia-east2
(Hong Kong) 2. nesil asia-northeast3
(Seul)asia-southeast1
(Singapur)asia-southeast2
(Cakarta)- Yalnızca
asia-south1
(Mumbai) 2. nesil australia-southeast1
(Sidney)australia-southeast2
(Melbourne) yalnızca 2. nesileurope-central2
(Varşova)europe-west2
(Londra) yalnızca 2. nesileurope-west3
(Frankfurt)europe-west6
(Zürih) energy_savings_leafnorthamerica-northeast1
(Montreal) energy_savings_leafnorthamerica-northeast2
(Toronto) energy_savings_leaf yalnızca 2. nesilsouthamerica-east1
(Sao Paulo) energy_savings_leafsouthamerica-west1
(Santiago, Şili) Yalnızca 2. nesilus-west2
(Los Angeles)us-west3
(Salt Lake City)us-west4
(Las Vegas)
Belirli bir projedeki belirli bir bölgedeki işlevlerin benzersiz (büyük/küçük harfe duyarlı olmayan) adları olmalıdır ancak bölgeler arasında veya projeler genelinde işlevler aynı adı paylaşabilir.
Bölge belirtmek için en iyi uygulamalar
Varsayılan olarak, işlevler us-central1
bölgesinde çalışır. Bunun, Cloud Storage paketi gibi bir etkinlik kaynağının bölgesinden farklı olabileceğini unutmayın. Bir işlevin çalıştırıldığı bölgeyi belirtmeniz gerekiyorsa her işlev tetikleyicisi türü için bu bölümdeki önerileri uygulayın.
İşlevin çalıştırıldığı bölgeyi ayarlamak için işlev tanımındaki region
parametresini gösterildiği gibi ayarlayın:
Node.js
exports.firestoreAsia = onDocumentCreated(
{
document: "my-collection/{docId}",
region: "asia-northeast1",
},
(event) => {},
);
Python
# 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
içinde virgülle ayrılmış birden fazla bölge dizesi ileterek birden fazla bölge belirtebilirsiniz. Ayrıca, birçok arka plan tetikleyici türü için bir bölge belirtirken bölgeyle birlikte doğru etkinlik filtresini de belirtmeniz gerektiğini unutmayın. Yukarıdaki örnekte, etkinliği yayınlayan Cloud Firestore document
öğesi budur. Cloud Storage tetikleyicisi için etkinlik filtresi bucket
, Pub/Sub tetikleyicisi için topic
vb. olabilir.
Üretim trafiğini yöneten bir işlevin bölgesini değiştirme hakkında daha fazla bilgi edinmek için işlevi değiştirme bölümünü inceleyin.
HTTP ve istemci tarafından çağrılabilir işlevler
HTTP ve çağrılabilir işlevler için öncelikle işlevinizi hedef bölgeye veya en çok beklenen müşterilerin bulunduğu yere en yakın konuma ayarlamanızı, ardından orijinal işlevinizi HTTP isteğini yeni işleve yönlendirecek şekilde değiştirmenizi (aynı ada sahip olabilirler) öneririz. HTTP işlevinizin desteğinin istemcileri yönlendirme yapıyorsa orijinal işlevinizi, yeni işlevinizin URL'siyle birlikte bir HTTP yönlendirme durumu (301) döndürecek şekilde değiştirebilirsiniz. Müşterileriniz yönlendirmeleri iyi işleyemezse orijinal işlevden yeni işleve yeni bir istek başlatarak isteği orijinal işlevden yeni işleve proxy olarak gönderebilirsiniz. Son adım, tüm müşterilerin yeni işlevi çağrısını sağlamaktır.
Çağrılabilir işlevler için istemci tarafı konum seçimi
Çağrılanabilir işlevle ilgili olarak, istemci çağrılabilir ayarları, HTTP işlevleriyle aynı yönergeleri uygulamalıdır. İstemci de bir bölge belirtebilir ve işlev us-central1
dışında herhangi bir bölgede çalışıyorsa bunu yapmalıdır.
İstemcide bölgeleri ayarlamak için başlangıçta istediğiniz bölgeyi belirtin:
Swift
lazy var functions = Functions.functions(region:"europe-west1")
Objective-C
@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];
Web
var functions = firebase.app().functions('europe-west1');
Android
private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");
C++
firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");
Unity
firebase.Functions.FirebaseFunctions functions;
functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");
Arka plan işlevleri
Arka plan işlevleri en az bir kez etkinlik teslimi anlamı kullanır. Diğer bir deyişle, bazı durumlarda yinelenen etkinlikler alabilirler. Bu nedenle, işlevleri ihtiyatlı olacak şekilde uygulamanız gerekir. İşleviniz zaten ideaklıysa aynı etkinlik tetikleyicisiyle işlevi yeni bölgede yeniden dağıtabilir ve yeni işlevin doğru şekilde trafik aldığını doğruladıktan sonra eski işlevi kaldırabilirsiniz. Bu geçiş sırasında her iki işlev de etkinlik alacaktır. İşlevlerin bölgelerini değiştirmek için önerilen komut sırası için işlevin bölgesini değiştirme bölümüne bakın.
İşleviniz şu anda idempotent (ideal) değilse veya idepotter özelliği bölgenin dışına taşmıyorsa işlevi taşımadan önce ilk olarak aciliyeti uygulamanızı öneririz.
Optimum bölge önerileri, etkinlik tetikleyicisi türüne göre farklılık gösterir:
Tetikleyici Türü | Bölge Önerisi |
---|---|
Cloud Firestore | Cloud Firestore örneği konumuna en yakın bölge (sonraki bölüme bakın) |
Realtime Database | Her zaman us-central1 |
Cloud Storage | Cloud Storage paketi konumuna en yakın bölge (sonraki bölüme bakın) |
Diğer | İşlevin içindeki bir Realtime Database örneği, bir Cloud Firestore örneği veya bir Cloud Storage paketiyle etkileşim kuruyorsanız önerilen bölge, bu kaynaklardan biri tarafından tetiklenen bir işlevin bulunduğu bölgeyle aynıdır. Aksi takdirde, varsayılan us-central1 bölgesini kullanın.
Firebase Hosting'e bağlı işlevler herhangi bir bölgede olabilir ancak öneriler için barındırmaya dayalı barındırmaya genel bakış sayfasını inceleyin. |
Cloud Firestore ve Cloud Storage konumlarına göre bölge seçme
İşlevler için kullanılabilecek bölgeler, Cloud Firestore veritabanınız ve Cloud Storage paketleriniz için kullanılabilen bölgelerle her zaman tam olarak eşleşmez.
İşleviniz ve kaynağınız (veritabanı örneği veya Cloud Storage paketi) farklı konumlardaysa gecikme ve faturalandırma maliyetlerinde artış olabileceğini unutmayın.
Aynı bölgenin desteklenmediği durumlarda, Cloud Firestore ve Cloud Storage için işlevler tarafından desteklenen en yakın bölgelerin eşlemesini aşağıda bulabilirsiniz:
Cloud Firestore ve Cloud Storage için Bölge/Çoklu Bölge | İşlevler için en yakın bölge |
---|---|
nam5 veya us-central (çoklu bölge) |
us-central1 |
eur3 veya europe-west (çoklu bölge) |
europe-west1 |
europe-west4 (Hollanda) |
europe-west1 |
asia-south1 (Mumbai) |
asia-east2 |
asia-south2 (Delhi) |
asia-east2 |
australia-southeast2 (Melbourne) |
australia-southeast1 |