Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi
TargetEndpoint yapılandırması, Apigee Edge'in bir arka uç hizmetine veya API'ye bağlanma şeklini tanımlar. İstekleri gönderir ve arka uç hizmetinden yanıtları alır. Arka uç hizmeti bir HTTP/HTTPS sunucusu, NodeJS veya barındırılan hedef olabilir.
TargetEndpoint'teki arka uç hizmeti aşağıdaki yöntemlerden biriyle çağrılabilir:
- HTTP veya HTTPS sunucusuna doğrudan URL
- ScriptTarget'ı Edge'de barındırılan bir Node.js komut dosyasına
- Barındırılan hedef ortamda dağıtılan NodeJS'ye HostedTarget
- TargetServer yapılandırması
Benzer şekilde, API proxy akışından herhangi bir harici hizmete çağrı yapmak için Hizmet Çağrısı politikası kullanılabilir. Bu politika, HTTP/HTTPS hedef URL'lerinin doğrudan politikada veya TargetServer yapılandırması kullanılarak tanımlanmasını destekler.
TargetServer yapılandırması
TargetServer yapılandırması, somut uç nokta URL'lerini TargetEndpoint yapılandırmalarından veya hizmet çağrısı politikalarından ayırır. TargetServer, TargetEndpoint'teki URL yerine adıyla referans verilir. TargetServer yapılandırmasında arka uç hizmetinin ana makine adı, bağlantı noktası numarası ve diğer ayrıntılar bulunur.
Aşağıda örnek bir TargetServer yapılandırması verilmiştir:
<TargetServer name="target1"> <Host>www.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
TargetServer, her ortam için farklı yapılandırmalara sahip olmanızı sağlar. Bir LoadBalancer kullanılarak bir veya daha fazla adlandırılmış TargetServer ile bir TargetEndpoint/Service Callout politikası yapılandırılabilir. Yük dengeleme için yerleşik destek, API'lerin kullanılabilirliğini ve yapılandırılmış arka uç sunucusu örnekleri arasında yük devretmeyi artırır.
TargetServer'ları kullanan örnek bir TargetEndpoint yapılandırmasını aşağıda bulabilirsiniz:
<TargetEndpoint name="default">
<HTTPTargetConnection>>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>MaxFailures
MaxFailures yapılandırması, hedef sunucunun devre dışı olarak işaretlenip sonraki tüm istekler için rotasyondan kaldırılmadan önce hedef sunucuda oluşabilecek maksimum istek hatası sayısını belirtir.
MaxFailures belirtilmiş bir örnek yapılandırma:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>Yukarıdaki örnekte, "target1" için beş istek art arda başarısız olursa "target1" dönüşümlü yayınlamadan kaldırılır ve sonraki tüm istekler yalnızca target2'ye gönderilir.
Antipattern
LoadBalancer yapılandırmasında MaxFailures değeri sıfır olmayan bir değere ayarlanmış tek bir TargetServer'ın bulunması, olumsuz sonuçlara yol açabileceğinden önerilmez.
MaxFailures değeri 5 (sıfır olmayan bir değer) olarak ayarlanmış ve "target1" adlı tek bir TargetServer'a sahip aşağıdaki örnek yapılandırmayı göz önünde bulundurun:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Algorithm>RoundRobin</Algorithm>
<Server name="target1" />
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>"target1" TargetServer'ına yapılan istekler beş kez başarısız olursa (MaxFailures içinde belirtilen sayı), TargetServer rotasyondan kaldırılır. Yedek olarak kullanılabilecek başka TargetServer'lar olmadığından, bu yapılandırmaya sahip API proxy'sine yapılan tüm sonraki istekler 503 Service Unavailable hatasıyla başarısız olur.
TargetServer "target1" normal durumuna dönse ve başarılı yanıtlar gönderebilse bile API proxy'sine yapılan istekler 503 hataları döndürmeye devam eder. Bunun nedeni, hedef tekrar çalışır duruma geldikten sonra bile Edge'in TargetServer'ı otomatik olarak tekrar kullanıma almamasıdır. Bu sorunu gidermek için Edge'in TargetServer'ı tekrar kullanıma alması amacıyla API Proxy'nin yeniden dağıtılması gerekir.
Hizmet Çağrısı politikasında aynı yapılandırma kullanılırsa TargetServer "target1"e yapılan istekler 5 kez başarısız olduktan sonra API istekleri 500 hatası alır.
Etki
LoadBalancer yapılandırmasında tek bir TargetServer kullanma veya MaxFailures değeri sıfır olmayan bir TargetEndpoint ya da Hizmet Çağrısı politikası kullanma şu sorunlara neden olur:
- API Proxy yeniden dağıtılana kadar API istekleri sürekli olarak 503/500 hatalarıyla başarısız olur (istekler MaxFailures sayısı kadar başarısız olduktan sonra).
- Bu sorunun nedenini teşhis etmek zor olduğundan (bu anti-desen hakkında önceden bilgi sahibi olmadan) daha uzun süreli kesinti yaşanabilir.
En İyi Uygulama
- Daha yüksek kullanılabilirlik için
LoadBalanceryapılandırmasında birden fazla TargetServer'a sahip olun. MaxFailuressıfır dışında bir değere ayarlandığında her zaman bir sağlık monitörü tanımlayın. Bir hedef sunucu, hata sayısıMaxFailuresiçinde belirtilen sayıya ulaştığında rotasyondan kaldırılır. HealthMonitor'un olması, hedef sunucu tekrar kullanılabilir hale gelir gelmez TargetServer'ın tekrar rotasyona alınmasını sağlar. Bu da proxy'nin yeniden dağıtılmasına gerek olmadığı anlamına gelir.Sağlık kontrolünün, Edge'in hedef sunuculara bağlanmak için kullandığı bağlantı noktası numarasıyla aynı bağlantı noktası numarası üzerinde yapılmasını sağlamak için Apigee, TargetServer bağlantı noktasından farklı olmadığı sürece
<TCPMonitor>altındaki<Port>alt öğesini atlamanızı önerir. Varsayılan olarak<Port>, TargetServer bağlantı noktasıyla aynıdır.HealthMonitor ile örnek yapılandırma:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> </TargetEndpoint>Yalnızca bir TargetServer'ın kullanılabileceği ve HealthMonitor'ın kullanılmadığı bir kısıtlama varsa
LoadBalanceryapılandırmasındaMaxFailuresbelirtmeyin.MaxFailures'ın varsayılan değeri 0'dır. Bu, Edge'in her istek için her zaman hedefe bağlanmaya çalıştığı ve hedef sunucuyu rotasyondan hiçbir zaman kaldırmadığı anlamına gelir.