Azure Service Fabric'te ters proxy

Azure Service Fabric'te yerleşik ters ara sunucu, Service Fabric kümesinde çalışan mikro hizmetlerin http uç noktaları olan diğer hizmetleri bulmasına ve bunlarla iletişim kurmasına yardımcı olur.

Mikro hizmetler iletişim modeli

Service Fabric'teki mikro hizmetler, kümedeki düğümlerin bir alt kümesinde çalışır ve çeşitli nedenlerle düğümler arasında geçiş yapabilir. Sonuç olarak, mikro hizmetlerin uç noktaları dinamik olarak değişebilir. Kümedeki diğer hizmetleri bulmak ve bunlarla iletişim kurmak için mikro hizmetin aşağıdaki adımları gerçekleştirmesi gerekir:

1. Adlandırma hizmeti aracılığıyla hizmet konumunu çözün.
2. Hizmete bağlanın.
3. Bağlantı hatalarına uygulamak için hizmet çözümleme ve yeniden deneme ilkeleri uygulayan bir döngüde önceki adımları sarmalama

Daha fazla bilgi için bkz . Hizmetlere bağlanma ve hizmetlerle iletişim kurma.

Ters ara sunucuyu kullanarak iletişim kurma

Ters ara sunucu, her düğümde çalışan ve istemci hizmetleri adına uç nokta çözümlemesi, otomatik yeniden deneme ve diğer bağlantı hatalarını işleyen bir hizmettir. Ters ara sunucu, istemci hizmetlerinden gelen istekleri işlerken çeşitli ilkeler uygulayacak şekilde yapılandırılabilir. Ters ara sunucu kullanmak, istemci hizmetinin istemci tarafı HTTP iletişim kitaplıklarını kullanmasına olanak tanır ve hizmette özel çözüm ve yeniden deneme mantığı gerektirmez.

Ters ara sunucu, istemci hizmetlerinin diğer hizmetlere istek göndermek için kullanması için yerel düğümde bir veya daha fazla uç noktayı kullanıma sunar.

Mikro hizmetlere küme dışından ulaşma

Mikro hizmetler için varsayılan dış iletişim modeli, her hizmete doğrudan dış istemcilerden erişilemeyen bir kabul modelidir. Mikro hizmetler ve dış istemciler arasındaki bir ağ sınırı olan Azure Load Balancer, ağ adresi çevirisi gerçekleştirir ve dış istekleri iç IP:bağlantı noktası uç noktalarına iletir. Bir mikro hizmetin uç noktasını dış istemciler için doğrudan erişilebilir hale getirmek için, önce Load Balancer'ı trafiği hizmetin kümede kullandığı her bağlantı noktasına iletecek şekilde yapılandırmanız gerekir. Ancak mikro hizmetlerin çoğu, özellikle durum bilgisi olan mikro hizmetler kümenin tüm düğümlerinde çalışmaz. Mikro hizmetler yük devretme sırasında düğümler arasında hareket edebilir. Böyle durumlarda Load Balancer, trafiği ileteceği çoğaltmaların hedef düğümünün konumunu etkili bir şekilde belirleyemez.

Küme dışından ters ara sunucu aracılığıyla mikro hizmetlere ulaşma

Load Balancer'da tek bir hizmetin bağlantı noktasını yapılandırmak yerine, Load Balancer'da yalnızca ters proxy'nin bağlantı noktasını yapılandırabilirsiniz. Bu yapılandırma, küme dışındaki istemcilerin ek yapılandırma olmadan ters ara sunucuyu kullanarak küme içindeki hizmetlere ulaşmasını sağlar.

Ters ara sunucuyu kullanarak hizmetleri ele almak için URI biçimi

Ters proxy, gelen isteğin iletilmesi gereken hizmet bölümünü tanımlamak için belirli bir tekdüzen kaynak tanımlayıcısı (URI) biçimi kullanır:

http(s)://<Cluster FQDN | internal IP>:Port/<ServiceInstanceName>/<Suffix path>?PartitionKey=<key>&PartitionKind=<partitionkind>&ListenerName=<listenerName>&TargetReplicaSelector=<targetReplicaSelector>&Timeout=<timeout_in_seconds>

• http(ler): Ters proxy, HTTP veya HTTPS trafiğini kabul etmek için yapılandırılabilir. HTTPS iletme için, HTTPS'yi dinlemek için ters ara sunucu kurulumuna sahip olduğunuzda ters proxy ile güvenli bir hizmete bağlanma bölümüne bakın.

