Service Fabric test edilebilirlik senaryoları: Hizmet iletişimi

Azure Service Fabric'te mikro hizmetler ve hizmet odaklı mimari stiller doğal olarak ortaya çıkar. Bu tür dağıtılmış mimarilerde, bileşenli mikro hizmet uygulamaları genellikle birbiriyle konuşması gereken birden çok hizmetlerden oluşur. En basit durumlarda bile, genellikle en az durum bilgisi olmayan bir web hizmeti ve iletişim kurması gereken durum bilgisi olan bir veri depolama hizmetiniz vardır.

Hizmet-hizmet iletişimi, bir uygulamanın kritik bir tümleştirme noktasıdır çünkü her hizmet bir uzak API'yi diğer hizmetlere sunar. G/Ç içeren bir dizi API sınırıyla çalışmak genellikle iyi miktarda test ve doğrulama ile biraz özen gerektirir.

Bu hizmet sınırları dağıtılmış bir sistemde birbirine bağlı olduğunda dikkat edilmesi gereken çok sayıda önemli nokta vardır:

• Aktarım protokolü. Daha fazla birlikte çalışabilirlik için HTTP mi yoksa en yüksek aktarım hızı için özel ikili protokol mü kullanacaksınız?
• Hata işleme. Kalıcı ve geçici hatalar nasıl işlenecek? Bir hizmet farklı bir düğüme geçtiğinde ne olur?
• Zaman aşımları ve gecikme süresi. Çok katmanlı uygulamalarda, her hizmet katmanı yığın aracılığıyla ve kullanıcı için gecikme süresini nasıl işler?

İster Service Fabric tarafından sağlanan yerleşik hizmet iletişimi bileşenlerinden birini kullanın ister kendi hizmetinizi oluşturun, hizmetleriniz arasındaki etkileşimleri test etmek, uygulamanızda dayanıklılık sağlamak için kritik öneme sahiptir.

Hizmetlerin taşınmasına hazırlanma

Hizmet örnekleri zaman içinde hareket edebilir. Bu durum özellikle özel olarak uyarlanmış en uygun kaynak dengeleme için yük ölçümleriyle yapılandırıldıklarında geçerlidir. Service Fabric, yükseltmeler, yük devretmeler, ölçeği genişletme ve dağıtılmış sistemin kullanım ömrü boyunca gerçekleşen diğer durumlarda bile hizmet örneklerinizi en üst düzeye çıkarmak için taşır.

Hizmetler kümede hareket ettikçe, istemcileriniz ve diğer hizmetleriniz bir hizmetle konuştuklarında iki senaryoyu işlemeye hazır olmalıdır:

• Hizmet örneği veya bölüm çoğaltması, son konuştuğunuz zamandan bu yana taşındı. Bu, bir hizmet yaşam döngüsünün normal bir parçasıdır ve uygulamanızın ömrü boyunca gerçekleşmesi beklenmelidir.
• Hizmet örneği veya bölüm çoğaltması taşıma işlemi devam ediyor. Service Fabric'te hizmetin bir düğümden diğerine yük devretmesi çok hızlı gerçekleşse de, hizmetinizin iletişim bileşeni yavaş başlatılırsa kullanılabilirlikte gecikme olabilir.

Sorunsuz çalışan bir sistem için bu senaryoları düzgün bir şekilde işlemek önemlidir. Bunu yapmak için şunları aklınızda bulundurun:

• Bağlanabilen her hizmetin dinlediği bir adres vardır (örneğin, HTTP veya WebSockets). Bir hizmet örneği veya bölümü taşındığında, adres uç noktası değişir. (Farklı bir IP adresine sahip farklı bir düğüme taşınır.) Yerleşik iletişim bileşenlerini kullanıyorsanız, bunlar sizin için hizmet adreslerini yeniden çözümlemeyi işler.
• Hizmet örneği dinleyicisini yeniden başlatırken hizmet gecikme süresinde geçici bir artış olabilir. Bu, hizmet örneği taşındıktan sonra hizmetin dinleyiciyi ne kadar hızlı açtığına bağlıdır.
• Hizmet yeni bir düğümde açıldıktan sonra mevcut bağlantıların kapatılması ve yeniden açılması gerekir. Düzgün bir düğümün kapatılması veya yeniden başlatılması, mevcut bağlantıların düzgün bir şekilde kapatılmasına izin verir.

