Sunucusuz web uygulaması

Bu başvuru mimarisinde sunucusuz bir Web uygulaması gösterilmektedir. uygulama, azure Blob Depolama statik içerik sunar ve azure işlevleri 'ni kullanarak bir apı uygular. apı Cosmos DB verileri okur ve sonuçları web uygulamasına döndürür.

bu mimari için iki başvuru uygulaması GitHub kullanılabilir: drone teslim uygulaması (ARM Azure Pipelines) ve To Do uygulaması (bıcep GitHub eylemleri).

Bu mimarinin bir SVG indirin.

Sunucusuz terimi iki ayrı ancak ilgili anlamlara sahiptir:

• 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 işlevler (FAAS). Bu modelde, "işlev" buluta dağıtılan ve kodu çalıştıran sunucuları tamamen soyutlayan bir barındırma ortamında çalıştırılan bir kod parçasıdır.

her iki tanım de geliştiricilerin ve DevOps personelin sunucuları dağıtmaları, yapılandırması veya yönetmesi gerekmez. bu başvuru mimarisi azure işlevleri kullanılarak faas 'ye odaklanmasına karşın azure Blob Depolama web içeriğine hizmet vermek, baas 'in bir örneği olabilir. FaaS 'nin bazı önemli özellikleri şunlardır:

1. İşlem kaynakları, platformun gerektiği şekilde 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ştiricilerin herhangi bir yapılandırma yapması gerekmeden trafiğe göre isteğe bağlı olarak ölçeklendirilir.

İşlevler, bir HTTP isteği veya bir sıraya ulaşan ileti gibi bir dış tetikleyici gerçekleştiğinde yürütülür. Bu, sunucusuz mimarilere yönelik olay odaklı bir mimari stili doğal hale getirir. Mimarideki bileşenler arasında çalışmayı koordine etmek için ileti aracıları veya yayın/alt desenleri kullanmayı düşünün. Azure 'da mesajlaşma teknolojileri arasında seçim yapma konusunda yardım almak için bkz. iletileri teslim eden Azure hizmetleri arasında seçim.

Mimari

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

Blob Depolama. HTML, CSS ve JavaScript dosyaları gibi statik web içerikleri, Azure Blob Depolama depolanır ve statik web sitesi barındırmakullanılarak istemcilere sunulur. Tüm dinamik etkileşim, arka uç API 'Lerine çağrılar yapan JavaScript kodu aracılığıyla gerçekleşir. Web sayfasını işlemek için sunucu tarafı kod 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.

Işlev uygulamaları. Azure işlevleri , sunucusuz bir işlem seçeneğidir. Kod parçasının (bir "işlev") bir tetikleyici tarafından çağrıldığı olay temelli bir model kullanır. Bu mimaride, bir istemci bir HTTP isteği yaptığında işlev çağrılır. İstek her zaman aşağıda açıklanan bir API ağ geçidiyle yönlendirilir.

API Management. API Management , http işlevinin önünde bulunan 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. Bir ağ geçidi kullanmak, arka uç API 'Lerinden ön uç uygulamayı ayrışmanıza yardımcı olur. Örneğin API Management, URL 'Leri yeniden yazabilir, istekleri arka uca ulaşmadan önce dönüştürebilir, istek veya yanıt üst bilgilerini ayarlayabilir ve benzeri bir şekilde devam edebilir.

API Management, şu gibi çapraz kesme sorunları uygulamak için de kullanılabilir:

• Kullanım kotalarını ve oran sınırlarını zorlama
• Kimlik doğrulaması için OAuth belirteçleri doğrulanıyor
• Çıkış noktaları arası istekleri etkinleştirme (CORS)
• Önbelleğe Alma yanıtları
• İzleme ve günlüğe kaydetme istekleri

API Management tarafından sunulan tüm işlevlere ihtiyacınız yoksa, Işlev proxy 'lerikullanmak başka bir seçenektir. Azure Işlevlerinin bu özelliği, arka uç işlevlerine yönlendirmeler oluşturarak birden çok işlev uygulaması için tek bir API yüzeyi tanımlamanızı sağlar. İşlev proxy 'leri ayrıca HTTP isteği ve yanıtı üzerinde sınırlı dönüşümler gerçekleştirebilir. Ancak, API Management aynı zengin ilke tabanlı özellikleri sağlamaz.

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

Azure Active Directory (Azure AD). Kullanıcılar, Azure AD kimlik bilgilerini kullanarak Web uygulamasında oturum açabilirler. Azure AD, 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ğrulama).

