Düzenle

Aracılığıyla paylaş


Azure Service Fabric üzerinde mikro hizmet mimarisi

Azure API Management
Azure Key Vault
Azure Monitor
Azure Pipelines
Azure Service Fabric

Bu başvuru mimarisi, Azure Service Fabric'e dağıtılan bir mikro hizmet mimarisini gösterir. Çoğu dağıtım için başlangıç noktası olabilecek temel bir küme yapılandırmasını gösterir.

GitHub logosuBu mimarinin başvuru uygulaması GitHub'da kullanılabilir.

Mimari

Service Fabric başvuru mimarisini gösteren diyagram.

Bu mimarinin bir Visio dosyasını indirin.

Not

Bu makale, Service Fabric için Reliable Services programlama modeline odaklanır. Kapsayıcıları dağıtmak ve yönetmek için Service Fabric kullanmak bu makalenin kapsamının dışındadır.

İş Akışı

Mimari aşağıdaki bileşenlerden oluşur. Diğer terimler için bkz . Service Fabric terminolojiye genel bakış.

  • Service Fabric kümesi. Küme, mikro hizmetlerinizi dağıtıp yönettiğiniz ağa bağlı bir sanal makine kümesidir.

  • Sanal makine ölçek kümeleri. Sanal makine ölçek kümeleri özdeş, yük dengeli ve otomatik ölçeklendirme VM'lerinden oluşan bir grup oluşturup yönetmenizi sağlar. Bu işlem kaynakları hata ve yükseltme etki alanlarını da sağlar.

  • Düğümler. Düğümler, Service Fabric kümesine ait vm'lerdir.

  • Düğüm türleri. Düğüm türü, düğüm koleksiyonunu dağıtan bir sanal makine ölçek kümesini temsil eder. Service Fabric kümesinin en az bir düğüm türü vardır.

    Birden çok düğüm türü olan bir kümede , birincil düğüm türü bildirilmelidir. Kümedeki birincil düğüm türü Service Fabric sistem hizmetlerini çalıştırır. Bu hizmetler Service Fabric'in platform özelliklerini sağlar. Birincil düğüm türü, temel alınan kümenin kullanılabilirliğini koruyan düğümler olan çekirdek düğümleri olarak da görev yapar.

    Hizmetlerinizi çalıştırmak için ek düğüm türlerini yapılandırın.

  • Hizmetler. Hizmet, diğer hizmetlerden bağımsız olarak başlatabilen ve çalıştırabilen tek başına bir işlev gerçekleştirir. Hizmet örnekleri kümedeki düğümlere dağıtılır. Service Fabric'te iki çeşit hizmet vardır:

    • Durum bilgisi olmayan hizmet. Durum bilgisi olmayan bir hizmet, hizmet içinde durumu korumaz. Durum kalıcılığı gerekiyorsa durum, Azure Cosmos DB gibi bir dış depoya yazılır ve bu depodan alınır.
    • Durum bilgisi olan hizmet. Hizmet durumu hizmetin kendi içinde tutulur. Durum bilgisi olan hizmetlerin çoğu bunu Service Fabric'teki Reliable Collections aracılığıyla uygular.
  • Service Fabric Explorer. Service Fabric Explorer , Service Fabric kümelerini incelemeye ve yönetmeye yönelik açık kaynak bir araçtır.

  • Azure Pipelines. Azure Pipelines, Azure DevOps Services'ın bir parçasıdır ve otomatik derlemeler, testler ve dağıtımlar çalıştırır. Jenkins gibi üçüncü taraf sürekli tümleştirme ve sürekli teslim (CI/CD) çözümlerini de kullanabilirsiniz.

  • Azure İzleyici. Azure İzleyici , çözüm ve uygulama telemetrisindeki Azure hizmetleri için platform ölçümleri de dahil olmak üzere ölçümleri ve günlükleri toplar ve depolar. Uygulamayı izlemek, uyarıları ve panoları ayarlamak ve hataların kök neden analizini gerçekleştirmek için bu verileri kullanın. Azure İzleyici, kapsayıcı ve düğüm günlüklerinin yanı sıra denetleyicilerden, düğümlerden ve kapsayıcılardan ölçüm toplamak için Service Fabric ile tümleşir.

  • Azure Key Vault. Mikro hizmetlerin kullandığı bağlantı dizesi gibi uygulama gizli dizilerini depolamak için Key Vault'ı kullanın.

  • Azure API Management. Bu mimaride API Management, istemcilerden gelen istekleri kabul eden ve bunları hizmetlerinize yönlendiren bir API ağ geçidi işlevi görür.

Dikkat edilmesi gereken noktalar

Bu önemli noktalar, bir iş yükünün kalitesini artırmaya yönelik bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular.

Tasarımla ilgili dikkat edilecek noktalar

Bu başvuru mimarisi mikro hizmet mimarilerine odaklanmıştır. Mikro hizmet, küçük, bağımsız olarak sürümlenmiş bir kod birimidir. Hizmet bulma mekanizmaları aracılığıyla bulunabilir ve API'ler üzerinden diğer hizmetlerle iletişim kurabilir. Her bir hizmet bağımsızdır ve tek bir iş özelliğini uygulamalıdır. Uygulama etki alanınızı mikro hizmetlere ayırma hakkında daha fazla bilgi için bkz . Mikro hizmetleri modellemek için etki alanı analizini kullanma.

Service Fabric mikro hizmetleri verimli bir şekilde oluşturmak, dağıtmak ve yükseltmek için bir altyapı sağlar. Ayrıca otomatik ölçeklendirme, durumu yönetme, sistem durumunu izleme ve hata durumunda hizmetleri yeniden başlatma seçenekleri sağlar.