• Küme tam etki alanı adı (FQDN) | iç IP: Dış istemciler için, ters proxy'yi küme etki alanı üzerinden (mycluster.eastus.cloudapp.azure.com gibi) erişilebilir olacak şekilde yapılandırabilirsiniz. Varsayılan olarak, ters ara sunucu her düğümde çalışır. İç trafik için ters ara sunucuya localhost'ta veya 10.0.0.1 gibi herhangi bir iç düğüm IP'sinde ulaşılabilir.

• Bağlantı noktası: Bu, ters ara sunucu için belirtilen 19081 gibi bir bağlantı noktasıdır.

• ServiceInstanceName: Bu, "fabric:/" şeması olmadan ulaşmaya çalıştığınız dağıtılan hizmet örneğinin tam adıdır. Örneğin, fabric:/myapp/myservice/ hizmetine ulaşmak için myapp/myservice komutunu kullanabilirsiniz.

  Hizmet örneği adı büyük/küçük harfe duyarlıdır. URL'de hizmet örneği adı için farklı bir büyük/küçük harf kullanılması, isteklerin 404 (Bulunamadı) ile başarısız olmasına neden olur.

• Sonek yolu: Bu, bağlanmak istediğiniz hizmetin myapi/values/add/3 gibi gerçek URL yoludur.

• PartitionKey: Bölümlenmiş bir hizmet için, bu, ulaşmak istediğiniz bölümün hesaplanan bölüm anahtarıdır. Bunun bölüm kimliği GUID'si olmadığını unutmayın. Bu parametre, tek bölüm düzenini kullanan hizmetler için gerekli değildir.

• PartitionKind: Bu hizmet bölümü düzenidir. Bu 'Int64Range' veya 'Named' olabilir. Bu parametre, tek bölüm düzenini kullanan hizmetler için gerekli değildir.

• ListenerName Hizmetten alınan uç noktalar {"Endpoints":{"Listener1":"Endpoint1","Listener2":"Endpoint2" ...}} biçimindedir. Hizmet birden çok uç noktayı kullanıma sunarsa, istemci isteğinin iletilmesi gereken uç noktayı tanımlar. Hizmetin yalnızca bir dinleyicisi varsa bu atlanabilir.

• TargetReplicaSelector Bu, hedef çoğaltmanın veya örneğin nasıl seçilmesi gerektiğini belirtir.

  • Hedef hizmet durum bilgisi olduğunda TargetReplicaSelector aşağıdakilerden biri olabilir: 'PrimaryReplica', 'RandomSecondaryReplica' veya 'RandomReplica'. Bu parametre belirtilmediğinde varsayılan değer 'PrimaryReplica'dır.
  • Hedef hizmet durum bilgisi olmadığında ters ara sunucu, isteği iletmek için hizmet bölümünün rastgele bir örneğini seçer.

• Zaman aşımı: İstemci isteği adına hizmete ters ara sunucu tarafından oluşturulan HTTP isteğinin zaman aşımını belirtir. Varsayılan değer 120 saniyedir. Bu isteğe bağlı bir parametredir.

Örnek kullanım

Örnek olarak, şu URL'de bir HTTP dinleyicisi açan fabric:/MyApp/MyService hizmetini alalım:

http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/

Hizmetin kaynakları şunlardır:

• /index.html
• /api/users/<userId>

Hizmet tek bölümleme düzenini kullanıyorsa PartitionKey ve PartitionKind sorgu dizesi parametreleri gerekli değildir ve hizmete ağ geçidi şu şekilde kullanılarak ulaşılabilir:

• Harici: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
• Dahili: http://localhost:19081/MyApp/MyService

Hizmet Uniform Int64 bölümleme düzenini kullanıyorsa, hizmetin bir bölümüne ulaşmak için PartitionKey ve PartitionKind sorgu dizesi parametreleri kullanılmalıdır:

• Harici: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range
• Dahili: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

Hizmetin kullanıma açık olduğu kaynaklara ulaşmak için kaynak yolunu URL'deki hizmet adından sonra yerleştirmeniz yeterlidir:

• Harici: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService/index.html?PartitionKey=3&PartitionKind=Int64Range
• Dahili: http://localhost:19081/MyApp/MyService/api/users/6?PartitionKey=3&PartitionKind=Int64Range

Ağ geçidi bu istekleri hizmetin URL'sine iletir:

• http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/index.html
• http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/api/users/6

