Sunucusuz web uygulaması

Bu başvuru mimarisi sunucusuz bir web uygulaması gösterir. Uygulama, Azure Blob Depolama statik içerik sağlar ve Azure İşlevleri kullanarak bir API uygular. API, Azure Cosmos DB'den verileri okur ve sonuçları web uygulamasına döndürür.

Bu mimariye yönelik iki başvuru uygulaması GitHub'da kullanılabilir: İnsansız Hava Aracı Teslim Uygulaması (ARM ve Azure Pipelines) ve To Do App (Bicep & GitHub Actions).

Mimari

Bu mimarinin bir Visio dosyasını indirin.

Sunucusuz teriminin iki farklı ama ilgili anlamı vardır:

• Hizmet olarak arka uç (BaaS). Veritabanları ve depolama gibi arka uç bulut hizmetleri, istemci uygulamalarının bu hizmetlere doğrudan bağlanmasını sağlayan API'ler sağlar.
• Hizmet olarak çalışır (FaaS). Bu modelde "işlev", buluta dağıtılan ve kodu çalıştıran sunucuları tamamen soyutlayan bir barındırma ortamında çalışan bir kod parçasıdır.

Her iki tanımda da geliştiricilerin ve DevOps personelinin sunucuları dağıtması, yapılandırması veya yönetmesi gerekmeyen bir fikri vardır. Bu başvuru mimarisi, Azure İşlevleri kullanarak FaaS'a odaklanır, ancak Azure Blob Depolama web içeriğinin sunulması BaaS'e bir örnek olabilir. FaaS'ın bazı önemli özellikleri şunlardır:

1. İşlem kaynakları platform tarafından gerektiğinde dinamik olarak ayrılır.
2. Tüketim tabanlı fiyatlandırma: Yalnızca kodunuzu yürütmek için kullanılan işlem kaynakları için ücretlendirilirsiniz.
3. İşlem kaynakları, geliştiricinin herhangi bir yapılandırma yapması gerekmeden trafiğe göre isteğe bağlı olarak ölçeklendirilir.

İşlevler, http isteği veya kuyruğa gelen ileti gibi bir dış tetikleyici gerçekleştiğinde yürütülür. Bu, sunucusuz mimariler için olay odaklı mimari stilini doğal hale getirir. Mimarideki bileşenler arasındaki çalışmayı koordine etmek için ileti aracılarını veya pub/sub desenlerini kullanmayı göz önünde bulundurun. Azure'da mesajlaşma teknolojileri arasında seçim yapma konusunda yardım için bkz . İleti teslim eden Azure hizmetleri arasında seçim yapma.

Bileşenler

Mimari aşağıdaki bileşenlerden oluşur:

Blob Depolama. HTML, CSS ve JavaScript dosyaları gibi statik web içeriği Azure Blob Depolama depolanır ve statik web sitesi barındırma kullanılarak istemcilere sunulur. Tüm dinamik etkileşimler, arka uç API'lerine çağrı yapan JavaScript kodu aracılığıyla gerçekleşir. Web sayfasını işlemek için sunucu tarafı kodu yoktur. Statik web sitesi barındırma, dizin belgelerini ve özel 404 hata sayfalarını destekler.

CDN. Daha düşük gecikme süresi ve daha hızlı içerik teslimi için içeriği önbelleğe almak ve bir HTTPS uç noktası sağlamak için Azure Content Delivery Network (CDN) kullanın.

İşlev Uygulamaları. Azure İşlevleri sunucusuz bir işlem seçeneğidir. Bir kod parçasının ("işlev") tetikleyici tarafından çağrıldığı olay temelli bir model kullanır. Bu mimaride, bir istemci HTTP isteğinde bulunduğunda işlev çağrılır. İstek her zaman aşağıda açıklanan bir API ağ geçidi üzerinden yönlendirilir.

API Management. Azure API Management , HTTP işlevinin önünde yer alan bir API ağ geçidi sağlar. İstemci uygulamaları tarafından kullanılan API'leri yayımlamak ve yönetmek için API Management'ı kullanabilirsiniz. Ağ geçidi kullanmak, ön uç uygulamasını arka uç API'lerinden ayırmaya yardımcı olur. Örneğin, API Management URL'leri yeniden yazabilir, istekleri arka uca ulaşmadan dönüştürebilir, istek veya yanıt üst bilgilerini ayarlayabilir vb.