Service Fabric, bir uygulamanın mikro hizmet koleksiyonu olduğu bir uygulama modelini izler. Uygulama, bir uygulama bildirim dosyasında açıklanmıştır. Bu dosya, bağımsız hizmet paketlerine yönelik işaretçilerle birlikte uygulamanın içerdiği hizmet türlerini tanımlar.

Uygulama paketi genellikle hizmetlerin kullandığı belirli ayarlar için geçersiz kılma görevi görecek parametreler içerir. Her hizmet paketinde ikili dosyalar, yapılandırma dosyaları ve salt okunur veriler de dahil olmak üzere bu hizmeti çalıştırmak için gereken fiziksel dosya ve klasörleri açıklayan bir bildirim dosyası vardır. Hizmetler ve uygulamalar bağımsız olarak sürümlenir ve yükseltilebilir.

İsteğe bağlı olarak, uygulama bildirimi, uygulamanın bir örneği oluşturulduğunda otomatik olarak sağlanan hizmetleri açıklayabilir. Bunlara varsayılan hizmetler denir. Bu durumda, uygulama bildirimi bu hizmetlerin nasıl oluşturulması gerektiğini de açıklar. Bu bilgiler hizmetin adını, örnek sayısını, güvenlik veya yalıtım ilkesini ve yerleştirme kısıtlamalarını içerir.

Not

Hizmetlerinizin kullanım ömrünü denetlemek istiyorsanız varsayılan hizmetleri kullanmaktan kaçının. Varsayılan hizmetler, uygulama oluşturulduğunda oluşturulur ve uygulama çalıştığı sürece çalışır.

Daha fazla bilgi için bkz. Service Fabric hakkında bilgi edinmek mi istiyorsunuz?

Uygulamadan hizmete paketleme modeli

Mikro hizmetlerin bir ağı, her hizmetin bağımsız olarak dağıtılabilmesidir. Service Fabric'te tüm hizmetlerinizi tek bir uygulama paketinde gruplandırırsanız ve bir hizmet yükseltilemezse, uygulama yükseltmesinin tamamı geri alınır. Bu geri alma, diğer hizmetin yükseltilmemesini engeller.

Bu nedenle, mikro hizmetler mimarisinde birden çok uygulama paketi kullanmanızı öneririz. Bir veya daha fazla yakından ilişkili hizmet türünü tek bir uygulama türüne yerleştirin. Örneğin, ekibiniz şu özniteliklerden birine sahip bir hizmet kümesinden sorumluysa hizmet türlerini aynı uygulama türüne yerleştirin:

  • Bunlar aynı süre boyunca çalışır ve aynı anda güncelleştirilmeleri gerekir.
  • Bunlar aynı yaşam döngüsüne sahiptir.
  • Bağımlılıklar veya yapılandırma gibi kaynakları paylaşırlar.

Service Fabric programlama modelleri

Service Fabric uygulamasına mikro hizmet eklediğinizde, yüksek oranda kullanılabilir ve güvenilir hale getirilmesi gereken durum veya verilere sahip olup olmadığına karar verin. Öyleyse, verileri harici olarak depolayabilir mi yoksa veriler hizmetin bir parçası olarak mı barındırılır? Verileri depolamanız gerekmiyorsa veya verileri dış depolama alanında depolamak istiyorsanız durum bilgisi olmayan bir hizmet seçin. Bu deyimlerden biri geçerliyse durum bilgisi olan bir hizmet seçmeyi göz önünde bulundurun:

  • Hizmetin bir parçası olarak durumu veya verileri korumak istiyorsunuz. Örneğin, bu verilerin koda yakın bellekte bulunması gerekir.
  • Dış depoya bağımlılığı tolere edemezsiniz.

Service Fabric'te çalıştırmak istediğiniz mevcut kodunuz varsa, bunu konuk yürütülebilir dosyası olarak çalıştırabilirsiniz: hizmet olarak çalışan rastgele bir yürütülebilir dosya. Alternatif olarak, yürütülebilir dosyayı dağıtım için ihtiyacınız olan tüm bağımlılıkları içeren bir kapsayıcıda paketleyebilirsiniz.

Service Fabric hem kapsayıcıları hem de konuk yürütülebilir dosyaları durum bilgisi olmayan hizmetler olarak modeller. Model seçme yönergeleri için bkz . Service Fabric programlama modeline genel bakış.

Konuk yürütülebilir dosyasının çalıştırıldığı ortamı korumak sizin sorumluluğundadır. Örneğin, konuk yürütülebilir dosyasının Python gerektirdiğini varsayalım. Yürütülebilir dosya kendi içinde değilse, gerekli Python sürümünün ortamda önceden yüklendiğinden emin olmanız gerekir. Service Fabric ortamı yönetmez. Azure, ortamı ayarlamak için özel sanal makine görüntüleri ve uzantıları dahil olmak üzere birden çok mekanizma sunar.

Bir konuk yürütülebilir dosyaya ters ara sunucu üzerinden erişmek içinEndpoint, konuk yürütülebilir dosyasının hizmet bildirimindeki öğesine özniteliğini eklediğinizden UriScheme emin olun.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Hizmetin ek yolları varsa, değerdeki PathSuffix yolları belirtin. Değere eğik çizgi (/ ) eklenmemeli veya soneklenmemelidir. Bir diğer yol da yolu hizmet adına eklemektir.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Daha fazla bilgi için bkz.

API ağ geçidi

Api ağ geçidi (giriş), dış istemcilerle mikro hizmetler arasında yer alır. İstemcilerden gelen istekleri mikro hizmetlere yönlendiren ters ara sunucu işlevi görür. Ayrıca kimlik doğrulaması, SSL sonlandırma ve hız sınırlama gibi çapraz kesme görevleri de gerçekleştirebilir.

