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

Service Fabric'te bir hizmet, service Fabric kümesinde bir yerde çalışır ve genellikle birden çok VM'ye dağıtılı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önetmenize yardımcı olur, ancak hizmetlerinizin ne yaptığı konusunda karar vermez. 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ıdır. Hizmetiniz, URI gibi herhangi bir adresleme şemasını kullanarak normal bir IP:bağlantı noktası adresini dinler. Birden çok hizmet örneği veya çoğaltma 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ğinin veya çoğaltmanın benzersiz bir şekilde adreslenebilir olması gerekir.

Hizmet bulma ve çözümleme

Dağıtılmış bir sistemde hizmetler zaman içinde bir makineden diğerine geçebilir. Bu durum kaynak dengeleme, yükseltmeler, yük devretmeler veya ölçeği genişletme gibi çeşitli nedenlerle 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çilen 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 üzerindeki DNS'ye benzer şekilde, web sitesi URL'lerini IP adreslerine çözümleyen Service Fabric'in 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ümlemek, özellikle de 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ıyla eşler. Hizmetin DNS adı, oluşturma sırasında sağlanır.

DNS hizmetini kullanma hakkında daha fazla bilgi için Bkz . Azure Service Fabric'te DNS hizmeti makalesi.

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 adlandırma hizmetini kullanarak bir hizmetin 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, bir küme giriş trafiğini sınırlı bir bağlantı noktası kümesi üzerinden yönlendiren bir yük dengeleyicinin arkasında olabilir. Bu gibi durumlarda hizmetler yine birbirleriyle iletişim kurabilir ve Adlandırma Hizmeti'ni kullanarak adresleri çözümleyebilir, 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, Azure Load Balancer'ın arkasına yerleştirilir. Kümeye gelen tüm dış trafik yük dengeleyiciden geçmelidir. Yük dengeleyici, belirli bir bağlantı noktasında gelen trafiği otomatik olarak aynı bağlantı noktası açık olan 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 80 numaralı bağlantı noktasını 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 iletmek için kümenin Kaynak Grubundaki Azure Load Balancer'ı yapılandırın. Azure portalı aracılığıyla küme oluştururken, bu, yapılandırılan 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 araştırma 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ı aracılığıyla küme oluştururken, yapılandırılan 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ını veren düğümlere trafik gönderir, bu nedenle yoklamayı 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 iyi şekilde çalışacağına ilişkin 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 olanak tanıyan 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, tümü Service Fabric tarafından desteklenen birçok farklı dilde kullanılabilen araçlar ve HTTP sunucuları ile endüstri standardı bir seçim sağlar. 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 yararlanırken Java için hizmet çözümlemesi, HTTP bağlantıları ve yeniden deneme döngüleri için ve FabricServicePartitionClient sınıflarını kullanabilirCommunicationClient.
• WCF: İletişim çerçeveniz olarak WCF kullanan mevcut kodunuz varsa, sunucu tarafı için ve WcfCommunicationClient ServicePartitionClient istemci için sınıflarını kullanabilirsinizWcfCommunicationListener. Ancak bu yalnızca Windows tabanlı kümelerdeki C# uygulamaları için kullanılabilir. Daha fazla ayrıntı 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 veya 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ı bağlayabileceğiniz iletişim API'leri sağlarken, keşfedilecek ve bağlanılan 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 sağlanan 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 self-host ile Web API'sini kullanarak iletişim dinleyicisi yazmayı öğrenmek için ayrıntılı bilgi edinin.