Azure İzleyici. İzleme , çözümde dağıtılan Azure hizmetleriyle ilgili performans ölçümlerini toplar. Bunları bir panoda görselleştirerek çözümün sistem durumunu görebilirsiniz. Uygulama günlükleri de topladı.

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

GitHub eylemler. iş akışı , GitHub deponuzda ayarladığınız otomatik bir işlemdir (cı/CD). GitHub bir iş akışıyla bir proje oluşturabilir, test edebilir, paketler, serbest bırakabilir veya dağıtabilirsiniz.

Öneriler

İşlev Uygulaması planları

Azure Işlevleri iki barındırma modelini destekler. Tüketim planıile, kodunuz çalışırken işlem gücü otomatik olarak tahsis edilir. App Service planı ile kodunuz Için bir VM kümesi ayrılır. App Service planı, sanal makine sayısını ve VM boyutunu tanımlar.

App Service planının yukarıda verilen tanıma göre kesinlikle sunucusuzolmadığına unutmayın. Programlama modeli aynıdır, ancak aynı işlev kodu hem tüketim planında hem de App Service planında çalıştırılabilir.

Hangi tür bir plan kullanacağınızı seçerken göz önünde bulundurmanız gereken bazı etmenler aşağıda verilmiştir:

• Soğuk başlangıç. Tüketim planı ile, son çağrılmayan bir işlev, bir sonraki sefer çalıştırıldığında bazı ek gecikme süresine neden olur. Bu ek gecikme süresi, çalışma zamanı ortamının tahsisi ve hazırlanması nedeniyle yapılır. Genellikle saniye sırasına sahiptir, ancak yüklenmesi gereken bağımlılıkların sayısı dahil olmak üzere çeşitli etkenlere bağlıdır. Daha fazla bilgi için bkz. sunucusuz soğuk başlangıcını anlama. Soğuk başlatma, genellikle zaman uyumsuz ileti temelli iş yüklerinden (kuyruk veya Olay Hub 'ları), daha fazla gecikme süresi Kullanıcı tarafından gözlemlendiği için etkileşimli iş yükleri (HTTP Tetikleyicileri) ile ilgili bir kaygıdır.
• Zaman aşımı süresi. Tüketim planında, yapılandırılabilir bir süre sonra bir işlev yürütme zaman aşımına uğrar (en fazla 10 dakika)
• Sanal ağ yalıtımı. App Service planının kullanılması, işlevlerin adanmış ve yalıtılmış bir barındırma ortamı olan App Service ortamıiçinde çalışmasına izin verir.
• Fiyatlandırma modeli. Tüketim planı, yürütme sayısına ve kaynak tüketimine (bellek × yürütme süresi) göre faturalandırılır. App Service planı, VM örneği SKU 'SU temelinde saatlik olarak faturalandırılır. Genellikle, yalnızca kullandığınız işlem kaynakları için ödeme yaptığınız için tüketim planı bir App Service planından daha ucuz olabilir. Bu özellikle, trafiğiniz tepe KS ve Troughs deneyimliyse geçerlidir. Ancak, bir uygulama yüksek hacimlik verimlilik yaşıyorsa, bir App Service planı, tüketim planından daha az ücret alabilir.
• Ölçeklendirme. Tüketim modelinin büyük bir avantajı, gelen trafiğe göre gerektiği şekilde dinamik olarak ölçeklendirilemidir. Bu ölçekleme hızlı bir şekilde gerçekleşirken, hala bir artırma dönemi vardır. Bazı iş yükleri için, VM 'Leri kasıtlı olarak sağlamak isteyebilirsiniz. böylece, sıfır artırma zamanına sahip trafik yükünü işleyebilmenizi sağlayabilirsiniz. Bu durumda bir App Service planını göz önünde bulundurun.

İşlev Uygulaması sınırları

İşlev uygulaması bir veya daha fazla işlevin yürütülmesinibarındırır. Çeşitli işlevleri bir mantıksal birim olarak gruplamak için bir işlev uygulaması 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 gruplamak için işlev uygulamalarını kullanın. Aynı yaşam döngüsünü paylaşılmayan işlevlerin farklı işlev uygulamalarında barındırılması gerekir.

Her bir işlev uygulamasının, muhtemelen birçok ilgili işlevden oluşan bir mikro hizmeti temsil ettiği bir mikro hizmet yaklaşımı almayı göz önünde bulundurun. Mikro hizmet mimarisinde, hizmetlerde gevşek ve yüksek işlevli bir işlem olmalıdır. Gevşek olarak bağlanmış, diğer hizmetlerin aynı anda güncelleştirilmesini gerektirmeden tek bir hizmeti değiştirebileceðiniz anlamına gelir. Birlikte , bir hizmetin tek ve iyi tanımlanmış bir amacı olduğu anlamına gelir. Bu fikirler hakkında daha fazla bilgi için bkz. mikro hizmetler tasarlama: etki alanı analizi.

İşlev bağlamaları

Mümkün olduğunda Işlev bağlamalarını kullanın. Bağlamalar, kodunuzu verilere bağlamak ve diğer Azure hizmetleriyle bütünleştirmek için bildirim temelli bir yol sağlar. Giriş bağlama bir giriş parametresini dış veri kaynağından 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şlevi Cosmos DB GetStatuskullanır. bu bağlama, HTTP isteğindeki sorgu dizesinden alınan sorgu parametrelerini kullanarak Cosmos DB bir belgeyi aramak üzere yapılandırılmıştır. Belge bulunursa, işleve parametre olarak geçirilir.

[FunctionName("GetStatusFunction")]
public static Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [CosmosDB(
        databaseName: "%COSMOSDB_DATABASE_NAME%",
        collectionName: "%COSMOSDB_DATABASE_COL%",
        ConnectionStringSetting = "COSMOSDB_CONNECTION_STRING",
        Id = "{Query.deviceId}",
        PartitionKey = "{Query.deviceId}")] dynamic deviceStatus,
    ILogger log)
{
    ...
}