Çoğu senaryo için Azure API Management'ı öneririz, ancak Traefik popüler bir açık kaynak alternatifidir. Her iki teknoloji seçeneği de Service Fabric ile tümleştirilir.

  • API Management. Genel IP adresini kullanıma sunar ve trafiği hizmetlerinize yönlendirir. Service Fabric kümesiyle aynı sanal ağda ayrılmış bir alt ağda çalışır.

    API Management, özel IP adresine sahip bir yük dengeleyici aracılığıyla kullanıma sunulan düğüm türündeki hizmetlere erişebilir. Bu seçenek yalnızca API Management'ın Premium ve Geliştirici katmanlarında kullanılabilir. Üretim iş yükleri için Premium katmanını kullanın. Fiyatlandırma bilgileri API Management fiyatlandırması bölümünde açıklanmıştır.

    Daha fazla bilgi için bkz . Azure API Management ile Service Fabric'e genel bakış.

  • Traefik'e. Yönlendirme, izleme, günlükler ve ölçümler gibi özellikleri destekler. Traefik, Service Fabric kümesinde durum bilgisi olmayan bir hizmet olarak çalışır. Hizmet sürümü oluşturma, yönlendirme aracılığıyla desteklenebilir.

    Hizmet girişi ve küme içinde ters ara sunucu olarak Traefik'i ayarlama hakkında bilgi için Traefik web sitesindeki Azure Service Fabric Sağlayıcısı'na bakın. Traefik'i Service Fabric ile kullanma hakkında daha fazla bilgi için, Traefik ile Service Fabric'te akıllı yönlendirme blog gönderisine bakın.

Traefik, Azure API Management'tan farklı olarak, bir isteğin yönlendirildiği durum bilgisi olan bir hizmetin (birden fazla bölüme sahip) bölümünü çözümleme işlevselliğine sahip değildir. Daha fazla bilgi için bkz . Bölümleme hizmetleri için eşleştirici ekleme.

Diğer API yönetimi seçenekleri arasında Azure Uygulaması lication Gateway ve Azure Front Door yer alır. Yönlendirme, SSL sonlandırma ve güvenlik duvarı gibi görevleri gerçekleştirmek için bu hizmetleri API Management ile birlikte kullanabilirsiniz.

Hizmetler arası iletişim

Hizmet-hizmet iletişimini kolaylaştırmak için aşağıdaki önerileri göz önünde bulundurun:

  • İletişim protokolü. Mikro hizmetler mimarisinde hizmetlerin çalışma zamanında en düşük bağlantı ile birbirleriyle iletişim kurması gerekir. Dilden bağımsız iletişimi etkinleştirmek için HTTP, farklı dillerde kullanılabilen çok çeşitli araçlara ve HTTP sunucularına sahip bir endüstri standardıdır. Service Fabric bu araçların ve sunucuların tümünü destekler.

    Çoğu iş yükü için, Service Fabric'te yerleşik olarak bulunan hizmet uzaktan iletişim yerine HTTP kullanmanızı öneririz.

  • Hizmet bulma. Bir kümedeki diğer hizmetlerle iletişim kurmak için istemci hizmetinin hedef hizmetin geçerli konumunu çözümlemesi gerekir. Service Fabric'te hizmetler düğümler arasında hareket edebilir ve hizmet uç noktalarının dinamik olarak değişmesine neden olabilir.

    Eski uç noktalara bağlantılardan kaçınmak için, güncelleştirilmiş uç nokta bilgilerini almak için Service Fabric'teki adlandırma hizmetini kullanabilirsiniz. Ancak Service Fabric, adlandırma hizmetini soyutlayan yerleşik bir ters proxy hizmeti de sağlar. Kullanımı daha kolay olduğundan ve daha basit bir kodla sonuçlanacağından çoğu senaryo için temel olarak hizmet bulma için bu seçeneği öneririz.

Hizmetler arası iletişim için diğer seçenekler şunlardır:

Ölçeklenebilirlik

Service Fabric şu küme varlıklarının ölçeklendirilmelerini destekler:

  • Her düğüm türü için düğüm sayısını ölçeklendirme
  • Hizmetleri ölçeklendirme

Bu bölüm otomatik ölçeklendirmeye odaklanmıştır. Uygun durumlarda el ile ölçeklendirmeyi seçebilirsiniz. Örneğin, örnek sayısını ayarlamak için el ile müdahale gerekebilir.

Ölçeklenebilirlik için ilk küme yapılandırması

Service Fabric kümesi oluşturduğunuzda, düğüm türlerini güvenlik ve ölçeklenebilirlik gereksinimlerinize göre sağlayın. Her düğüm türü bir sanal makine ölçek kümesine eşlenir ve bağımsız olarak ölçeklendirilebilir.

  • Farklı ölçeklenebilirlik veya kaynak gereksinimleri olan her hizmet grubu için bir düğüm türü oluşturun. Service Fabric sistem hizmetleri için bir düğüm türü (birincil düğüm türü olur) sağlayarak başlayın. Genel veya ön uç hizmetlerinizi çalıştırmak için ayrı düğüm türleri oluşturun. Arka ucunuz ve özel veya yalıtılmış hizmetleriniz için gereken diğer düğüm türlerini oluşturun. Hizmetlerin yalnızca hedeflenen düğüm türlerine dağıtılması için yerleştirme kısıtlamalarını belirtin.
  • Her düğüm türü için dayanıklılık katmanını belirtin. Dayanıklılık katmanı, Service Fabric'in sanal makine ölçek kümelerindeki güncelleştirmeleri ve bakım işlemlerini etkileme özelliğini temsil eder. Üretim iş yükleri için Bir Silver veya daha yüksek dayanıklılık katmanı seçin. Her katman hakkında bilgi için bkz . Kümenin dayanıklılık özellikleri.
  • Bronz dayanıklılık katmanını kullanıyorsanız, bazı işlemler için el ile adımlar gerekir. Bronz dayanıklılık katmanına sahip düğüm türleri, ölçeklendirme sırasında ek adımlar gerektirir. Ölçeklendirme işlemleri hakkında daha fazla bilgi için bu kılavuza bakın.

