Service Fabric'te hizmetlere bağlanma ve hizmetlerle iletişim kurma

Service Fabric'te bir hizmet, genellikle birden çok VM'ye dağıtılmış bir Service Fabric kümesinde bir yerde çalışır. Hizmet sahibi tarafından veya Service Fabric tarafından otomatik olarak bir yerden diğerine taşınabilir. Hizmetler statik olarak belirli bir makineye veya adrese bağlı değildir.

Service Fabric uygulaması genellikle her hizmetin özel bir görev gerçekleştirdiği birçok farklı hizmetlerden oluşur. Bu hizmetler, web uygulamasının farklı bölümlerini işleme gibi eksiksiz bir işlev oluşturmak için birbirleriyle iletişim kurabilir. Hizmetlere bağlanan ve hizmetlerle iletişim kuran istemci uygulamaları da vardır. Bu belgede Service Fabric'teki hizmetlerinizle ve hizmetleriniz arasında iletişimin nasıl ayarlanacağı açıklanır.

Hizmet iletişimlerini de ele alan bir eğitim videosu için bu sayfayı gözden geçirin:

Kendi protokolünüzü getirin

Service Fabric, hizmetlerinizin yaşam döngüsünü yönetmeye yardımcı olur, ancak hizmetlerinizin ne yaptığıyla ilgili kararlar almaz. Buna iletişim de dahildir. Hizmetiniz Service Fabric tarafından açıldığında, hizmetinizin istediğiniz protokolü veya iletişim yığınını kullanarak gelen istekler için bir uç nokta ayarlama fırsatı olur. Hizmetiniz, URI gibi herhangi bir adresleme şemasını kullanarak normal bir IP:bağlantı noktası adresini dinler. Birden çok hizmet örneği veya çoğaltması bir konak işlemini paylaşabilir; bu durumda farklı bağlantı noktaları kullanmaları veya Windows'daki http.sys çekirdek sürücüsü gibi bir bağlantı noktası paylaşım mekanizması kullanmaları gerekir. Her iki durumda da, bir konak işlemindeki her hizmet örneği veya çoğaltma benzersiz bir şekilde adreslenebilir olmalıdır.

Hizmet bulma ve çözümleme

Dağıtılmış bir sistemde hizmetler zaman içinde bir makineden diğerine geçebilir. Kaynak dengeleme, yükseltmeler, yük devretmeler veya ölçeği genişletme gibi çeşitli nedenlerle bu durum oluşabilir. Bu, hizmet farklı IP adreslerine sahip düğümlere geçtikçe hizmet uç noktası adreslerinin değiştiği ve hizmet dinamik olarak seçili bir bağlantı noktası kullanıyorsa farklı bağlantı noktalarında açabileceği anlamına gelir.

Service Fabric, Adlandırma Hizmeti adlı bir bulma ve çözüm hizmeti sağlar. Adlandırma Hizmeti, adlandırılmış hizmet örneklerini dinledikleri uç nokta adresleriyle eşleyen bir tablo tutar. Service Fabric'teki tüm adlandırılmış hizmet örnekleri, URI'ler olarak temsil edilen benzersiz adlara sahiptir, örneğin. "fabric:/MyApplication/MyService" Hizmetin adı hizmetin ömrü boyunca değişmez; yalnızca hizmetler taşındığında değişebilen uç nokta adresleridir. Bu, sabit URL'leri olan ancak IP adresinin değişebileceği web sitelerine benzer. Web'de WEB URL'lerini IP adreslerine çözümleyen DNS'e benzer şekilde, Service Fabric'in de hizmet adlarını uç nokta adreslerine eşleyen bir kayıt şirketi vardır.

Hizmetleri çözümleme ve hizmetlere bağlanma, döngüde aşağıdaki adımların çalıştırılmasını içerir:

• Çözüm: Adlandırma Hizmeti'nden bir hizmetin yayımladığı uç noktayı alın.
• Bağlan: Bu uç noktada kullandığı protokol üzerinden hizmete bağlanın.
• Yeniden deneme: Bağlantı girişimi, örneğin hizmet uç nokta adresinin son çözümlenmesinden bu yana taşınmışsa, çeşitli nedenlerle başarısız olabilir. Bu durumda, önceki çözümleme ve bağlantı adımlarının yeniden denenmiş olması gerekir ve bağlantı başarılı olana kadar bu döngü yinelenir.

Diğer hizmetlere bağlanma

Küme içindeki düğümler aynı yerel ağda olduğundan, küme içinde birbirine bağlanan hizmetler genellikle diğer hizmetlerin uç noktalarına doğrudan erişebilir. Service Fabric, hizmetler arasında bağlantı kurmayı kolaylaştırmak için Adlandırma Hizmeti'ni kullanan ek hizmetler sağlar. DNS hizmeti ve ters ara sunucu hizmeti.

DNS hizmeti

Kapsayıcılı hizmetler başta olmak üzere birçok hizmet mevcut bir URL adına sahip olabileceğinden, bunları standart DNS protokolü (Adlandırma Hizmeti protokolü yerine) kullanarak çözümleyebilmek, özellikle uygulama "lift and shift" senaryolarında çok kullanışlıdır. DNS hizmeti tam olarak bunu yapar. DNS adlarını bir hizmet adıyla eşlemenize ve dolayısıyla uç nokta IP adreslerini çözümlemenize olanak tanır.

Aşağıdaki diyagramda gösterildiği gibi, Service Fabric kümesinde çalışan DNS hizmeti, DNS adlarını, bağlanacak uç nokta adreslerini döndürmek için Adlandırma Hizmeti tarafından çözümlenen hizmet adlarına eşler. Hizmetin DNS adı oluşturma sırasında sağlanır.

DNS hizmetini kullanma hakkında daha fazla bilgi için Azure Service Fabric'te DNS hizmeti makalesine bakın.

Ters proxy hizmeti

Ters ara sunucu, HTTPS de dahil olmak üzere HTTP uç noktalarını kullanıma sunan kümedeki hizmetleri ele alır. Ters ara sunucu, belirli bir URI biçimine sahip olarak diğer hizmetleri ve yöntemlerini çağırmayı büyük ölçüde basitleştirir ve bir hizmetin Adlandırma Hizmeti'ni kullanarak başka bir hizmetle iletişim kurması için gereken çözüm, bağlanma, yeniden deneme adımlarını işler. Başka bir deyişle, bunu URL çağırmak kadar basit hale getirerek diğer hizmetleri çağırırken Adlandırma Hizmeti'ni sizden gizler.

Ters proxy hizmetini kullanma hakkında daha fazla bilgi için Azure Service Fabric'te ters proxy makalesine bakın.

Dış istemcilerden bağlantılar

Küme içindeki düğümler aynı yerel ağda olduğundan, küme içinde birbirine bağlanan hizmetler genellikle diğer hizmetlerin uç noktalarına doğrudan erişebilir. Ancak bazı ortamlarda küme, sınırlı bir bağlantı noktası kümesi üzerinden giriş trafiğini yönlendiren bir yük dengeleyicinin arkasında olabilir. Bu gibi durumlarda hizmetler, Adlandırma Hizmeti'ni kullanarak birbirleriyle iletişim kurmaya ve adresleri çözümlemeye devam edebilir, ancak dış istemcilerin hizmetlere bağlanmasına izin vermek için ek adımlar atılmalıdır.

Azure'da Service Fabric

Azure'da Service Fabric kümesi bir Azure Load Balancer arkasına yerleştirilir. Kümeye gelen tüm dış trafiğin yük dengeleyiciden geçmesi gerekir. Yük dengeleyici, belirli bir bağlantı noktasına gelen trafiği otomatik olarak aynı bağlantı noktasının açık olduğu rastgele bir düğüme iletir. Azure Load Balancer yalnızca düğümlerde açık olan bağlantı noktalarını bilir, tek tek hizmetler tarafından açılan bağlantı noktalarını bilmez.