Bağlamaları kullanarak doğrudan hizmete iletişim kuran bir kod yazmanız gerekmez. Bu, işlev kodunu daha basit hale getiren ve ayrıca veri kaynağı veya havuzunun ayrıntılarını de soyutlayan bir 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, doğrudan Azure istemci SDK 'larını kullanın.

Ölçeklenebilirlik konusunda dikkat edilmesi gerekenler

İşlevler. Tüketim planı için, HTTP tetikleyicisi trafiğe göre ölçeklendirilir. Eşzamanlı işlev örneklerinin sayısı için 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 olabilen veya otomatik ölçeklendirme kuralları kümesine göre otomatik ölçeklendirme olabilen sanal makine örneklerinin sayısına göre ölçeklendirilir. Daha fazla bilgi için bkz. Azure işlevleri ölçeklendirme ve barındırma.

Cosmos DB. Cosmos DB için üretilen iş kapasitesi, istek birimleri (RU) cinsinden ölçülür. 1-RU üretilen iş hacmi, 4 KB 'lık bir belge almak için gereken iş hızına karşılık gelir. bir Cosmos DB kapsayıcısını 10.000 RU 'dan ö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 dahil etmeniz gerekir. bölüm anahtarları hakkında daha fazla bilgi için bkz. Azure Cosmos DB bölüm ve ölçek.

API Management. API Management, kural tabanlı otomatik ölçeklendirmeyi ölçeklendirebilir ve destekler. Ölçeklendirme işlemi en az 20 dakika sürer. Trafiğiniz burstise, beklediğinizi en fazla patlama trafiği için sağlamanız gerekir. Ancak otomatik ölçeklendirme, trafikte saatlik veya günlük değişimleri işlemek için faydalıdır. Daha fazla bilgi için bkz. Azure API Management örneğini otomatik olarak ölçeklendirme.

Olağanüstü durum kurtarmayla konusunda dikkat edilmesi gerekenler

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

• API Management, çok bölgeli dağıtımı destekler ve bu, herhangi bir sayıda Azure bölgesinde tek bir API Management örneği dağıtmak için kullanılabilir. 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 hale gelirse, Traffic Manager ikincil bir bölgeye yük devreder.

• Cosmos DB, Cosmos DB hesabınıza eklediğiniz herhangi bir bölgeye yazma sağlayan birden çok yazmabölgesini destekler. Çoklu yazma 'yı etkinleştirmezseniz, birincil yazma bölgesinin yükünü yine de devredesiniz. Cosmos DB istemci sdk 'ları ve Azure işlevi bağlamaları, yük devretmeyi otomatik olarak işler, bu nedenle herhangi bir uygulama yapılandırma ayarını güncelleştirmeniz gerekmez.

Güvenlik konuları

Kimlik Doğrulaması