Düğümleri ölçeklendirme

Service Fabric, ölçeği daraltma ve ölçeği genişletme için otomatik ölçeklendirmeyi destekler. Her düğüm türünü otomatik ölçeklendirme için bağımsız olarak yapılandırabilirsiniz.

Her düğüm türünün en fazla 100 düğümü olabilir. Daha küçük bir düğüm kümesiyle başlayın ve yüklemenize bağlı olarak daha fazla düğüm ekleyin. Bir düğüm türünde 100'den fazla düğüm gerekiyorsa, daha fazla düğüm türü eklemeniz gerekir. Ayrıntılar için bkz . Service Fabric küme kapasitesi planlama konuları. Sanal makine ölçek kümesi anında ölçeklendirilmediğinden, otomatik ölçeklendirme kurallarını ayarlarken bu faktörü göz önünde bulundurun.

Otomatik ölçeklendirmeyi desteklemek için düğüm türünü Silver veya Gold dayanıklılık katmanına sahip olacak şekilde yapılandırın. Bu yapılandırma, Service Fabric hizmetleri yeniden konumlandırmayı tamamlayana kadar içinde ölçeklendirmenin gecikmeli olmasını sağlar. Ayrıca, sanal makine ölçek kümelerinin Yalnızca geçici olarak değil, VM'lerin kaldırıldığını Service Fabric'e bildirmesini de sağlar.

Düğüm veya küme düzeyinde ölçeklendirme hakkında daha fazla bilgi için bkz . Azure Service Fabric kümelerini ölçeklendirme.

Hizmetleri ölçeklendirme

Durum bilgisi olmayan ve durum bilgisi olan hizmetler ölçeklendirmeye farklı yaklaşımlar uygular.

Durum bilgisi olmayan bir hizmet için (otomatik ölçeklendirme):

  • Ortalama bölüm yükü tetikleyicisini kullanın. Bu tetikleyici, ölçeklendirme ilkesinde belirtilen bir yük eşiği değerine göre hizmetin ölçeğinin ne zaman genişletileceğini belirler. Tetikleyicinin ne sıklıkta denetlenebileceğini de ayarlayabilirsiniz. Bkz . Örnek tabanlı ölçeklendirme ile ortalama bölüm yükü tetikleyicisi. Bu yaklaşım, kullanılabilir düğüm sayısını artırmanıza olanak tanır.
  • Hizmet bildiriminde -1 olarak ayarlayın InstanceCount ve Service Fabric'e hizmetin bir örneğini her düğümde çalıştırmasını söyler. Bu yaklaşım, küme ölçeklendikçe hizmetin dinamik olarak ölçeklendirilmesini sağlar. Kümedeki düğüm sayısı değiştikçe Service Fabric, eşleşecek hizmet örneklerini otomatik olarak oluşturur ve siler.

Not

Bazı durumlarda hizmetinizi el ile ölçeklendirmek isteyebilirsiniz. Örneğin, Azure Event Hubs'dan okuyan bir hizmetiniz varsa, her olay hub'ı bölümünden ayrılmış bir örneğin okumasını isteyebilirsiniz. Bu şekilde, bölüme eşzamanlı erişimi önleyebilirsiniz.

Durum bilgisi olan bir hizmet için ölçeklendirme, bölüm sayısı, her bölümün boyutu ve makinede çalıştırılan bölüm veya çoğaltma sayısıyla denetlenmektedir:

  • Bölümlenmiş hizmetler oluşturuyorsanız, her düğümün kaynak çakışmalarına neden olmadan iş yükünün eşit dağıtımı için yeterli çoğaltmaları aldığından emin olun. Daha fazla düğüm eklerseniz, Service Fabric iş yüklerini varsayılan olarak yeni makinelere dağıtır. Örneğin, 5 düğüm ve 10 bölüm varsa, Service Fabric her düğüme varsayılan olarak iki birincil çoğaltma yerleştirir. Düğümlerin ölçeğini genişletirseniz, çalışma daha fazla kaynak arasında eşit olarak dağıtıldığı için daha yüksek performans elde edebilirsiniz.

    Bu stratejiden yararlanan senaryolar hakkında bilgi için bkz . Service Fabric'te ölçeklendirme.

  • Bölümlerin eklenmesi veya kaldırılması iyi desteklenmiyor. Ölçeklendirmek için yaygın olarak kullanılan bir diğer seçenek de hizmetleri veya uygulama örneklerinin tamamını dinamik olarak oluşturmak veya silmektir. Bu desene bir örnek, yeni adlandırılmış hizmetler oluşturarak veya kaldırarak Ölçeklendirme bölümünde açıklanmıştır.

Daha fazla bilgi için bkz.

Yükü dengelemek için ölçümleri kullanma

Bölümü nasıl tasarladığınıza bağlı olarak, diğerlerinden daha fazla trafik alan çoğaltmalara sahip düğümleriniz olabilir. Bu durumu önlemek için hizmet durumunu tüm bölümlere dağıtılması için bölümleyin. İyi bir karma algoritmasıyla aralık bölümleme düzenini kullanın. Bkz . Bölümlemeye başlama.

Service Fabric, bir küme içinde hizmetleri yerleştirmeyi ve dengelemeyi öğrenmek için ölçümleri kullanır. Hizmet oluşturulduğunda bir hizmetle ilişkili her ölçüm için varsayılan bir yük belirtebilirsiniz. Ardından Service Fabric, hizmeti yerleştirirken veya kümedeki düğümleri dengelemek için hizmetin taşınması gerektiğinde (örneğin yükseltmeler sırasında) bu yükü dikkate alır.