Örneğin, 80 numaralı bağlantı noktasında dış trafiği kabul etmek için aşağıdakilerin yapılandırılması gerekir:

1. 80 numaralı bağlantı noktasını dinleyen bir hizmet yazın. Hizmetin ServiceManifest.xml bağlantı noktası 80'i yapılandırın ve hizmette şirket içinde barındırılan bir web sunucusu gibi bir dinleyici açın.

   <Resources>
       <Endpoints>
           <Endpoint Name="WebEndpoint" Protocol="http" Port="80" />
       </Endpoints>
   </Resources>
   

       class HttpCommunicationListener : ICommunicationListener
       {
           ...
   
           public Task<string> OpenAsync(CancellationToken cancellationToken)
           {
               EndpointResourceDescription endpoint =
                   serviceContext.CodePackageActivationContext.GetEndpoint("WebEndpoint");
   
               string uriPrefix = $"{endpoint.Protocol}://+:{endpoint.Port}/myapp/";
   
               this.httpListener = new HttpListener();
               this.httpListener.Prefixes.Add(uriPrefix);
               this.httpListener.Start();
   
               string publishUri = uriPrefix.Replace("+", FabricRuntime.GetNodeContext().IPAddressOrFQDN);
               return Task.FromResult(publishUri);
           }
   
           ...
       }
   
       class WebService : StatelessService
       {
           ...
   
           protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
           {
               return new[] { new ServiceInstanceListener(context => new HttpCommunicationListener(context))};
           }
   
           ...
       }
   

       class HttpCommunicationlistener implements CommunicationListener {
           ...
   
           @Override
           public CompletableFuture<String> openAsync(CancellationToken arg0) {
               EndpointResourceDescription endpoint =
                   this.serviceContext.getCodePackageActivationContext().getEndpoint("WebEndpoint");
               try {
                   HttpServer server = com.sun.net.httpserver.HttpServer.create(new InetSocketAddress(endpoint.getPort()), 0);
                   server.start();
   
                   String publishUri = String.format("http://%s:%d/",
                       this.serviceContext.getNodeContext().getIpAddressOrFQDN(), endpoint.getPort());
                   return CompletableFuture.completedFuture(publishUri);
               } catch (IOException e) {
                   throw new RuntimeException(e);
               }
           }
   
           ...
       }
   
       class WebService extends StatelessService {
           ...
   
           @Override
           protected List<ServiceInstanceListener> createServiceInstanceListeners() {
               <ServiceInstanceListener> listeners = new ArrayList<ServiceInstanceListener>();
               listeners.add(new ServiceInstanceListener((context) -> new HttpCommunicationlistener(context)));
               return listeners;		
           }
   
           ...
       }
   

2. Azure'da bir Service Fabric Kümesi oluşturun ve hizmeti barındıracak düğüm türü için özel uç nokta bağlantı noktası olarak 80 numaralı bağlantı noktasını belirtin. Birden fazla düğüm türünüz varsa, yalnızca özel uç nokta bağlantı noktasının açık olduğu düğüm türünde çalıştığından emin olmak için hizmette bir yerleştirme kısıtlaması ayarlayabilirsiniz.

   

3. Küme oluşturulduktan sonra, trafiği 80 numaralı bağlantı noktasına iletecek şekilde kümenin Kaynak Grubundaki Azure Load Balancer yapılandırın. Azure portal üzerinden küme oluştururken, bu, yapılandırılmış her özel uç nokta bağlantı noktası için otomatik olarak ayarlanır.

   

4. Azure Load Balancer, trafiğin belirli bir düğüme gönderilip gönderilmeyeceğini belirlemek için bir yoklama kullanır. Yoklama, düğümün yanıt verip vermediğini belirlemek için her düğümdeki bir uç noktayı düzenli aralıklarla denetler. Yoklama, yapılandırılmış sayıdan sonra yanıt alamazsa yük dengeleyici bu düğüme trafik göndermeyi durdurur. Azure portal üzerinden küme oluştururken, yapılandırılmış her özel uç nokta bağlantı noktası için otomatik olarak bir yoklama ayarlanır.

   