API Management, aşağıdakiler gibi çapraz kesme sorunlarını uygulamak için de kullanılabilir:

• Kullanım kotalarını ve hız sınırlarını zorunlu tutma
• Kimlik doğrulaması için OAuth belirteçlerini doğrulama
• Çıkış noktaları arası istekleri etkinleştirme (CORS)
• yanıtları Önbelleğe Alma
• İstekleri izleme ve günlüğe kaydetme

API Management tarafından sağlanan işlevlerin tümüne ihtiyacınız yoksa, başka bir seçenek de İşlev Proxy'lerini kullanmaktır. bu Azure İşlevleri özelliği, arka uç işlevlerine yollar oluşturarak birden çok işlev uygulaması için tek bir API yüzeyi tanımlamanızı sağlar. İşlev proxy'leri, HTTP isteği ve yanıtı üzerinde sınırlı dönüştürmeler de gerçekleştirebilir. Ancak, API Management'ın aynı zengin ilke tabanlı özelliklerini sağlamaz.

Azure Cosmos DB. Azure Cosmos DB , çok modelli bir veritabanı hizmetidir. Bu senaryo için işlev uygulaması, istemciden gelen HTTP GET isteklerine yanıt olarak Azure Cosmos DB'den belgeleri getirir.

Microsoft Entra Id (Microsoft Entra ID). Kullanıcılar, Microsoft Entra Id kimlik bilgilerini kullanarak web uygulamasında oturum açar. Microsoft Entra Id, web uygulamasının API isteklerinin kimliğini doğrulamak için kullandığı API için bir erişim belirteci döndürür (bkz . Kimlik Doğrulaması).

Azure İzleyici. Azure İzleyici , çözümde dağıtılan Azure hizmetleriyle ilgili performans ölçümlerini toplar. Bunları bir panoda görselleştirerek çözümün durumu hakkında görünürlük elde edebilirsiniz. Ayrıca uygulama günlüklerini de topladı.

Azure Pipelines. Azure Pipelines , uygulamayı oluşturan, test eden ve dağıtan bir sürekli tümleştirme (CI) ve sürekli teslim (CD) hizmetidir.

GitHub Actions. İş akışı , GitHub deponuzda ayarladığınız otomatik bir işlemdir (CI/CD). GitHub'da iş akışıyla herhangi bir proje oluşturabilir, test edebilir, paketleyebilir, yayımlayabilir veya dağıtabilirsiniz.

Senaryo ayrıntıları

Olası kullanım örnekleri

Bu insansız hava aracı ile teslimat çözümü uçak, havacılık, havacılık ve robot endüstrisi için idealdir.

Öneriler

İşlev Uygulaması planları

Azure İşlevleri iki barındırma modeli destekler. Tüketim planıyla, kodunuz çalışırken işlem gücü otomatik olarak ayrılır. App Service planıyla kodunuz için bir vm kümesi ayrılır. App Service planı, VM sayısını ve VM boyutunu tanımlar.

App Service planının yukarıda verilen tanıma göre tamamen sunucusuz olmadığını unutmayın. Ancak programlama modeli aynıdır; aynı işlev kodu hem tüketim planında hem de App Service planında çalıştırılabilir.

Hangi plan türünü kullanacağınızı seçerken dikkate alınması gereken bazı faktörler şunlardır:

• Soğuk başlangıç. Tüketim planında, yakın zamanda çağrılmamış bir işlev bir sonraki çalıştırıldığında ek gecikmeye neden olur. Bu ek gecikme süresi, çalışma zamanı ortamının ayırılıp hazırlanmasından kaynaklanır. Genellikle saniye sırasına bağlıdır, ancak yüklenmesi gereken bağımlılık sayısı da dahil olmak üzere çeşitli faktörlere bağlıdır. Daha fazla bilgi için bkz . Sunucusuz Soğuk Başlatmayı Anlama. Ek gecikme süresi kullanıcılar tarafından doğrudan gözlemlendiğinden, soğuk başlatma genellikle zaman uyumsuz ileti temelli iş yüklerinden (kuyruk veya olay hub'ları tetikleyicileri) daha çok etkileşimli iş yükleri (HTTP tetikleyicileri) için önemlidir.
• Zaman aşımı süresi. Tüketim planında, yapılandırılabilir bir süre (en fazla 10 dakika) sonra işlev yürütme zaman aşımına uğradı
• Sanal ağ yalıtımı. App Service planı kullanmak, işlevlerin ayrılmış ve yalıtılmış bir barındırma ortamı olan bir App Service Ortamı içinde çalışmasına olanak tanır.
• Fiyatlandırma modeli. Tüketim planı, yürütme sayısı ve kaynak tüketimi (bellek × yürütme süresi) ile faturalandırılır. App Service planı, VM örneği SKU'su temelinde saatlik olarak faturalandırılır. Yalnızca kullandığınız işlem kaynakları için ödeme yaptığınız için tüketim planı genellikle App Service planından daha ucuz olabilir. Bu durum özellikle trafiğinizin en yoğun ve en yüksek trafikle karşılaşması durumunda geçerlidir. Ancak bir uygulama sabit yüksek hacimli aktarım hızıyla karşılaşırsa App Service planının maliyeti tüketim planından daha düşük olabilir.
• Ölçeklendirme. Tüketim modelinin büyük bir avantajı, gelen trafiğe göre dinamik olarak ölçeklendirilmesidir. Bu ölçeklendirme hızlı bir şekilde gerçekleşse de, yine de bir artış süresi vardır. Bazı iş yüklerinde, sıfır artış süresiyle trafik artışlarını işleyebilmek için VM'lerin kasıtlı olarak fazla sağlamasını yapmak isteyebilirsiniz. Bu durumda bir App Service planı düşünün.

İşlev Uygulaması sınırları

İşlev uygulaması bir veya daha fazla işlevin yürütülmesini barındırıyor. Birkaç işlevi mantıksal birim olarak gruplandırmak için işlev uygulamasını kullanabilirsiniz. İşlev uygulaması içinde işlevler aynı uygulama ayarlarını, barındırma planını ve dağıtım yaşam döngüsünü paylaşır. Her işlev uygulamasının kendi ana bilgisayar adı vardır.

Aynı yaşam döngüsünü ve ayarları paylaşan işlevleri gruplandırmak için işlev uygulamalarını kullanın. Aynı yaşam döngüsünü paylaşmayen işlevler farklı işlev uygulamalarında barındırılmalıdır.

Her işlev uygulamasının büyük olasılıkla birkaç ilgili işlevden oluşan bir mikro hizmeti temsil ettiği mikro hizmetler yaklaşımını kullanmayı göz önünde bulundurun. Mikro hizmetler mimarisinde, hizmetlerin gevşek bağlantı ve yüksek işlevsel uyumu olmalıdır. Gevşek bir şekilde bağlanmış olması, diğer hizmetlerin aynı anda güncelleştirilmesine gerek kalmadan bir hizmeti değiştirebileceğiniz anlamına gelir. Uyumlu, bir hizmetin tek, iyi tanımlanmış bir amacı olduğu anlamına gelir. Bu fikirlerin daha fazla tartışılması için bkz . Mikro hizmetler tasarlama: Etki alanı analizi.

İşlev bağlamaları

Mümkün olduğunda İşlev bağlamalarını kullanın. Bağlamalar, kodunuzu verilere bağlamak ve diğer Azure hizmetleriyle tümleştirmek için bildirim temelli bir yol sağlar. Giriş bağlaması, bir dış veri kaynağından giriş parametresini doldurur. Çıkış bağlaması, işlevin dönüş değerini kuyruk veya veritabanı gibi bir veri havuzuna gönderir.

Örneğin, GetStatus başvuru uygulamasındaki işlev Azure Cosmos DB giriş bağlamasını kullanır. Bu bağlama, HTTP isteğindeki sorgu dizesinden alınan sorgu parametreleri kullanılarak Azure Cosmos DB'de belge aramak üzere yapılandırılır. Belge bulunursa işleve parametre olarak geçirilir.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

Bağlamaları kullanarak, doğrudan hizmetle konuşan ve işlev kodunu daha basit hale getiren ve ayrıca veri kaynağının veya havuzun ayrıntılarını soyutlayan kod yazmanız gerekmez. Ancak bazı durumlarda bağlamanın sağladığından daha karmaşık bir mantığa ihtiyacınız olabilir. Bu durumda Azure istemci SDK'larını doğrudan kullanın.

Dikkat edilmesi gereken noktalar

Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular. Daha fazla bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve.

Ölçeklenebilirlik

İşlevler. Tüketim planı için HTTP tetikleyicisi trafiğe göre ölçeklendirilir. Eşzamanlı işlev örneği sayısının bir sınırı vardır, ancak her örnek aynı anda birden fazla isteği işleyebilir. App Service planında HTTP tetikleyicisi, sabit bir değer olabilecek veya bir dizi otomatik ölçeklendirme kuralına göre otomatik ölçeklendirme gerçekleştirebilen VM örneği sayısına göre ölçeklendirilir. Bilgi için bkz. Azure İşlevleri ölçeklendirme ve barındırma.

Azure Cosmos DB. Azure Cosmos DB için aktarım hızı kapasitesi İstek Birimleri (RU) cinsinden ölçülür. 1 RU aktarım hızı, 1 KB'lık bir belge elde etmek için gereken aktarım hızı gereksinimine karşılık gelir. Azure Cosmos DB kapsayıcısını 10.000 RU'yu aşacak şekilde ölçeklendirmek için, kapsayıcıyı oluştururken bir bölüm anahtarı belirtmeniz ve bölüm anahtarını oluşturduğunuz her belgeye eklemeniz gerekir. Bölüm anahtarları hakkında daha fazla bilgi için bkz . Azure Cosmos DB'de bölümleme ve ölçeklendirme.

API Management. API Management ölçeği genişletebilir ve kural tabanlı otomatik ölçeklendirmeyi destekler. Ölçeklendirme işlemi en az 20 dakika sürer. Trafiğiniz çok yüksekse, beklediğiniz maksimum veri bloğu trafiğini sağlamanız gerekir. Ancak otomatik ölçeklendirme, trafikteki saatlik veya günlük değişimleri işlemek için kullanışlıdır. Daha fazla bilgi için bkz . Azure API Management örneğini otomatik olarak ölçeklendirme.

Olağanüstü durum kurtarma

Burada gösterilen dağıtım tek bir Azure bölgesinde yer alır. Olağanüstü durum kurtarma için daha dayanıklı bir yaklaşım için çeşitli hizmetlerdeki coğrafi dağıtım özelliklerinden yararlanın:

• API Management, tek bir API Management örneğini herhangi bir sayıda Azure bölgesine dağıtmak için kullanılabilen çok bölgeli dağıtımı destekler. Daha fazla bilgi için bkz . Azure API Management hizmet örneğini birden çok Azure bölgesine dağıtma.

• HTTP isteklerini birincil bölgeye yönlendirmek için Traffic Manager'ı kullanın. Bu bölgede çalışan İşlev Uygulaması kullanılamaz duruma gelirse Traffic Manager ikincil bölgeye yük devredebilir.

• Azure Cosmos DB, Azure Cosmos DB hesabınıza eklediğiniz tüm bölgelere yazma olanağı sağlayan birden çok yazma bölgesini destekler. Çoklu yazma özelliğini etkinleştirmezseniz, birincil yazma bölgesine yük devretmeye devam edebilirsiniz. Azure Cosmos DB istemci SDK'ları ve Azure İşlev bağlamaları yük devretmeyi otomatik olarak işler, bu nedenle uygulama yapılandırma ayarlarını güncelleştirmeniz gerekmez.

Güvenlik

Güvenlik, kasıtlı saldırılara ve değerli verilerinizin ve sistemlerinizin kötüye kullanılmasına karşı güvence sağlar. Daha fazla bilgi için bkz . Güvenlik sütununa genel bakış.

Kimlik Doğrulaması

GetStatus Başvuru uygulamasındaki API, isteklerin kimliğini doğrulamak için Microsoft Entra Id kullanır. Microsoft Entra ID, OAuth 2 protokolünün üzerinde oluşturulmuş bir kimlik doğrulama protokolü olan OpenID Bağlan protokolünün desteklenmesini sağlar.

Bu mimaride, istemci uygulaması tarayıcıda çalışan tek sayfalı bir uygulamadır (SPA). Bu tür bir istemci uygulaması bir istemci gizli dizisini veya yetkilendirme kodunu gizli tutamaz, bu nedenle örtük verme akışı uygundur. (Bkz. Hangi OAuth 2.0 akışını kullanmalıyım?). Genel akış şu şekildedir:

1. Kullanıcı, web uygulamasında "Oturum aç" bağlantısına tıklar.
2. Tarayıcı, Microsoft Entra oturum açma sayfasına yönlendirilir.
3. Kullanıcı oturum açar.
4. Microsoft Entra Id, URL parçasındaki bir erişim belirteci de dahil olmak üzere istemci uygulamasına geri yönlendirir.
5. Web uygulaması API'yi çağırdığında, Kimlik Doğrulaması üst bilgisinde erişim belirtecini içerir. Uygulama kimliği erişim belirtecinde hedef kitle ('aud') talebi olarak gönderilir.
6. Arka uç API'si erişim belirtecini doğrular.

Kimlik doğrulamasını yapılandırmak için:

• Microsoft Entra kiracınıza bir uygulama kaydedin. Bu, istemcinin oturum açma URL'sini içeren bir uygulama kimliği oluşturur.

• İşlev Uygulamasının içinde Microsoft Entra kimlik doğrulamasını etkinleştirin. Daha fazla bilgi için bkz. Azure App Service’de kimlik doğrulama ve yetkilendirme.

• Erişim belirtecini doğrulayarak isteği önceden yetkilendirmek için API Management'a validate-jwt ilkesini ekleyin.

Diğer ayrıntılar için bkz . GitHub benioku.

İstemci uygulaması ve arka uç API'si için Microsoft Entra Id'de ayrı uygulama kayıtları oluşturmanız önerilir. İstemci uygulamasına API'yi çağırma izni verin. Bu yaklaşım, birden çok API ve istemci tanımlama ve her birinin izinlerini denetleme esnekliği sağlar.

Api'de, uygulamalara kullanıcıdan hangi izinleri istedikleri üzerinde ayrıntılı denetim sağlamak için kapsamları kullanın. Örneğin, bir API'nin Read ve Write kapsamları olabilir ve belirli bir istemci uygulaması kullanıcıdan yalnızca izinleri yetkilendirmesini Read isteyebilir.

Yetkilendirme

Birçok uygulamada, arka uç API'sinin kullanıcının belirli bir eylemi gerçekleştirme izni olup olmadığını denetlemesi gerekir. Kullanıcı hakkındaki bilgilerin kimlik sağlayıcısı (bu örnekte Microsoft Entra Id) tarafından iletildiği ve yetkilendirme kararları almak için kullanıldığı talep tabanlı yetkilendirme kullanılması önerilir. Örneğin, bir uygulamayı Microsoft Entra Id'ye kaydettiğinizde, bir dizi uygulama rolü tanımlayabilirsiniz. Kullanıcı uygulamada oturum açtığında Microsoft Entra ID, grup üyeliği aracılığıyla devralınan roller de dahil olmak üzere kullanıcıya verilen her rol için bir roles talep içerir.

Microsoft Entra Id'nin istemciye döndürdüğü kimlik belirteci, kullanıcının taleplerinden bazılarını içerir. İşlev uygulamasında, bu talepler isteğin X-MS-CLIENT-PRINCIPAL üst bilgisinde bulunur. Ancak, bu bilgileri bağlama verilerinden okumak daha kolaydır. Diğer talepler için Microsoft Graph'ı kullanarak Microsoft Entra Id sorgusunu yapın. (Kullanıcı oturum açarken bu eyleme onay vermelidir.)

Daha fazla bilgi için bkz . İstemci kimlikleriyle çalışma.

CORS

Bu başvuru mimarisinde, web uygulaması ve API aynı kaynağı paylaşmaz. Bu, uygulama API'yi çağırdığında çıkış noktaları arası bir istek olduğu anlamına gelir. Tarayıcı güvenliği, bir web sitesinin başka bir etki alanına AJAX istekleri göndermesini engeller. Bu kısıtlama aynı kaynak ilkesi olarak adlandırılır ve kötü amaçlı bir sitenin başka bir siteden hassas verileri okumasını engeller. Çıkış noktaları arası bir isteği etkinleştirmek için API Management ağ geçidine bir Çıkış Noktaları Arası Kaynak Paylaşımı (CORS) ilkesi ekleyin:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

Bu örnekte allow-credentials özniteliği true şeklindedir. Bu, tarayıcıya istekle kimlik bilgileri (tanımlama bilgileri dahil) gönderme yetkisi sağlar. Aksi takdirde, tarayıcı varsayılan olarak çıkış noktaları arası bir istekle kimlik bilgileri göndermez.

HTTPS zorlama

En yüksek güvenlik için, istek işlem hattı boyunca HTTPS'yi zorunlu kın:

• CDN. Azure CDN, varsayılan olarak alt etki alanı *.azureedge.net üzerinde HTTPS'yi destekler. ÖZEL etki alanı adları için CDN'de HTTPS'yi etkinleştirmek için bkz . Öğretici: Azure CDN özel etki alanında HTTPS'yi yapılandırma.

• Statik web sitesi barındırma. Depolama hesabındaki "Güvenli aktarım gerekli" seçeneğini etkinleştirin. Bu seçenek etkinleştirildiğinde, depolama hesabı yalnızca güvenli HTTPS bağlantılarından gelen isteklere izin verir.

• API Management. API'leri yalnızca HTTPS protokollerini kullanacak şekilde yapılandırın. Bunu Azure portalında veya resource manager şablonu aracılığıyla yapılandırabilirsiniz:

  {
      "apiVersion": "2018-01-01",
      "type": "apis",
      "name": "dronedeliveryapi",
      "dependsOn": [
          "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
      ],
      "properties": {
          "displayName": "Drone Delivery API",
          "description": "Drone Delivery API",
          "path": "api",
          "protocols": [ "HTTPS" ]
      },
      ...
  }
  

• Azure İşlevleri "Yalnızca HTTPS" ayarını etkinleştirin.

İşlev uygulamasını kilitleme

İşleve yapılan tüm çağrılar API ağ geçidinden geçmelidir. Bunu aşağıdaki gibi gerçekleştirebilirsiniz:

• İşlev uygulamasını bir işlev anahtarı gerektirecek şekilde yapılandırın. API Management ağ geçidi, işlev uygulamasını çağırdığında işlev anahtarını içerir. Bu, istemcilerin ağ geçidini atlayarak işlevi doğrudan çağırmasını engeller.

• API Management ağ geçidinin statik bir IP adresi vardır. Azure İşlevi'ni yalnızca bu statik IP adresinden gelen çağrılara izin verecek şekilde kısıtlayın. Daha fazla bilgi için bkz. hizmet statik IP kısıtlamaları Azure Uygulaması. (Bu özellik yalnızca Standart katman hizmetlerinde kullanılabilir.)

Uygulama parolalarını koruma

Veritabanı kimlik bilgileri gibi uygulama gizli dizilerini kodunuzda veya yapılandırma dosyalarınızda depolamayın. Bunun yerine, Azure'da şifrelenmiş olarak depolanan Uygulama ayarlarını kullanın. Daha fazla bilgi için bkz. Azure Uygulaması Hizmetinde güvenlik ve Azure İşlevleri.

Alternatif olarak, uygulama gizli dizilerini Key Vault'ta depolayabilirsiniz. Bu, gizli dizilerin depolanmasını merkezileştirmenize, dağıtımlarını denetlemenize ve gizli dizilere nasıl ve ne zaman erişildiğini izlemenize olanak tanır. Daha fazla bilgi için bkz . Key Vault'tan gizli dizi okumak için Azure web uygulaması yapılandırma. Ancak, İşlevler tetikleyicilerinin ve bağlamalarının yapılandırma ayarlarını uygulama ayarlarından yüklediğini unutmayın. Tetikleyicileri ve bağlamaları Key Vault gizli dizilerini kullanacak şekilde yapılandırmanın yerleşik bir yolu yoktur.

DevOps

Ön uç dağıtımı

Bu başvuru mimarisinin ön ucu, Sunucusuz arka uç API'lerine erişen JavaScript ve hızlı bir kullanıcı deneyimi sağlayan statik içerik içeren tek sayfalı bir uygulamadır. Bu tür bir uygulama için dikkat edilmesi gereken bazı önemli noktalar şunlardır:

• Uygulamayı, bulutta barındırılan statik içerikle genel kullanıma hazır bir CDN ile geniş bir coğrafi alan üzerinden kullanıcılara tekdüzen dağıtın. Bu, ayrılmış bir web sunucusu gereksinimini önler. Başlamak için Bkz . Azure depolama hesabını Azure CDN ile tümleştirme. HTTPS ile uygulamanızın güvenliğini sağlayın. Ek öneriler için içerik teslim ağlarını kullanmaya yönelik en iyi yöntemler makalesini okuyun.
• Her kaynak değişikliğini otomatik olarak derlemek ve dağıtmak için Azure Pipelines veya GitHub Actions gibi hızlı ve güvenilir bir CI/CD hizmeti kullanın. Kaynak bir çevrimiçi sürüm denetim sisteminde bulunmalıdır. Azure Pipelines hakkında daha fazla bilgi için bkz . İlk işlem hattınızı oluşturma. Azure için GitHub Actions hakkında daha fazla bilgi edinmek için bkz . Azure'a uygulama dağıtma.
• CDN'de bant genişliği tüketimini azaltmak ve performansı artırmak için web sitesi dosyalarınızı sıkıştırın. Azure CDN, uç sunucularda anında sıkıştırmaya izin verir. Alternatif olarak, bu başvuru mimarisindeki dağıtım işlem hattı, dosyaları Blob depolamaya dağıtmadan önce sıkıştırır. Bu, depolama gereksinimini azaltır ve CDN sınırlamalarından bağımsız olarak sıkıştırma araçlarını seçme özgürlüğü sunar.
• CDN, tüm kullanıcılara en yeni içeriğin sunulduğundan emin olmak için önbelleğini temizleyebilmelidir. Derleme ve dağıtma işlemleri atomik değilse( örneğin, eski dosyaları aynı kaynak klasörde yeni oluşturulanlarla değiştirirlerse) önbellek temizlemesi gerekir.
• Dizinleri kullanarak sürüm oluşturma gibi farklı bir önbellek stratejisi, CDN tarafından temizleme gerektirmeyebilir. Bu ön uç uygulamasındaki derleme işlem hattı, yeni oluşturulan her sürüm için yeni bir dizin oluşturur. Bu sürüm Blob depolamaya atomik birim olarak yüklenir. Azure CDN, bu yeni sürümü yalnızca tamamlanan bir dağıtımdan sonra gösterir.
• Kaynak dosyalarını aylara yayılan daha uzun bir süre önbelleğe alarak önbellek TTL'sini artırın. Önbelleğe alınan dosyaların değiştiğinde güncelleştirildiğinden emin olmak için, yeniden oluşturulduğunda dosya adlarının parmak izini alın. Bu ön uç uygulaması, index.html gibi genel kullanıma yönelik dosyalar dışındaki tüm dosyaların parmak izini alır. index.html sık sık güncelleştirildiğinden, önbellek yenilemesine neden olan değiştirilen dosya adlarını yansıtır. Daha fazla bilgi için Bkz. Azure CDN'de web içeriğinin süre sonunu yönetme.

Arka uç dağıtımı

İşlev uygulamasını dağıtmak için paket dosyalarını ("Paketten çalıştır") kullanmanızı öneririz. Bu yaklaşımı kullanarak blob Depolama kapsayıcısına bir zip dosyası yüklersiniz ve İşlevler çalışma zamanı zip dosyasını salt okunur bir dosya sistemi olarak bağlar. Bu, başarısız bir dağıtımın uygulamayı tutarsız bir durumda bırakma olasılığını azaltan atomik bir işlemdir. Ayrıca, tüm dosyalar aynı anda değiştirildiğinden, özellikle Node.js uygulamalar için soğuk başlangıç sürelerini iyileştirebilir.

API sürümü oluşturma

API, hizmet ve istemciler arasındaki bir sözleşmedir. Bu mimaride API sözleşmesi API Management katmanında tanımlanır. API Management iki ayrı ama tamamlayıcı sürüm oluşturma kavramını destekler:

• Sürümler , API tüketicilerinin v1 ve v2 gibi ihtiyaçlarına göre bir API sürümü seçmesine olanak sağlar.

• Düzeltmeler , API yöneticilerinin BIR API'de hataya neden olmayan değişiklikler yapmasına ve bu değişiklikleri dağıtmasına olanak sağlar ve değişiklikleri API tüketicilerine bildirmek için bir değişiklik günlüğüyle birlikte dağıtabilir.

API'de hataya neden olan bir değişiklik yaparsanız API Management'ta yeni bir sürüm yayımlayın. Yeni sürümü özgün sürümle birlikte ayrı bir İşlev Uygulamasında dağıtın. Bu, istemci uygulamalarını bozmadan mevcut istemcileri yeni API'ye geçirmenizi sağlar. Sonunda, önceki sürümü kullanımdan kaldırabilirsiniz. API Management çeşitli sürüm oluşturma düzenlerini destekler: URL yolu, HTTP üst bilgisi veya sorgu dizesi. GENEL olarak API sürümü oluşturma hakkında daha fazla bilgi için bkz . RESTful web API'sini sürüm oluşturma.

API değişikliklerini bozmamayan güncelleştirmeler için yeni sürümü aynı İşlev Uygulamasındaki bir hazırlama yuvasına dağıtın. Dağıtımın başarılı olduğunu doğrulayın ve ardından hazırlanmış sürümü üretim sürümüyle değiştirin. API Management'ta düzeltme yayımlama.

Maliyet iyileştirme

Maliyet iyileştirmesi, gereksiz giderleri azaltmanın ve operasyonel verimlilikleri iyileştirmenin yollarını aramaktır. Daha fazla bilgi için bkz . Maliyet iyileştirme sütununa genel bakış.

Maliyetleri tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Bu mimarinin maliyetini iyileştirmek için bu noktaları göz önünde bulundurun.

Azure İşlevleri

Azure İşlevleri iki barındırma modeli destekler.

• Tüketim planı.

  Kodunuz çalışırken işlem gücü otomatik olarak ayrılır.

• App Service Planı.

  Kodunuz için bir vm kümesi ayrılır. Bu plan VM sayısını ve VM boyutunu tanımlar.

Bu mimaride, bir istemci HTTP isteğinde bulunduğunda bir işlev çağrılır. Bu kullanım örneğinde sabit bir yüksek hacimli aktarım hızı beklenmediğinden, yalnızca kullandığınız işlem kaynakları için ödeme yaptığınız için tüketim planı önerilir.

Azure Cosmos DB

Azure Cosmos DB, sağlanan aktarım hızı ve tüketilen depolama için saate göre faturalandırılır. Sağlanan aktarım hızı, eklemeler, okumalar gibi tipik veritabanı işlemleri için kullanılabilen saniye başına İstek Birimleri (RU/sn) cinsinden ifade edilir. Fiyat, ayırdığınız RU/sn kapasiteye bağlıdır.

Depolama, depolanan verileriniz ve dizininiz için kullanılan her GB için faturalandırılır.

Daha fazla bilgi için bkz . Azure Cosmos DB fiyatlandırma modeli .

Bu mimaride işlev uygulaması, istemciden gelen HTTP GET isteklerine yanıt olarak Azure Cosmos DB'den belgeleri getirir. Okuma işlemleri RU/sn ile ifade edilen yazma işlemlerinden çok daha ucuz olduğundan Azure Cosmos DB bu durumda uygun maliyetlidir.

Content Delivery Network

Faturalama oranı, içeriği son kullanıcıya teslim eden kaynak sunucunun konumuna bağlı olarak faturalama bölgesine bağlı olarak farklılık gösterebilir. İstemcinin fiziksel konumu faturalama bölgesi değildir. CDN'ye isabet eden herhangi bir HTTP veya HTTPS isteği, tüm yanıt türlerini içeren faturalanabilir bir olaydır: başarı, başarısızlık veya diğer. Farklı yanıtlar farklı trafik miktarları oluşturabilir.

Bu başvuru mimarisinde dağıtım tek bir Azure bölgesinde bulunur.

Maliyetleri düşürmek için kaynak dosyalarını daha uzun süre önbelleğe alarak ve içeriğinizde mümkün olan en uzun TTL'yi ayarlayarak önbellek TTL'sini artırmayı göz önünde bulundurun.

Daha fazla bilgi için Microsoft Azure İyi Tasarlanmış Çerçeve'deki Maliyet bölümüne bakın.

Bu senaryoyu dağıtın

Bu mimariye yönelik başvuru uygulamasını dağıtmak için bkz . GitHub benioku.

Sonraki adımlar

Ürün belgeleri:

• Azure Blob Depolama nedir?
• Azure Content Delivery Network (CDN)
• Azure İşlevleri’ne giriş
• API Yönetimi hakkında
• Azure Cosmos DB'ye hoş geldiniz
• Microsoft Entra ID
• Azure İzleyici'ye genel bakış
• Azure Pipelines nedir?

Modülleri öğrenin:

• İş senaryonuz için en iyi Azure sunucusuz teknolojisini seçin
• Azure İşlevleri ile sunucusuz mantık oluşturma

İlgili kaynaklar

Başvuru uygulaması hakkında daha fazla bilgi edinmek için Kod kılavuzu: Azure İşlevleri ile sunucusuz uygulama makalesini okuyun.

İlgili kılavuz:

• CDN'leri kullanmak için en iyi yöntemler
• Statik İçerik Barındırma düzeni