Bir hizmet için başlangıçta belirtilen varsayılan yük, hizmetin ömrü boyunca değişmez. Bir hizmetin değişen ölçümlerini yakalamak için hizmetinizi izlemenizi ve ardından yükü dinamik olarak raporlamanızı öneririz. Bu yaklaşım, Service Fabric'in belirli bir zamanda bildirilen yüke göre ayırmayı ayarlamasına olanak tanır. Özel ölçümleri raporlamak için IServicePartition.ReportLoad yöntemini kullanın. Daha fazla bilgi için bkz . Dinamik yük.

Kullanılabilirlik

Hizmetlerinizi birincil düğüm türünden farklı bir düğüm türüne yerleştirin. Service Fabric sistem hizmetleri her zaman birincil düğüm türüne dağıtılır. Hizmetleriniz birincil düğüm türüne dağıtılırsa, kaynaklar için sistem hizmetleriyle rekabet edebilir (ve müdahale edebilir). Bir düğüm türünün durum bilgisi olan hizmetleri barındırması bekleniyorsa en az beş düğüm örneği olduğundan ve Silver veya Gold dayanıklılık katmanını seçtiğinizden emin olun.

Hizmetlerinizin kaynaklarını kısıtlamayı göz önünde bulundurun. Bkz. Kaynak idare mekanizması.

Sık dikkat edilmesi gereken noktalar şunlardır:

  • Kaynak idaresi olan hizmetleri ve aynı düğüm türünde yönetilmeyen hizmetleri karıştırmayın. yönetilmeyen hizmetler çok fazla kaynak tüketebilir ve idare edilen hizmetleri etkileyebilir. Bu hizmet türlerinin aynı düğüm kümesinde çalışmadığından emin olmak için yerleştirme kısıtlamalarını belirtin. (Bu, Bölme ucu deseni.)
  • Bir hizmet örneği için ayırılacak CPU çekirdeklerini ve belleği belirtin. Kaynak idare ilkelerinin kullanımı ve sınırlamaları hakkında bilgi için bkz . Kaynak idaresi.

Tek bir hata noktasını (SPOF) önlemek için her hizmetin hedef örneğinin veya çoğaltma sayısının birden büyük olduğundan emin olun. Hizmet örneği veya çoğaltma sayısı olarak kullanabileceğiniz en büyük sayı, hizmeti kısıtlayan düğüm sayısına eşittir.

Durum bilgisi olan her hizmetin en az iki etkin ikincil çoğaltması olduğundan emin olun. Üretim iş yükleri için beş çoğaltma öneririz.

Daha fazla bilgi için bkz . Service Fabric hizmetlerinin kullanılabilirliği.

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ış.

Service Fabric'te uygulamanızın güvenliğini sağlamaya yönelik bazı önemli noktalar aşağıdadır.

Sanal ağ

İletişim akışını denetlemek için her sanal makine ölçek kümesi için alt ağ sınırları tanımlamayı göz önünde bulundurun. Her düğüm türünün Service Fabric kümesinin sanal ağı içindeki bir alt ağda kendi sanal makine ölçek kümesi vardır. Ağ trafiğine izin vermek veya trafiği reddetmek için alt ağlara ağ güvenlik grupları (NSG) ekleyebilirsiniz. Örneğin, ön uç ve arka uç düğüm türleriyle, yalnızca ön uç alt ağından gelen trafiği kabul etmek için arka uç alt ağına bir NSG ekleyebilirsiniz.

Kümeden dış Azure hizmetlerini çağırırken, Azure hizmeti destekliyorsa sanal ağ hizmet uç noktalarını kullanın. Hizmet uç noktasının kullanılması, hizmetin yalnızca kümenin sanal ağına güvenliğini sağlar.

Örneğin, verileri depolamak için Azure Cosmos DB kullanıyorsanız Azure Cosmos DB hesabını yalnızca belirli bir alt ağdan erişime izin verecek şekilde bir hizmet uç noktasıyla yapılandırın. Bkz. Sanal ağlardan Azure Cosmos DB kaynaklarına erişme.

Uç noktalar ve hizmetler arası iletişim

Güvenli olmayan bir Service Fabric kümesi oluşturmayın. Küme yönetim uç noktalarını genel İnternet'te kullanıma sunarsa anonim kullanıcılar buna bağlanabilir. Güvenli olmayan kümeler üretim iş yükleri için desteklenmez. Bkz. Service Fabric kümesi güvenlik senaryoları.

Hizmetler arası iletişimlerinizin güvenliğini sağlamaya yardımcı olmak için:

  • ASP.NET Core veya Java web hizmetlerinizde HTTPS uç noktalarını etkinleştirmeyi göz önünde bulundurun.
  • Ters proxy ile hizmetler arasında güvenli bir bağlantı kurun. Ayrıntılar için bkz . Güvenli bir hizmete bağlanma.

API ağ geçidi kullanıyorsanız, kimlik doğrulamasını ağ geçidine boşaltabilirsiniz. İletilerin kimliğini doğrulamak için ek güvenlik sağlanmadığı sürece tek tek hizmetlere doğrudan (API ağ geçidi olmadan) ulaşılamadığından emin olun.

Service Fabric ters ara sunucusunu genel kullanıma sunma. Bunun yapılması, HTTP uç noktalarını kullanıma sunan tüm hizmetlerin küme dışından ele alınabilmesine neden olur. Bu, güvenlik açıklarına neden olur ve gereksiz yere küme dışında ek bilgiler ortaya çıkarabilir. Bir hizmete genel olarak erişmek istiyorsanız API ağ geçidi kullanın. Bu makalenin devamında yer alan API ağ geçidi bölümünde bazı seçeneklerden bahsedilmiştir.