Azure Load Balancer ve yoklamanın düğümlerde çalışan hizmetleri değil yalnızca düğümleri bildiğini unutmayın. Azure Load Balancer her zaman yoklama yanıt veren düğümlere trafik gönderir, bu nedenle araştırmayı yanıtlayabilen düğümlerde hizmetlerin kullanılabilir olduğundan emin olmak için dikkatli olunmalıdır.

Reliable Services: Yerleşik iletişim API'si seçenekleri

Reliable Services çerçevesi, önceden oluşturulmuş çeşitli iletişim seçenekleriyle birlikte sunulur. Hangisinin sizin için en uygun olduğuna karar, programlama modelinin seçimine, iletişim çerçevesine ve hizmetlerinizin yazıldığı programlama diline bağlıdır.

• Belirli bir protokol yok: Belirli bir iletişim çerçevesi seçeneğiniz yoksa, ancak hızlı bir şekilde çalışmaya başlamak istiyorsanız, sizin için ideal seçenek, Reliable Services ve Reliable Actors için kesin olarak türlenmiş uzaktan yordam çağrılarına izin veren hizmet uzaktan iletişimidir. Bu, hizmet iletişimini kullanmaya başlamanın en kolay ve en hızlı yoludur. Hizmet uzaktan iletişim hizmeti adreslerinin, bağlantının, yeniden denemenin ve hata işlemenin çözümünü işler. Bu, hem C# hem de Java uygulamaları için kullanılabilir.
• HTTP: Dilden bağımsız iletişim için HTTP, service Fabric tarafından desteklenen birçok farklı dilde kullanılabilen araçlar ve HTTP sunucuları ile endüstri standardı bir seçenek sunar. Hizmetler, C# uygulamaları için ASP.NET Web API'si de dahil olmak üzere kullanılabilir herhangi bir HTTP yığınını kullanabilir. C# dilinde yazılan istemciler ve ServicePartitionClient sınıflarından ICommunicationClient yararlanabilirken Java için hizmet çözümlemesi, HTTP bağlantıları ve yeniden deneme döngüleri için veFabricServicePartitionClient sınıflarını kullanabilirCommunicationClient.
• WCF: İletişim çerçeveniz olarak WCF kullanan mevcut kodunuz varsa, sunucu tarafı için ve WcfCommunicationClientServicePartitionClient istemci için sınıfları kullanabilirsinizWcfCommunicationListener. Ancak bu yalnızca Windows tabanlı kümelerdeki C# uygulamalarında kullanılabilir. Diğer ayrıntılar için iletişim yığınının WCF tabanlı uygulaması hakkındaki bu makaleye bakın.

Özel protokolleri ve diğer iletişim çerçevelerini kullanma

Hizmetler, TCP yuvaları üzerinden özel bir ikili protokol veya Azure Event Hubs ya da Azure IoT Hub üzerinden akış olayları olsun, iletişim için herhangi bir protokolü veya çerçeveyi kullanabilir. Service Fabric, iletişim yığınınızı takabileceğiniz iletişim API'leri sağlarken, keşfedip bağlanmaya yönelik tüm çalışmalar sizden soyutlanır. Daha fazla ayrıntı için Güvenilir Hizmet iletişim modeli hakkındaki bu makaleye bakın.

Sonraki adımlar

Reliable Services iletişim modelinde bulunan kavramlar ve API'ler hakkında daha fazla bilgi edinin, ardından hizmet uzaktan iletişimini kullanmaya hızlı bir şekilde başlayın veya OWIN kendi kendine ana bilgisayarıyla Web API'sini kullanarak iletişim dinleyicisi yazmayı öğrenmek için ayrıntılı bilgi edinin.