Test edin: Hizmet örneklerini taşıma

Service Fabric'in test edilebilirlik araçlarını kullanarak, bu durumları farklı şekillerde test etmek için bir test senaryosu yazabilirsiniz:

1. Durum bilgisi olan bir hizmetin birincil çoğaltmasını taşıma.

   Durum bilgisi olan bir hizmet bölümünün birincil çoğaltması çeşitli nedenlerle taşınabilir. Hizmetlerinizin taşımaya çok denetimli bir şekilde nasıl tepki verdiğinizi görmek için belirli bir bölümün birincil çoğaltmasını hedeflemek için bunu kullanın.

   
   PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyService
   
   

2. Düğümü durdurun.

   Bir düğüm durdurulduğunda, Service Fabric bu düğümdeki tüm hizmet örneklerini veya bölümlerini kümedeki diğer kullanılabilir düğümlerden birine taşır. Bir düğümün kümenizden kaybolduğu ve bu düğümdeki tüm hizmet örneklerinin ve çoğaltmalarının taşınması gereken bir durumu test etmek için bunu kullanın.

   PowerShell Stop-ServiceFabricNode cmdlet'ini kullanarak bir düğümü durdurabilirsiniz:

   
   PS > Stop-ServiceFabricNode -NodeName Node_1
   
   

Hizmet kullanılabilirliğini koruma

Platform olarak Service Fabric, hizmetlerinizin yüksek kullanılabilirliğini sağlamak için tasarlanmıştır. Ancak aşırı durumlarda, temel altyapı sorunları hala kullanılamazlığa neden olabilir. Bu senaryolar için de test etmek önemlidir.

Durum bilgisi olan hizmetler, yüksek kullanılabilirlik durumunu çoğaltmak için çekirdek tabanlı bir sistem kullanır. Bu, yazma işlemlerini gerçekleştirmek için bir çoğaltma çekirdeğinin kullanılabilir olması gerektiği anlamına gelir. Yaygın donanım hatası gibi nadir durumlarda çoğaltma çekirdeği kullanılamayabilir. Bu gibi durumlarda, yazma işlemlerini gerçekleştiremezsiniz, ancak yine de okuma işlemleri gerçekleştirebilirsiniz.

Test edin: Yazma işlemi kullanılamıyor

Service Fabric'teki test edilebilirlik araçlarını kullanarak çekirdek kaybına neden olan bir hatayı test olarak ekleyebilirsiniz. Böyle bir senaryo nadir olsa da, durum bilgisi olan bir hizmete bağımlı olan istemcilerin ve hizmetlerin, bu hizmete yazma isteğinde bulunamayacakları durumları işlemeye hazır olmaları önemlidir. Durum bilgisi olan hizmetin kendisi de bu olasılığın farkındadır ve arayanlara düzgün bir şekilde iletebilir.

PowerShell Invoke-ServiceFabricPartitionQuorumLoss cmdlet'ini kullanarak çekirdek kaybına neden olabilirsiniz:

PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20

Bu örnekte, tüm çoğaltmaları azaltmadan çekirdek kaybına neden olmak istediğimizi belirtmek için olarak ayarlıyoruz QuorumLossMode QuorumReplicas . Bu şekilde, okuma işlemleri hala mümkündür. Bölümün tamamının kullanılamadığı bir senaryoya test etmek için, bu anahtarı olarak AllReplicasayarlayabilirsiniz.

Sonraki adımlar

Test edilebilirlik eylemleri hakkında daha fazla bilgi edinin

Test edilebilirlik senaryoları hakkında daha fazla bilgi edinin