Uzak Masaüstü tanılama ve sorun giderme için kullanışlıdır, ancak kapatmayı unutmayın. Açık bırakmak bir güvenlik deliğine neden olur.

Gizli diziler ve sertifikalar

Veri depolarına bağlantı dizesi gibi gizli dizileri bir anahtar kasasında depolayın. Anahtar kasası, sanal makine ölçek kümesiyle aynı bölgede olmalıdır. Anahtar kasası kullanmak için:

  1. Hizmetin anahtar kasasına erişiminin kimliğini doğrulama.

    Hizmeti barındıran sanal makine ölçek kümesinde yönetilen kimliği etkinleştirin.

  2. Gizli dizilerinizi anahtar kasasında depolayın.

    Anahtar/değer çiftine çevrilebilecek biçimde gizli diziler ekleyin. Örneğin, kullanın CosmosDB--AuthKey. Yapılandırma oluşturulduğunda, çift kısa çizgi (--) iki nokta üst üste (:) dönüştürülür.

  3. Hizmetinizdeki bu gizli dizilere erişin.

    anahtar kasası URI'sini appSettings.json dosyanıza ekleyin. Hizmetinizde anahtar kasasından okuyan, yapılandırmayı oluşturan ve yerleşik yapılandırmadan gizli diziye erişen yapılandırma sağlayıcısını ekleyin.

aşağıda İş Akışı hizmetinin anahtar kasasında biçiminde bir gizli dizi depoladığı bir örnek verilmiştir CosmosDB--Database.

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

Gizli diziye erişmek için, yerleşik yapılandırmada gizli dizi adını belirtin.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

Service Fabric Explorer'a erişmek için istemci sertifikalarını kullanmayın. Bunun yerine Microsoft Entra Id kullanın. Bkz . Microsoft Entra kimlik doğrulamayı destekleyen Azure hizmetleri.

Üretim için otomatik olarak imzalanan sertifikalar kullanmayın.

Bekleyen verilerin korunması

Service Fabric kümesinin sanal makine ölçek kümelerine veri diskleri eklediyseniz ve hizmetleriniz bu disklere veri kaydederse, diskleri şifrelemeniz gerekir. Daha fazla bilgi için bkz . Azure PowerShell (önizleme) ile sanal makine ölçek kümesindeki işletim sistemini ve bağlı veri disklerini şifreleme.

Service Fabric'in güvenliğini sağlama hakkında daha fazla bilgi için bkz:

Dayanıklılık

Hatalardan kurtarmak ve tam olarak çalışır durumda olmak için uygulamanın belirli dayanıklılık desenlerini uygulaması gerekir. Bazı yaygın desenler şunlardır:

  • Yeniden Deneyin: Geçici olarak kullanılamayan kaynaklar gibi geçici olmasını beklediğiniz hataları işlemek için.
  • Devre kesici: Düzeltilmesi daha uzun sürebilecek hataları gidermek için.
  • Bölme Ucu: Her hizmetin kaynaklarını yalıtmak için.

Bu başvuru uygulaması, tüm bu desenleri uygulamak için açık kaynak bir seçenek olan Polly'yi kullanır.

İzleme

İzleme seçeneklerini incelemeden önce, Service Fabric ile yaygın senaryoları tanılama hakkındaki bu makaleyi okumanızı öneririz. Şu kümelerdeki verileri izlemeyi düşünebilirsiniz:

Bu verileri analiz etmek için iki ana seçenek şunlardır:

  • Application Insights
  • Log Analytics

İzleme için panolar ayarlamak ve operatörlere uyarı göndermek için Azure İzleyici'yi kullanabilirsiniz. Bazı üçüncü taraf izleme araçları da Dynatrace gibi Service Fabric ile tümleşiktir. Ayrıntılar için bkz . Azure Service Fabric izleme iş ortakları.

Uygulama ölçümleri ve günlükleri

Uygulama telemetrisi, hizmetinizin durumunu izlemenize ve sorunları belirlemenize yardımcı olabilecek veriler sağlar. Hizmetinize izlemeler ve olaylar eklemek için:

  • Hizmetinizi ASP.NET Core ile geliştiriyorsanız Microsoft.Extensions.Logging kullanın. Diğer çerçeveler için Serilog gibi tercihinize göre bir günlük kitaplığı kullanın.
  • SDK'daki TelemetryClient sınıfını kullanarak kendi izlemenizi ekleyin ve Application Insights'ta verileri görüntüleyin. Bkz. Uygulamanıza özel izleme ekleme.
  • EventSource kullanarak Windows için Olay İzleme (ETW) olaylarını günlüğe kaydetme. Bu seçenek bir Visual Studio Service Fabric çözümünde varsayılan olarak kullanılabilir.

Application Insights birçok yerleşik telemetri sağlar: istekler, izlemeler, olaylar, özel durumlar, ölçümler, bağımlılıklar. Hizmetiniz HTTP uç noktalarını kullanıma sunarsa, Microsoft.AspNetCore.Hosting.IWebHostBuilder için uzantı yöntemini çağırarak UseApplicationInsights Application Insights'ı etkinleştirin. Application Insights için hizmetinizi izleme hakkında bilgi için şu makalelere bakın:

İzlemeleri ve olay günlüklerini görüntülemek için Application Insights'ı yapılandırılmış günlüğe kaydetme havuzlarından biri olarak kullanın. Uzantı yöntemini çağırarak AddApplicationInsights Application Insights'ı izleme anahtarınız ile yapılandırın. Bu örnekte izleme anahtarı anahtar kasasında gizli dizi olarak depolanır.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

