Sık sorulan Service Fabric soruları

  • Makale

Service Fabric'in yapabilecekleri ve nasıl kullanılması gerektiği hakkında sık sorulan birçok soru vardır. Bu belge, bu yaygın soruların çoğunu ve yanıtlarını kapsar.

Not

Azure ile etkileşim kurmak için Azure Az PowerShell modülünü kullanmanızı öneririz. Başlamak için bkz. Azure PowerShell'i yükleme. Az PowerShell modülüne nasıl geçeceğinizi öğrenmek için bkz. Azure PowerShell’i AzureRM’den Az’ye geçirme.

Küme kurulumu ve yönetimi

Service Fabric küme sertifikamı geri Nasıl yaparım??

Uygulamanıza herhangi bir yükseltmenin geri döndürülmesi, Service Fabric küme çekirdeğinizin değişikliği işlemeden önce sistem durumu hatası algılamasını gerektirir; kaydedilmiş değişiklikler yalnızca ileriye doğru alınabiliyor. İzlenmeyen bir hata sertifikası değişikliği yapılmışsa, müşteri destek hizmetleri aracılığıyla yükseltme mühendisinin kümenizi kurtarması gerekebilir. Service Fabric'in uygulama yükseltmesi, Uygulama yükseltme parametrelerini uygular ve sıfır kapalı kalma süresi yükseltme sözü verir. Önerilen uygulama yükseltmesi izlenen modumuzdan sonra, güncelleştirme etki alanlarındaki otomatik ilerleme durumu denetimlerinin geçmesine dayanır ve varsayılan bir hizmeti güncelleştirme başarısız olursa otomatik olarak geri döner.

Kümeniz Resource Manager şablonunuzdaki klasik Sertifika Parmak İzi özelliğinden yararlanmaya devam ediyorsa, modern gizli dizi yönetimi özelliklerinden yararlanmak için kümeyi sertifika parmak izi yerine ortak ada dönüştürmeniz önerilir.

Birden çok Azure bölgesine veya kendi veri merkezime yayılan bir küme oluşturabilir miyim?

Evet.

Temel Service Fabric kümeleme teknolojisi, birbirleriyle ağ bağlantısı olduğu sürece dünyanın herhangi bir yerinde çalışan makineleri birleştirmek için kullanılabilir. Ancak, böyle bir küme oluşturmak ve çalıştırmak karmaşık olabilir.

Bu senaryoyla ilgileniyorsanız, ek rehberlik almak için Service Fabric GitHub Sorun Listesi veya destek temsilciniz aracılığıyla iletişime geçmenizi öneririz. Service Fabric ekibi, bu senaryo için ek netlik, rehberlik ve öneriler sağlamak için çalışmaktadır.

Dikkate alınması gereken bazı noktalar şunlardır:

  1. Azure'daki Service Fabric küme kaynağı, kümenin üzerinde oluşturulduğu sanal makine ölçek kümeleri gibi bölgeseldir. Bu, bölgesel bir hata durumunda Azure Resource Manager veya Azure portalı aracılığıyla kümeyi yönetme becerinizi kaybedebilirsiniz anlamına gelir. Küme çalışmaya devam etse ve doğrudan onunla etkileşim kurabilseniz bile bu durum oluşabilir. Buna ek olarak, Azure bugün bölgeler arasında kullanılabilen tek bir sanal ağa sahip olma olanağı sunmaz. Bu, Azure'daki çok bölgeli bir kümenin sanal makine ölçek kümelerindeki her VM için Genel IP Adresleri veya Azure VPN Ağ Geçitleri gerektirdiği anlamına gelir. Bu ağ seçimlerinin maliyetler, performans ve bir derece uygulama tasarımı üzerinde farklı etkileri vardır, bu nedenle böyle bir ortamı ayakta kullanmadan önce dikkatli analiz ve planlama gerekir.
  2. Bu makinelerin bakımı, yönetimi ve izlenmesi, özellikle farklı bulut sağlayıcıları arasında veya şirket içi kaynaklar ile Azure arasında olduğu gibi ortam türlerine yayıldığında karmaşık hale gelebilir. Böyle bir ortamda üretim iş yüklerini çalıştırmadan önce yükseltmelerin, izlemenin, yönetimin ve tanılamaların hem küme hem de uygulamalar için anlaşılmasını sağlamak için dikkatli olunmalıdır. Azure'da veya kendi veri merkezlerinizde bu sorunları çözme konusunda zaten deneyiminiz varsa, Service Fabric kümenizi oluştururken veya çalıştırırken aynı çözümlerin uygulanması olasıdır.