GetStatusBaşvuru uygulamasındaki API, isteklerin kimliğini doğrulamak Için Azure ad kullanır. Azure AD, OAuth 2 protokolünün üzerine oluşturulmuş bir kimlik doğrulama protokolü olan openıd Bağlan protokolünü destekler.

Bu mimaride, istemci uygulaması tarayıcıda çalışan tek sayfalı bir uygulamadır (SPA). Bu tür istemci uygulaması, bir istemci gizli anahtarını veya bir yetkilendirme kodunu gizlemez, bu nedenle dolaylı verme akışı uygun olur. ( Hangi OAuth 2,0 akışının kullanmalıyım?). Genel akış aşağıdadır:

1. Kullanıcı Web uygulamasındaki "oturum aç" bağlantısına tıklar.
2. Tarayıcı Azure AD oturum açma sayfasına yeniden yönlendirilir.
3. Kullanıcı oturum açar.
4. Azure AD, URL parçasındaki bir erişim belirteci de dahil olmak üzere istemci uygulamasına yeniden yönlendirir.
5. Web uygulaması API 'yi çağırdığında, kimlik doğrulama üstbilgisinde 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:

• Azure AD kiracınıza bir uygulama kaydedin. Bu, istemcinin oturum açma URL 'SI ile içerdiği bir uygulama KIMLIĞI oluşturur.

• İşlev Uygulaması içinde Azure AD 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 Validate-JWT ilkesini API Management ekleyin.

daha fazla ayrıntı için GitHub benioku dosyasınabakın.

İstemci uygulaması ve arka uç API 'SI için Azure AD 'de ayrı uygulama kayıtları oluşturmanız önerilir. İstemci uygulamasına API çağrısı için izin verin. Bu yaklaşım, birden fazla API ve istemci tanımlama ve her biri için izinleri denetleme esnekliği sağlar.

Bir API içinde, uygulamalara Kullanıcı tarafından talep ettikleri izinleri ayrıntılı olarak denetlemek için kapsamları kullanın. Örneğin, bir API, Read ve Write kapsamlarına sahip olabilir ve belirli bir istemci uygulaması, kullanıcıdan yalnızca izinleri yetkilendirebilmesine sorun verebilir Read .

Yetkilendirme

Birçok uygulamada, arka uç API 'SI, bir kullanıcının belirli bir eylemi gerçekleştirme izni olup olmadığını denetmelidir. Kullanıcı hakkındaki bilgilerin kimlik sağlayıcısı (Bu durumda, Azure AD) tarafından geldiği ve yetkilendirme kararları almak için kullanıldığı, talep tabanlı yetkilendirmekullanılması önerilir. Örneğin, Azure AD 'de bir uygulamayı kaydettiğinizde, bir uygulama rolleri kümesi tanımlayabilirsiniz. Kullanıcı uygulamada oturum açtığında, Azure AD, roles grup üyeliğiyle devralınan roller de dahil olmak üzere, Kullanıcı tarafından verilen her rol için bir talep içerir.

Azure AD 'nin istemciye döndürdüğü KIMLIK belirteci, bazı Kullanıcı taleplerini içerir. İşlev uygulaması içinde bu talepler, isteğin X-MS-CLIENT-PRINCIPAL üst bilgisinde bulunur. Ancak, bu bilgileri bağlama verilerinden okumak daha basittir. diğer talepler için Microsoft Graph kullanarak Azure AD 'yi sorgulayın. (Kullanıcı oturum açarken bu eylemi kabul etmelidir.)

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

CORS

Bu başvuru mimarisinde, Web uygulaması ve API aynı kaynağı paylaşmaz. Bu, uygulama API 'yi çağırdığında, bir çapraz kaynak isteği 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ıtlamaya aynı-Origin ilkesi adı verilir ve kötü amaçlı bir sitenin başka bir siteden hassas verileri okumasını önler. Bir çapraz kaynak isteğini 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'dur. Bu, tarayıcıya kimlik bilgileri de dahil olmak üzere kimlik bilgilerini (tanımlama bilgileri dahil) göndermesini yetkilendirir. Aksi takdirde tarayıcı, varsayılan olarak, bir çapraz kaynak isteğiyle kimlik bilgileri göndermez.

HTTPS'yi zorunlu tutma

En yüksek güvenlik için istek ardışık düzeni boyunca HTTPS gerektir:

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