Hizmetiniz HTTP uç noktalarını kullanıma sunmazsa, Application Insights'a izlemeler gönderen özel bir uzantı yazmanız gerekir. Bir örnek için, başvuru uygulamasında İş Akışı hizmetine bakın.

ASP.NET Core hizmetleri, uygulama günlüğü için ILogger arabirimini kullanır. Bu uygulama günlüklerini Azure İzleyici'de kullanılabilir hale getirmek için olayları Application Insights'a ILogger gönderin. Application Insights, dağıtılmış izlemeyi görselleştirmek için yararlı olan olaylara ILogger bağıntı özellikleri ekleyebilir.

Daha fazla bilgi için bkz.

Service Fabric sistem durumu ve olay verileri

Service Fabric telemetrisi, bir Service Fabric kümesinin ve varlıklarının çalışma ve performansı hakkında sistem durumu ölçümlerini ve olaylarını içerir: düğümleri, uygulamaları, hizmetleri, bölümleri ve çoğaltmaları. Sistem durumu ve olay verileri şu kaynaklardan gelebilir:

  • EventStore. Durum bilgisi olan bu sistem hizmeti, küme ve varlıklarıyla ilgili olayları toplar. Service Fabric durum güncelleştirmeleri, sorun giderme ve izleme için kümeniz hakkında bilgi sağlamak üzere Service Fabric olayları yazmak için EventStore kullanır. EventStore, kümedeki sorunları belirlemek için belirli bir zamanda farklı varlıklardaki olayları da ilişkilendirebilir. Hizmet bu olayları bir REST API aracılığıyla kullanıma sunar.

    EventStore API'lerini sorgulama hakkında bilgi için bkz . Küme olayları için EventStore API'lerini sorgulama. Kümenizi Windows (WAD) için Azure Tanılama uzantısıyla yapılandırarak Log Analytics'te EventStore'dan olayları görüntüleyebilirsiniz.

  • HealthStore. Durum bilgisi olan bu hizmet, kümenin geçerli durumunun anlık görüntüsünü sağlar. Hiyerarşideki varlıklar tarafından bildirilen tüm sistem durumu verilerini toplar. Veriler Service Fabric Explorer'da görselleştirilir. HealthStore, uygulama yükseltmelerini de izler. PowerShell, .NET uygulaması veya REST API'lerinde sistem durumu sorgularını kullanabilirsiniz. Bkz . Service Fabric sistem durumu izlemesine giriş.

  • Özel sistem durumu raporları. Çalışan hizmetlerin hatalı durumları gibi özel sistem durumu verilerini düzenli aralıklarla bildirebilen iç izleme hizmetleri uygulamayı göz önünde bulundurun. Sistem durumu raporlarını Service Fabric Explorer'da okuyabilirsiniz.

Altyapı ölçümleri ve günlükleri

Altyapı ölçümleri, kümedeki kaynak ayırmayı anlamanıza yardımcı olur. Bu bilgileri toplamak için ana seçenekler şunlardır:

  • WAD. Windows'ta düğüm düzeyinde günlükleri ve ölçümleri toplayın. Tanılama olaylarını toplamak için düğüm türüne eşlenen herhangi bir sanal makine ölçek kümesinde IaaSDiagnostics VM uzantısını yapılandırarak WAD kullanabilirsiniz. Bu olaylar Windows olay günlüklerini, performans sayaçlarını, ETW/bildirim sistemini ve işletimsel olayları ve özel günlükleri içerebilir.
  • Log Analytics aracısı. Windows olay günlüklerini, performans sayaçlarını ve özel günlükleri Log Analytics'e göndermek için MicrosoftMonitoringAgent VM uzantısını yapılandırın.

Performans sayaçları gibi önceki mekanizmalar aracılığıyla toplanan ölçüm türlerinde bazı çakışmalar vardır. Çakışma olduğunda Log Analytics aracısını kullanmanızı öneririz. Log Analytics aracısı Azure depolama kullanmadığından gecikme süresi düşüktür. Ayrıca IaaSDiagnostics'teki performans sayaçları Log Analytics'e kolayca aktarılamaz.

Service Fabric'te altyapı izlemeyi gösteren diyagram.

VM uzantılarını kullanma hakkında bilgi için bkz . Azure sanal makine uzantıları ve özellikleri.

Verileri görüntülemek için Log Analytics'i WAD aracılığıyla toplanan verileri görüntüleyecek şekilde yapılandırın. Log Analytics'i depolama hesabından olayları okuyacak şekilde yapılandırma hakkında bilgi için bkz . Küme için Log Analytics'i ayarlama.

Service Fabric kümesi, iş yükleri, ağ trafiği, bekleyen güncelleştirmeler ve daha fazlası ile ilgili performans günlüklerini ve telemetri verilerini de görüntüleyebilirsiniz. Bkz. Log Analytics ile performans izleme.

Log Analytics'teki Hizmet Eşlemesi çözümü, kümenin topolojisi (yani her düğümde çalışan işlemler) hakkında bilgi sağlar. Depolama hesabındaki verileri Application Insights'a gönderin. Application Insights'a veri almada biraz gecikme olabilir. Verileri gerçek zamanlı olarak görmek istiyorsanız havuzları ve kanalları kullanarak Event Hubs'ı yapılandırmayı göz önünde bulundurun. Daha fazla bilgi için bkz . WAD kullanarak olay toplama ve toplama.

Bağımlı hizmet ölçümleri

  • Application Insights'ta Application Map, yüklü Application Insights SDK'sı ile hizmetler arasında yapılan HTTP bağımlılık çağrılarını kullanarak uygulamanın topolojisini sağlar.
  • Log Analytics'teki Hizmet Eşlemesi, dış hizmetlerden ve dış hizmetlere gelen ve giden trafik hakkında bilgi sağlar. Hizmet Eşlemesi, güncelleştirmeler veya güvenlik gibi diğer çözümlerle tümleştirilir.
  • Özel izlemeler dış hizmetlerde hata koşullarını bildirebilir. Örneğin, hizmet bir dış hizmete veya veri depolama alanına (Azure Cosmos DB) erişemiyorsa bir hata durumu raporu sağlayabilir.

