Service Fabric test edilebilirlik senaryoları: Hizmet iletişimi

Makale
06/01/2023

Azure Service Fabric'te mikro hizmetler ve hizmet odaklı mimari stilleri doğal olarak ortaya çıkabilir. 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ından durum bilgisi olmayan bir web hizmetiniz ve iletişim kurması gereken durum bilgisi olan bir veri depolama hizmetiniz vardır.

Hizmetlerden hizmete iletişim, 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 için genellikle iyi miktarda test ve doğrulama ile biraz özen gerekir.

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, 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ıya 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ığı 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, hizmet örneklerinizi 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 kullanılabilirliklerini en üst düzeye çıkarmak için taşır.

Hizmetler kümede hareket ettikçe, istemcileriniz ve diğer hizmetler 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ğunuzdan bu yana taşındı. Bu, bir hizmet yaşam döngüsünün normal bir parçasıdır ve uygulamanızın kullanım ömrü boyunca gerçekleşmesi beklenmelidir.
Hizmet örneği veya bölüm çoğaltması taşıma aşamasındadır. 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ı unutmayın:

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şlattığından 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ı için zaman sağlar.

Test etme: 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:

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
```
Düğümü durdurun.

Bir düğüm durdurulduğunda, Service Fabric söz konusu düğümdeki tüm hizmet örneklerini veya bölümlerini kümedeki diğer kullanılabilir düğümlerden birine taşır. Kümenizden bir düğümün 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ı test etmek de ö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 çoğaltma çekirdeğinin kullanılabilir olması gerektiği anlamına gelir. Yaygın donanım arızası 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 bu olasılığın farkında olması ve arayanlara düzgün bir şekilde iletebileceği de önemlidir.

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ı kapatmadan çekirdek kaybına neden olmak istediğimizi belirtmek için olarak ayarlıyoruz QuorumLossModeQuorumReplicas . 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