• Statik Web sitesi barındırma. Depolama hesabında "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 protokolünü kullanacak şekilde yapılandırın. Bunu Azure portal veya bir Kaynak Yöneticisi ş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 işlevleri. "Yalnızca https" ayarını etkinleştirin.

İşlev uygulamasını kilitle

İşleve yapılan tüm çağrılar API Gateway 'e gitmelidir. Bunu aşağıdaki gibi elde edebilirsiniz:

• İş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ı dahil eder. Bu, istemcilerin ağ geçidini atlayarak işlevi doğrudan aramasını engeller.

• API Management ağ geçidi statik bir IP adresinesahiptir. Azure Işlevini yalnızca bu statik IP adresinden gelen çağrılara izin verecek şekilde kısıtlayın. Daha fazla bilgi için bkz. Azure App Service STATIK IP kısıtlamaları. (Bu özellik yalnızca Standart katman hizmetleri için kullanılabilir.)

Uygulama parolalarını koruma

Veritabanı kimlik bilgileri gibi uygulama gizli dizilerini kodunuzda veya yapılandırma dosyalarınızda depolamamayın. Bunun yerine, Azure 'da şifrelenmiş olarak depolanan uygulama ayarlarını kullanın. Daha fazla bilgi için bkz. Azure App Service ve Azure Işlevlerinde güvenlik.

Alternatif olarak, Key Vault içinde uygulama gizli dizileri de saklayabilirsiniz. Bu, parolaların depolanmasını merkezileştirmenizi, dağıtımını denetlemenizi ve gizli dizileri nasıl ve ne zaman erişildiğini izlemenizi sağlar. Daha fazla bilgi için bkz. bir Azure Web uygulamasını Key Vault gizli dizi okumak Için yapılandırma. Ancak, Tetikleyicilerin ve bağlamaların yapılandırma ayarlarını uygulama ayarlarından yüklediğine unutmayın. Tetikleyicileri ve bağlamaları Key Vault gizli dizileri kullanacak şekilde yapılandırmanın yerleşik bir yolu yoktur.

DevOps için dikkat edilmesi gerekenler

Ö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 olmak üzere tek sayfalı bir uygulamadır. Bu tür bir uygulamayla ilgili bazı önemli noktalar aşağıda verilmiştir:

• uygulamayı, genel kullanıma açık bir CDN, bulutta barındırılan statik içeriğe sahip geniş bir coğrafi bölge üzerinden kullanıcılara tek bir şekilde dağıtın. Bu, adanmış bir Web sunucusu gereksinimini ortadan kaldırır. başlamak için Azure CDN ile bir Azure depolama hesabını tümleştirin ' i okuyun. Uygulamanızı httpsile güvenli hale getirin. Ek öneriler için içerik teslim ağlarını kullanmaya yönelik en iyi uygulamaları okuyun.
• her kaynak değişikliğini otomatik olarak derlemek ve dağıtmak için Azure Pipelines veya GitHub eylemlerigibi hızlı ve güvenilir bir cı/CD hizmeti kullanın. Kaynak, çevrimiçi bir sürüm denetim sisteminde bulunmalıdır. Azure Pipelines hakkında daha fazla bilgi için ilk işlem hattınızı oluşturmamakalesini okuyun. azure 'a yönelik GitHub eylemler hakkında daha fazla bilgi edinmek için bkz. azure 'a uygulama dağıtma.
• CDN 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 edge sunucularında anında sıkıştırmayaizin verir. Alternatif olarak, bu başvuru mimarisinde 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çmek için daha fazla özgürlük sağlar.
• CDN, tüm kullanıcıların en güncel içeriği sunulmasını sağlamak için önbelleğini temizlemelidir . Derleme ve dağıtım işlemlerinin atomik olmaması halinde bir önbellek temizliği gerekir, örneğin eski dosyaları aynı kaynak klasöründeki yeni yerleşik olanlarla değiştirir.
• Dizinler kullanılarak 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 bir atomik birim olarak yüklenir. Azure CDN, bu yeni sürüme yalnızca tamamlanan bir dağıtımdan sonra işaret eder.
• Kaynak dosyalarını daha uzun bir süre boyunca önbelleğe alarak önbellek TTL 'sini artırın. Önbelleğe alınan dosyaların değişdikleri sırada güncelleştirildiğinden emin olmak için dosya adlarını yeniden inşa edildiğinde parmak izi. Bu ön uç uygulaması parmak izi index.htmlgibi herkese açık dosyalar hariç tüm dosyaları yazdırır. index.html sıklıkla güncelleştirildiğinden, değiştirilen dosya adlarını yansıtır ve bu da önbellek yenilemeye neden olur. daha fazla bilgi için Azure CDN web içeriğinin kullanım süresini yönetme bölümüne bakın.

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 zıp dosyası yüklersiniz ve işlevler çalışma zamanı zıp dosyasını salt bir dosya sistemi olarak takar. Bu, başarısız bir dağıtımın uygulamayı tutarsız bir durumda bırakacağı olasılığını azaltan atomik bir işlemdir. Tüm dosyalar bir kez takas edildiği için, özellikle Node.js uygulamalar için soğuk başlangıç zamanlarını da geliştirebilirsiniz.