Bağlantı noktası paylaşım hizmetleri için özel işleme

Service Fabric ters ara sunucusu bir hizmet adresini yeniden çözümlemeyi dener ve hizmete ulaşılamadığında isteği yeniden dener. Genel olarak, bir hizmete ulaşılamadığında, hizmet örneği veya çoğaltma normal yaşam döngüsünün bir parçası olarak farklı bir düğüme taşınır. Bu durumda ters ara sunucu, ilk çözümlenen adreste bir uç noktanın artık açık olmadığını belirten bir ağ bağlantısı hatası alabilir.

Ancak, çoğaltmalar veya hizmet örnekleri bir konak işlemini paylaşabilir ve http.sys tabanlı bir web sunucusu tarafından barındırıldığında aşağıdakiler de dahil olmak üzere bir bağlantı noktasını paylaşabilir:

• System.Net.HttpListener
• ASP.NET Core WebListener
• Katana

Bu durumda, web sunucusu büyük olasılıkla konak işleminde kullanılabilir ve isteklere yanıt verir, ancak çözümlenen hizmet örneği veya çoğaltması artık konakta kullanılamaz. Bu durumda, ağ geçidi web sunucusundan bir HTTP 404 yanıtı alır. Bu nedenle, bir HTTP 404 yanıtının iki farklı anlamı olabilir:

• Servis Talebi 1: Hizmet adresi doğru, ancak kullanıcının istediği kaynak yok.
• 2. Olay: Hizmet adresi yanlış ve kullanıcının istediği kaynak farklı bir düğümde olabilir.

İlk durum, kullanıcı hatası olarak kabul edilen normal bir HTTP 404'dür. Ancak ikinci durumda, kullanıcı var olan bir kaynak istedi. Ters ara sunucu, hizmetin kendisi taşındığından bu proxy'yi bulamadı. Ters proxy'nin adresi yeniden çözümlemesi ve isteği yeniden denemesi gerekir.

Bu nedenle ters ara sunucu, bu iki durum arasında ayrım yapmak için bir yönteme ihtiyaç duyar. Bu ayrımı yapmak için sunucudan bir ipucu gerekir.

• Varsayılan olarak, ters ara sunucu 2. durumu varsayar ve isteği yeniden çözmeyi ve yayımlamayı dener.

• Ters ara sunucuya 1. büyük/küçük harf durumunu göstermek için hizmet aşağıdaki HTTP yanıt üst bilgisini döndürmelidir:

  X-ServiceFabric : ResourceNotFound

Bu HTTP yanıt üst bilgisi, istenen kaynağın mevcut olmadığı normal bir HTTP 404 durumunu gösterir ve ters ara sunucu hizmet adresini yeniden çözümlemeye çalışmaz.

Kapsayıcılarda çalışan hizmetler için özel işleme

Kapsayıcıların içinde çalışan hizmetler için ortam değişkenini Fabric_NodeIPOrFQDN kullanarak aşağıdaki kodda olduğu gibi ters proxy URL'sini oluşturabilirsiniz:

    var fqdn = Environment.GetEnvironmentVariable("Fabric_NodeIPOrFQDN");
    var serviceUrl = $"http://{fqdn}:19081/DockerSFApp/UserApiContainer";

Yerel küme için varsayılan Fabric_NodeIPOrFQDN olarak "localhost" olarak ayarlanır. Kapsayıcıların düğümde çalışan ters ara sunucuya erişebildiğinden emin olmak için yerel kümeyi parametresiyle -UseMachineName başlatın. Daha fazla bilgi için bkz . Kapsayıcılarda hata ayıklamak için geliştirici ortamınızı yapılandırma.

Docker Compose kapsayıcıları içinde çalışan Service Fabric hizmetleri için http: veya https: yapılandırma özel bir docker-compose.yml Bağlantı Noktaları bölümü gerekir. Daha fazla bilgi için bkz . Azure Service Fabric'te Docker Compose dağıtım desteği.

Sonraki adımlar

• Kümede ters ara sunucu ayarlama ve yapılandırma.
• Ters proxy ile HTTP hizmetinin güvenliğini sağlamak için iletmeyi ayarlama
• Ters proxy olaylarını tanılama
• GitHub'daki örnek projedeki hizmetler arasındaki HTTP iletişimi örneğine bakın.
• Reliable Services uzaktan iletişim ile uzaktan yordam çağrıları
• Reliable Services'da OWIN kullanan Web API'si
• Reliable Services kullanarak WCF iletişimi