Dağıtılmış izleme

Mikro hizmetler mimarisinde, bir görevi tamamlamak için genellikle birkaç hizmet katılır. Bu hizmetlerin her birinden gelen telemetri, dağıtılmış izlemedeki bağlam alanları (işlem kimliği ve istek kimliği gibi) ile ilişkilendirilir.

Application Insights'ta Uygulama Eşlemesi'ni kullanarak dağıtılmış mantıksal işlemlerin görünümünü oluşturabilir ve uygulamanızın hizmet grafiğinin tamamını görselleştirebilirsiniz. Sunucu tarafı telemetri verilerini ilişkilendirmek için Application Insights'ta işlem tanılamalarını da kullanabilirsiniz. Daha fazla bilgi için bkz . Birleşik bileşenler arası işlem tanılaması.

Kuyruk kullanılarak zaman uyumsuz olarak dağıtılan görevlerin bağıntılı olması da önemlidir. Kuyruk iletisinde bağıntı telemetrisi gönderme hakkında ayrıntılı bilgi için bkz . Kuyruk izleme.

Daha fazla bilgi için bkz.

Uyarılar ve panolar

Application Insights ve Log Analytics, günlük verilerini alıp analiz etmenize olanak tanıyan kapsamlı bir sorgu dilini (Kusto sorgu dili) destekler. Veri kümeleri oluşturmak ve bunları tanılama panolarında görselleştirmek için sorguları kullanın.

Belirli kaynaklarda belirli koşullar oluştuğunda sistem yöneticilerine bildirim göndermek için Azure İzleyici uyarılarını kullanın. Bildirim e-posta, Azure işlevi veya web kancası olabilir. Daha fazla bilgi için bkz . Azure İzleyici'de uyarılar.

Günlük araması uyarı kuralları , düzenli aralıklarla Bir Log Analytics çalışma alanında Kusto sorgusu tanımlamanıza ve çalıştırmanıza olanak sağlar. Sorgu sonucu belirli bir koşulla eşleşiyorsa bir uyarı oluşturulur.

Maliyet iyileştirme

Maliyetleri tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Diğer önemli noktalar, Microsoft Azure İyi Tasarlanmış Çerçeve'nin maliyet iyileştirme ayağında açıklanmıştır.

Bu mimaride kullanılan bazı hizmetler için göz önünde bulundurmanız gereken bazı noktalar aşağıdadır.

Azure Service Fabric

Service Fabric kümesi oluştururken seçtiğiniz işlem örnekleri, depolama, ağ kaynakları ve IP adresleri için ücretlendirilirsiniz. Service Fabric için dağıtım ücretleri vardır.

Sanal makine ölçek kümeleri

Bu mimaride, mikro hizmetler sanal makine ölçek kümeleri olan düğümlere dağıtılır. Kümenin parçası olarak dağıtılan Azure VM'leri ve depolama ve ağ gibi temel altyapı kaynakları için ücretlendirilirsiniz. Sanal makine ölçek kümeleri için artımlı ücret alınmaz.

Azure API Management

Azure API Management, istemcilerden gelen istekleri kümedeki hizmetlerinize yönlendiren bir ağ geçididir.

Çeşitli fiyatlandırma seçenekleri vardır. Tüketim seçeneği kullanım başına ödeme temelinde ücretlendirilir ve bir ağ geçidi bileşeni içerir. İş yükünüz temelinde API Management fiyatlandırması bölümünde açıklanan bir seçeneği belirleyin.

Application Insights

Application Insights'ı kullanarak tüm hizmetler için telemetri toplayabilir ve izlemeleri ve olay günlüklerini yapılandırılmış bir şekilde görüntüleyebilirsiniz. Application Insights fiyatlandırması, alınan veri hacmini ve veri saklama seçeneklerini temel alan kullandıkça öde modelidir. Daha fazla bilgi için bkz . Application Insights için kullanımı ve maliyeti yönetme.

Azure İzleyici

Azure İzleyici Log Analytics için veri alımı ve saklama için ücretlendirilirsiniz. Daha fazla bilgi için bkz . Azure İzleyici fiyatlandırması.

Azure Key Vault

Application Insights izleme anahtarını gizli dizi olarak depolamak için Azure Key Vault kullanırsınız. Azure iki hizmet katmanında Key Vault sunar. HSM korumalı anahtarlara ihtiyacınız yoksa Standart katmanı seçin. Her katmandaki özellikler hakkında bilgi için bkz . Key Vault fiyatlandırması.

Azure DevOps Services

Bu başvuru mimarisinde dağıtım için Azure Pipelines kullanılır. Azure Pipelines hizmeti, CI/CD için ayda 1.800 dakika ve ayda sınırsız dakika ile şirket içinde barındırılan bir iş ile microsoft tarafından barındırılan ücretsiz bir iş sağlar. Ek işlerin ücretleri vardır. Daha fazla bilgi için bkz . Azure DevOps Services fiyatlandırması.

Mikro hizmetler mimarisinde DevOps ile ilgili dikkat edilmesi gerekenler için bkz . Mikro hizmetler için CI/CD.

CI/CD ile bir kapsayıcı uygulamasını Service Fabric kümesine dağıtmayı öğrenmek için bu öğreticiye bakın.

Bu senaryoyu dağıtın

Bu mimariye yönelik başvuru uygulamasını dağıtmak için GitHub deposundaki adımları izleyin.

Sonraki adımlar