API sürümü oluşturma

API, bir hizmet ve istemciler arasındaki bir sözleşmedir. Bu mimaride, API sözleşmesi API Management katmanında tanımlanmıştır. API Management, iki ayrı ancak tamamlayıcı Sürüm kavramlarınıdestekler:

• Sürümler , API tüketicilerinin v1 ve v2 gibi ihtiyaçlarını temel alarak bir API sürümü seçmesine olanak sağlar.

• Düzeltmeler , API yöneticilerinin DEĞIŞIKLIKLER hakkında API tüketicilerini bilgilendirmek IÇIN bir API 'de önemli olmayan değişiklikler yapmasına ve bu değişiklikleri dağıtmasına imkan tanır.

Bir API 'de Son değişiklik yaparsanız, API Management yeni bir sürüm yayımlayın. Yeni sürümü, özgün sürümle ayrı bir İşlev Uygulaması yan yana dağıtın. Bu, mevcut istemcileri, istemci uygulamalarını bozmadan yeni API 'ye geçirmenize olanak sağlar. Sonuç olarak, önceki sürümü kullanımdan kaldırabilirsiniz. API Management, çeşitli sürüm oluşturma düzenlerinidestekler: URL yolu, http üstbilgisi veya sorgu dizesi. API sürümü oluşturma hakkında daha fazla bilgi için bkz. Restsize bir Web API 'Sinin sürümü oluşturma.

API değişikliklerini bozmayan güncelleştirmeler için, yeni sürümü aynı İşlev Uygulaması bir hazırlama yuvasına dağıtın. Dağıtımın başarılı olduğunu doğrulayın ve ardından hazırlanan sürümü üretim sürümü ile değiştirin. API Management bir düzeltme yayımlayın.

Maliyetle ilgili konular

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 Işlevleri iki barındırma modelini destekler.

• Tüketim planı.

  İşlem gücü, kodunuz çalışırken otomatik olarak ayrılır.

• Planı App Service .

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

Bu mimaride, istemci bir HTTP isteği yaptığında bir işlev çağrılır. Bu kullanım durumunda sabit bir yüksek hacme performansı 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

sağlanan aktarım hızı ve depolama alanı saate göre tüketilen Azure Cosmos DB. Sağlanan verimlilik, saniye başına Istek birimi (RU/s) olarak ifade edilir ve bunlar ekleme, okuma gibi tipik veritabanı işlemleri için kullanılabilir. Fiyat, ayırdığınızın RU/sn cinsinden kapasitesini temel alır.

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

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

bu mimaride, işlev uygulaması istemciden gelen HTTP GET isteklerine yanıt olarak Cosmos DB belgeleri getirir. okuma işlemleri RU/s üzerinde ifade edilen yazma işlemlerinden çok önemli bir değer olduğundan, bu durumda Cosmos DB ücret geçerlidir.

Content Delivery Network

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

Bu başvuru mimarisinde, dağıtım tek bir Azure bölgesinde yer alır.

Maliyetleri düşürmek için, kaynak dosyalarını daha uzun bir süre önbelleğe alarak ve İçerikleriniz için mümkün olan en uzun TTL 'yi ayarlayarak önbellek TTL 'sini artırmayı düşünün.

daha fazla bilgi için Microsoft Azure Well-Architected Framework 'ünmaliyet bölümüne bakın.

Çözümü dağıtma

bu mimariye yönelik başvuru uygulamasını dağıtmak için GitHub benioku dosyasınabakın.

Sonraki adımlar

Başvuru uygulaması hakkında daha fazla bilgi edinmek için, Azure işlevleri Ile sunucusuz uygulamamakalesini okuyun.

İlgili rehberlik:

• CDNs kullanmaya yönelik en iyi uygulamalar
• Statik İçerik Barındırma düzeni