Service Fabric düğümleri işletim sistemi güncelleştirmelerini otomatik olarak alıyor mu?

Sanal Makine Ölçek Kümesi Otomatik İşletim Sistemi Görüntü Güncelleştirmesi Genel Kullanıma Sunuldu özelliğini bugün kullanabilirsiniz.

Azure'da çalıştırılmayan kümeler için Service Fabric düğümlerinizin altındaki işletim sistemlerine düzeltme eki uygulamak için bir uygulama sağladık.

SF kümemde büyük sanal makine ölçek kümelerini kullanabilir miyim?

Kısa yanıt - Hayır.

Uzun Yanıt - Büyük sanal makine ölçek kümeleri, bir sanal makine ölçek kümesini 1000 VM örneğine kadar ölçeklendirmenize izin verse de, bunu Yerleştirme Grupları (PG) kullanarak yapar. Hata etki alanları (FD' ler) ve yükseltme etki alanları (UD) yalnızca hizmet çoğaltmalarınızın/Hizmet örneklerinizin yerleştirme kararlarını almak için FD'leri ve UD'leri kullanan bir yerleştirme grubu içinde tutarlıdır. FD'ler ve UD'ler yalnızca bir yerleştirme grubu içinde karşılaştırılabilir olduğundan, SF bunu kullanamaz. Örneğin, PG1'deki VM1'de FD=0 topolojisi varsa ve PG2'deki VM9'da FD=4 topolojisi varsa, bu VM1 ve VM2'nin iki farklı Donanım Rafı üzerinde olduğu anlamına gelmez, bu nedenle SF bu durumda yerleştirme kararları almak için FD değerlerini kullanamaz.

Şu anda 4. düzey Yük dengeleme desteğinin olmaması gibi büyük sanal makine ölçek kümeleriyle ilgili başka sorunlar da vardır. Büyük ölçek kümeleriyle ilgili ayrıntılar için bkz.

Service Fabric kümesinin en düşük boyutu nedir? Neden daha küçük olamaz?

Üretim iş yüklerini çalıştıran bir Service Fabric kümesi için desteklenen en düşük boyut beş düğümdür. Geliştirme senaryoları için bir düğümü (Visual Studio'da hızlı geliştirme deneyimi için iyileştirilmiş) ve beş düğüm kümesini destekliyoruz.

Aşağıdaki üç nedenden dolayı bir üretim kümesinin en az beş düğümü olması gerekir:

  1. Hiçbir kullanıcı hizmeti çalışmadığında bile, Service Fabric kümesi adlandırma hizmeti ve yük devretme yöneticisi hizmeti de dahil olmak üzere durum bilgisi olan bir sistem hizmeti kümesi çalıştırır. Bu sistem hizmetleri, kümenin çalışır durumda kalması için gereklidir.
  2. Düğüm başına her zaman bir hizmetin bir çoğaltmasını yerleştiririz; bu nedenle küme boyutu, bir hizmetin (aslında bir bölüm) sahip olabileceği çoğaltma sayısı için üst sınırdır.
  3. Bir küme yükseltmesi en az bir düğümü düşüreceğinden en az bir düğümden oluşan bir arabelleğe sahip olmak istiyoruz, bu nedenle bir üretim kümesinin en az en az iki düğüme ek olarak en az iki düğümü olmasını istiyoruz. Minimum değer, aşağıda açıklandığı gibi bir sistem hizmetinin çekirdek boyutudur.

İki düğümün aynı anda başarısız olması durumunda kümenin kullanılabilir olmasını istiyoruz. Bir Service Fabric kümesinin kullanılabilir olması için sistem hizmetlerinin kullanılabilir olması gerekir. Kümeye hangi hizmetlerin dağıtıldığını ve şu anda nerede barındırıldığını izleyen adlandırma hizmeti ve yük devretme yöneticisi hizmeti gibi durum bilgisi olan sistem hizmetleri güçlü tutarlılığa bağlıdır. Bu güçlü tutarlılık da belirli bir hizmet için çoğaltmaların (N/2 +1) katı çoğunluğunu temsil eden çekirdek, söz konusu hizmetlerin durumunda belirli bir güncelleştirme için çekirdek elde etme yeteneğine bağlıdır. Bu nedenle, iki düğümün eşzamanlı kaybına (dolayısıyla bir sistem hizmetinin iki çoğaltmasının eşzamanlı kaybına) karşı dayanıklı olmak istiyorsak, minimum boyutu beş olarak zorlayan ClusterSize - QuorumSize >= 2 olmalıdır. Bunu görmek için kümenin N düğümleri olduğunu ve bir sistem hizmetinin N çoğaltması olduğunu (her düğümde bir tane) düşünün. Sistem hizmetinin çekirdek boyutu :(N/2 + 1). Yukarıdaki eşitsizlik N - (N/2 + 1) >= 2 gibi görünür. Dikkate alınması gereken iki durum vardır: N çift olduğunda ve N tek olduğunda. N eşitse, N = 2*m, burada m >= 1 deyin, eşitsizlik 2*m - (2*m/2 + 1) >= 2 veya m >= 3 gibi görünür. N için en düşük değer 6'dır ve m = 3 olduğunda elde edilir. Öte yandan N tekse, N = 2*m+1 deyin; burada m >= 1, eşitsizlik 2*m+1 - ( (2*m+1)/2 + 1 ) >= 2 veya 2*m+1 - (m+1) >= 2 veya m >= 2 gibi görünür. N için en düşük değer 5'tir ve bu değer m = 2 olduğunda elde edilir. Bu nedenle, eşit olmayan ClusterSize - QuorumSize >= 2 değerini karşılayan tüm N değerleri arasında en düşük değer 5'tir.

Yukarıdaki bağımsız değişkende her düğümün bir sistem hizmetinin çoğaltması olduğunu, dolayısıyla çekirdek boyutunun kümedeki düğüm sayısına göre hesaplandığını varsaydığımıza dikkat edin. Ancak TargetReplicaSetSize değerini değiştirerek çekirdek boyutunun (N/2+1) değerinden küçük olmasını sağlayabiliriz. Bu, 5 düğümden küçük bir kümeye sahip olabileceğimizi ve çekirdek boyutunun üzerinde 2 ek düğüme sahip olabileceğimizi gösterebilir. Örneğin, 4 düğümlü bir kümede TargetReplicaSetSize değerini 3 olarak ayarlarsak, TargetReplicaSetSize'ı temel alan çekirdek boyutu (3/2 + 1) veya 2 olur, bu nedenle ClusterSize - QuorumSize = 4-2 = 2 >olur. Ancak, aynı anda herhangi bir düğüm çiftini kaybedersek sistem hizmetinin çekirdekte veya daha yüksek bir çekirdekte olacağını garanti edemeyiz, kaybettiğimiz iki düğüm iki çoğaltma barındırıyor olabilir, bu nedenle sistem hizmeti çekirdek kaybına (yalnızca tek bir çoğaltma kaldı) gider ve kullanılamaz duruma gelir.

Bu arka planla, bazı olası küme yapılandırmalarını inceleyelim:

Bir düğüm: Bu seçenek yüksek kullanılabilirlik sağlamaz çünkü herhangi bir nedenle tek düğümün kaybı tüm kümenin kaybı anlamına gelir.

İki düğüm: İki düğüm arasında dağıtılan bir hizmetin çekirdek sayısı (N = 2) 2'dir (2/2 + 1 = 2). Tek bir çoğaltma kaybolduğunda çekirdek oluşturmak mümkün değildir. Hizmet yükseltmesi gerçekleştirmek için çoğaltmanın geçici olarak indirilmesi gerektiğinden, bu kullanışlı bir yapılandırma değildir.

Üç düğüm: üç düğümle (N=3), çekirdek oluşturma gereksinimi hala iki düğümdür (3/2 + 1 = 2). Bu, tek bir düğümü kaybedebileceğiniz ve yine de çekirdeği koruyabileceğiniz anlamına gelir, ancak iki düğümün aynı anda başarısız olması sistem hizmetlerini çekirdek kaybına sürükler ve kümenin kullanılamaz duruma gelmesine neden olur.

Dört düğüm: dört düğümle (N=4), çekirdek oluşturma gereksinimi üç düğümdür (4/2 + 1 = 3). Bu, tek bir düğümü kaybedebileceğiniz ve yine de çekirdeği koruyabileceğiniz anlamına gelir, ancak iki düğümün aynı anda başarısız olması sistem hizmetlerini çekirdek kaybına sürükler ve kümenin kullanılamaz duruma gelmesine neden olur.

Beş düğüm: beş düğümle (N=5), çekirdek oluşturma gereksinimi hala üç düğümdür (5/2 + 1 = 3). Bu, aynı anda iki düğümü kaybedebileceğiniz ve sistem hizmetleri için çekirdek tutabileceğiniz anlamına gelir.

Üretim iş yükleri için en az iki düğümün aynı anda başarısız olması (örneğin, biri küme yükseltmesi, biri diğer nedenlerden dolayı) için dayanıklı olmanız gerekir, bu nedenle beş düğüm gereklidir.

Maliyet tasarrufu yapmak için kümemi gece/hafta sonları kapatabilir miyim?

Genel olarak hayır. Service Fabric durumu yerel kısa ömürlü disklerde depolar; başka bir deyişle sanal makine farklı bir konağa taşınırsa veriler onunla birlikte taşınmaz. Normal işlemde, yeni düğüm diğer düğümler tarafından güncellendiğinden bu bir sorun değildir. Ancak, tüm düğümleri durdurur ve daha sonra yeniden başlatırsanız, düğümlerin çoğunun yeni konaklarda başlaması ve sistemin kurtarılamamasını sağlama olasılığı oldukça fazladır.

Uygulamanızın dağıtılmadan önce test edilmesi için kümeler oluşturmak isterseniz, bu kümeleri sürekli tümleştirme/sürekli dağıtım işlem hattınızın bir parçası olarak dinamik olarak oluşturmanızı öneririz.

İşletim Sistemimi (örneğin, Windows Server 2012'den Windows Server 2016'ya) Nasıl yaparım? yükseltin?

Geliştirilmiş bir deneyim üzerinde çalışırken, bugün yükseltmeden siz sorumlusunuz. Kümenin sanal makinelerinde işletim sistemi görüntüsünü bir kerede bir VM yükseltmeniz gerekir.

Bağlı veri disklerini bir küme düğümü türünde (sanal makine ölçek kümesi) şifreleyebilir miyim?

Evet. Daha fazla bilgi için bkz. Bağlı veri diskleriyle küme oluşturma ve Sanal Makine Ölçek Kümeleri için Azure Disk Şifrelemesi.

Düşük öncelikli VM'leri bir küme düğümü türünde (sanal makine ölçek kümesi) kullanabilir miyim?

Hayır Düşük öncelikli VM'ler desteklenmez.

Kümemde bir virüsten koruma programı çalıştırırken dışlamam gereken dizinler ve işlemler nelerdir?

Virüsten Koruma Dışlanan dizinler
Program Files\Microsoft Service Fabric
FabricDataRoot (küme yapılandırmasından)
FabricLogRoot (küme yapılandırmasından)
Virüsten Koruma Dışlanan işlemler
Fabric.exe
FabricHost.exe
FabricInstallerService.exe
FabricSetup.exe
FabricDeployer.exe
ImageBuilder.exe
FabricGateway.exe
FabricDCA.exe
FabricFAS.exe
FabricUOS.exe
FabricRM.exe
FileStoreService.exe

Uygulamam gizli dizileri almak için Key Vault'ta nasıl kimlik doğrulaması yapabilir?

Aşağıdakiler, uygulamanızın Key Vault'ta kimlik doğrulaması için kimlik bilgilerini almasına yönelik araçlardır:

A. Uygulama derleme/paketleme işiniz sırasında SF uygulamanızın veri paketine bir sertifika çekebilir ve bunu kullanarak Key Vault'ta kimlik doğrulaması yapabilirsiniz. B. Sanal makine ölçek kümesi MSI özellikli konaklar için, MSI uç noktasından erişim belirteci almak ve ardından Key Vault'tan gizli dizilerinizi almak üzere SF uygulamanız için basit bir PowerShell KurulumuEntryPoint geliştirebilirsiniz.

Aboneliğimi farklı bir Microsoft Entra kiracısına aktarabilir miyim?

Hayır Şu anda abonelik farklı bir Microsoft Entra kiracısına aktarıldıktan sonra yeni bir Service Fabric küme kaynağı oluşturmanız gerekir.

Kümemi Microsoft Entra kiracıları arasında taşıyabilir/geçirebilir miyim?

Hayır Şu anda yeni kiracı altında yeni bir Service Fabric küme kaynağı oluşturmanız gerekir.

Kümemi abonelikler arasında taşıyabilir/geçirebilir miyim?

Hayır Şu anda yeni abonelik altında yeni bir Service Fabric küme kaynağı oluşturmanız gerekir.

Küme veya küme kaynaklarımı başka kaynak gruplarına taşıyabilir/geçirebilir veya yeniden adlandırabilir miyim?

Hayır Şu anda yeni kaynak grubu/adı altında yeni bir Service Fabric küme kaynağı oluşturmanız gerekir.

Uygulama Tasarımı

Güvenilir Koleksiyonun bölümleri arasında veri sorgulamanın en iyi yolu nedir?

Güvenilir koleksiyonlar genellikle daha yüksek performans ve aktarım hızı için ölçeği genişletmeyi etkinleştirmek üzere bölümlenir . Bu, belirli bir hizmetin durumunun onlarca veya yüzlerce makineye yayılacağı anlamına gelir. Bu tam veri kümesi üzerinde işlem gerçekleştirmek için birkaç seçeneğiniz vardır:

  • Gerekli verileri çekmek için başka bir hizmetin tüm bölümlerini sorgulayan bir hizmet oluşturun.
  • Başka bir hizmetin tüm bölümlerinden veri alabilen bir hizmet oluşturun.
  • Verileri düzenli aralıklarla her hizmetten bir dış depoya gönderme. Bu yaklaşım yalnızca, dış mağazanın verileri eski olacağı için, gerçekleştirdiğiniz sorgular temel iş mantığınızın bir parçası değilse uygundur.
  • Alternatif olarak, tüm kayıtlarda sorgulamayı desteklemesi gereken verileri güvenilir bir koleksiyon yerine doğrudan bir veri deposunda depolayın. Bu, eski verilerle ilgili sorunu ortadan kaldırır, ancak güvenilir koleksiyonların avantajlarından yararlanmaya izin vermez.

Aktörlerim arasında verileri sorgulamanın en iyi yolu hangisidir?

Aktörler bağımsız durum ve işlem birimleri olacak şekilde tasarlanmıştır, bu nedenle çalışma zamanında aktör durumunun geniş sorgularını gerçekleştirmeniz önerilmez. Aktör durumunun tamamını sorgulamanız gerekiyorsa şunları göz önünde bulundurmanız gerekir:

  • Aktör hizmetlerinizi durum bilgisi olan güvenilir hizmetlerle değiştirerek, aktör sayısından hizmetinizdeki bölüm sayısına kadar tüm verileri toplamak için ağ isteklerinin sayısını belirleyin.
  • Aktörlerinizi, daha kolay sorgulama için durumlarını düzenli aralıklarla bir dış depoya gönderecek şekilde tasarlama. Yukarıdaki gibi, bu yaklaşım yalnızca gerçekleştirdiğiniz sorgular çalışma zamanı davranışınız için gerekli değilse uygulanabilir.

Güvenilir Koleksiyonda ne kadar veri depolayabilirim?

Güvenilir hizmetler genellikle bölümlenir, bu nedenle depolayabileceğiniz miktar yalnızca kümedeki makine sayısıyla ve bu makinelerde kullanılabilir bellek miktarıyla sınırlıdır.

Örneğin, 100 bölümü ve 3 çoğaltması olan ve ortalama 1 kb boyutunda nesneleri depolayan bir hizmette güvenilir bir koleksiyonunuz olduğunu varsayalım. Şimdi makine başına 16 gb belleğe sahip 10 makine kümeniz olduğunu varsayalım. Kolaylık sağlamak ve muhafazakar olmak için işletim sistemi ve sistem hizmetlerinin, Service Fabric çalışma zamanının ve hizmetlerinizin bu işlemden 6 gb yararlandığını ve makine başına 10 gb veya küme için 100 gb kullanılabilir olduğunu varsayalım.

Her nesnenin üç kez (bir birincil ve iki çoğaltma) depolanması gerektiğini unutmayın; tam kapasitede çalışırken koleksiyonunuzda yaklaşık 35 milyon nesne için yeterli belleğe sahip olursunuz. Ancak, bir hata etki alanının ve yaklaşık 3'te 1'ini temsil eden ve sayıyı kabaca 23 milyona düşürecek bir yükseltme etki alanının eşzamanlı kaybına dayanıklı olmasını öneririz.

Bu hesaplamada aşağıdakiler de varsayılır:

  • Verilerin bölümler arasında dağılımının kabaca tekdüze olduğunu veya yük ölçümlerini Küme Resource Manager'a bildirdiğiniz. Varsayılan olarak, Service Fabric çoğaltma sayısına göre dengeyi yükler. Yukarıdaki örnekte, kümedeki her düğüme 10 birincil çoğaltma ve 20 ikincil çoğaltma koyacak. Bu, bölümler arasında eşit olarak dağıtılan yük için iyi çalışır. Yük eşit değilse, Resource Manager'ın daha küçük çoğaltmaları birlikte paketleyip daha büyük çoğaltmaların tek bir düğümde daha fazla bellek tüketmesine izin vermesi için yükü bildirmeniz gerekir.

  • Söz konusu güvenilir hizmetin kümede durumu depolayan tek hizmet olduğunu. Bir kümeye birden çok hizmet dağıtabildiğiniz için, her birinin durumunu çalıştırması ve yönetmesi gereken kaynaklara dikkat etmeniz gerekir.

  • Kümenin kendisinin büyümediğini veya küçülmediğini belirtir. Daha fazla makine eklerseniz, tek bir çoğaltma makinelere yayılamayacağından, makine sayısı hizmetinizdeki bölüm sayısını aşana kadar Service Fabric çoğaltmalarınızı yeniden dengeler. Buna karşılık, makineleri kaldırarak kümenin boyutunu küçültürseniz, çoğaltmalarınız daha sıkı bir şekilde paketlenir ve daha az genel kapasiteye sahiptir.

Bir aktörde ne kadar veri depolayabilirim?

Güvenilir hizmetlerde olduğu gibi, aktör hizmetinde depolayabileceğiniz veri miktarı yalnızca kümenizdeki düğümler arasında kullanılabilen toplam disk alanı ve bellekle sınırlıdır. Ancak, tek tek aktörler en çok az miktarda durum ve ilişkili iş mantığını kapsüllemek için kullanıldıklarında etkilidir. Genel bir kural olarak, tek bir aktörün kilobayt cinsinden ölçülen bir durumu olmalıdır.

Azure Service Fabric Kaynak Sağlayıcısı müşteri verilerini nerede depolar?

Azure Service Fabric Kaynak Sağlayıcısı müşteri verilerini dağıtılan bölgenin dışına taşımaz veya depolamaz.

Diğer sorular

Service Fabric'in kapsayıcılar ile ilişkisi nedir?

Kapsayıcılar, hizmetleri ve bağımlılıklarını tüm ortamlarda tutarlı bir şekilde çalıştıracak ve tek bir makinede yalıtılmış bir şekilde çalışacak şekilde paketlemek için basit bir yol sunar. Service Fabric, kapsayıcıda paketlenmiş hizmetler de dahil olmak üzere hizmetleri dağıtmak ve yönetmek için bir yol sunar.

Açık kaynak Service Fabric mi planlıyorsunuz?

GitHub'da Service Fabric'in açık kaynaklı bölümleri (güvenilir hizmetler çerçevesi, güvenilir aktörler çerçevesi, ASP.NET Çekirdek tümleştirme kitaplıkları, Service Fabric Gezgini ve Service Fabric CLI) var ve bu projelere topluluk katkılarını kabul ediyoruz.

Kısa süre önce Service Fabric çalışma zamanını açık kaynak yapmayı planladığımızı duyurmuştuk . Bu noktada, Linux derleme ve test araçlarıyla GitHub'da Service Fabric deposuna sahibiz. Bu da depoyu kopyalayabileceğiniz, Linux için Service Fabric oluşturabileceğiniz, temel testleri çalıştırabileceğiniz, sorunları açabileceğiniz ve çekme istekleri gönderebileceğiniz anlamına gelir. Tam bir CI ortamının yanı sıra Windows derleme ortamının da geçirilmesini sağlamak için çok çalışıyoruz.

Duyurulan diğer ayrıntılar için Service Fabric blogunu izleyin.

Sonraki adımlar

Service Fabric çalışma zamanı kavramları ve en iyi yöntemleri hakkında bilgi edinin