Anda sedang melihat dokumentasi Apigee Edge.
Buka
Dokumentasi Apigee X. info
Konfigurasi TargetEndpoint menentukan cara Apigee Edge terhubung ke layanan backend atau API. Klien mengirimkan permintaan dan menerima respons ke/dari layanan backend. Layanan backend dapat berupa server HTTP/HTTPS, NodeJS, atau Target yang Dihosting.
Layanan backend di TargetEndpoint dapat dipanggil dengan salah satu cara berikut:
- URL langsung ke server HTTP atau HTTPS
- ScriptTarget ke skrip Node.js yang dihosting Edge
- HostedTarget ke NodeJS yang di-deploy di Lingkungan Target yang Dihosting
- Konfigurasi TargetServer
Demikian pula, kebijakan Info Layanan dapat digunakan untuk melakukan panggilan ke layanan eksternal mana pun dari alur Proxy API. Kebijakan ini mendukung penentuan URL target HTTP/HTTPS secara langsung pada kebijakan itu sendiri atau menggunakan konfigurasi TargetServer.
Konfigurasi TargetServer
Konfigurasi TargetServer memisahkan URL endpoint konkret dari Konfigurasi TargetEndpoint atau di kebijakan Info Layanan. TargetServer adalah dirujuk oleh nama, bukan URL di TargetEndpoint. Konfigurasi TargetServer akan memiliki nama host layanan backend, nomor port, dan detail lainnya.
Berikut adalah contoh konfigurasi TargetServer:
<TargetServer name="target1"> <Host>www.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
TargetServer memungkinkan Anda memiliki konfigurasi yang berbeda untuk setiap lingkungan. Kebijakan TargetEndpoint/Panggilan Layanan dapat dikonfigurasi dengan satu atau beberapa TargetServers yang bernama menggunakan LoadBalancer. Dukungan bawaan untuk load balancing meningkatkan ketersediaan API dan failover di antara instance server backend yang dikonfigurasi.
Berikut adalah contoh konfigurasi TargetEndpoint menggunakan TargetServers:
<TargetEndpoint name="default"> <HTTPTargetConnection>> <LoadBalancer> <Server name="target1"/> <Server name="target2"/> </LoadBalancer> </HTTPTargetConnection> </TargetEndpoint>
MaxFailures
Konfigurasi MaxFailures
menentukan jumlah maksimum kegagalan permintaan
ke server target. Setelah itu, server target harus ditandai sebagai tidak aktif dan dihapus
rotasi untuk semua permintaan berikutnya.
Contoh konfigurasi dengan MaxFailures
yang ditentukan:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1"/> <Server name="target2"/> <MaxFailures>5</MaxFailures> </LoadBalancer> </HTTPTargetConnection> </TargetEndpoint>
Pada contoh di atas, jika lima permintaan berturut-turut untuk "target1" gagal lalu "target1" akan dihapus dari rotasi dan semua permintaan berikutnya hanya akan dikirim ke target2.
Anti-pola
Memiliki satu TargetServer dalam konfigurasi LoadBalancer
Kebijakan TargetEndpoint atau Info Layanan dengan MaxFailures
ditetapkan ke
nilai bukan nol tidak disarankan karena dapat memiliki implikasi yang merugikan.
Pertimbangkan contoh konfigurasi berikut yang memiliki satu TargetServer
bernama "target1" dengan MaxFailures
ditetapkan ke 5 (nilai bukan nol):
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <MaxFailures>5</MaxFailures> </LoadBalancer> </HTTPTargetConnection>
Jika permintaan ke TargetServer "target1" gagal lima kali (angka ditentukan dalam MaxFailures
),
TargetServer dihapus dari rotasi. Karena tidak ada {i>TargetServers <i}lain yang akan dituju,
semua permintaan berikutnya ke Proxy API yang memiliki konfigurasi ini akan gagal dengan
503 Service Unavailable
error.
Meskipun TargetServer "target1" dapat kembali ke keadaan normal dan mengirim respons yang berhasil, permintaan ke Proxy API akan terus menghasilkan pesan error 503. Hal ini karena Edge tidak secara otomatis menempatkan TargetServer kembali secara bergilir, bahkan setelah target aktif dan berjalan kembali. Untuk mengatasi masalah ini, Proxy API harus di-deploy ulang agar Edge dapat menempatkan TargetServer kembali ke rotasi.
Jika konfigurasi yang sama digunakan dalam kebijakan Info Layanan, berarti API akan mendapatkan Error 500 setelah permintaan ke TargetServer "target1" gagal 5 kali.
Dampak
Menggunakan satu TargetServer dalam konfigurasi LoadBalancer
Kebijakan TargetEndpoint atau Info Layanan dengan MaxFailures
yang ditetapkan ke nilai bukan nol menyebabkan:
- Permintaan API akan terus-menerus gagal dengan 503/500 Error (setelah permintaan gagal selama beberapa kali MaxFailures) hingga Proxy API di-deploy ulang.
- Pemadaman layanan yang lebih lama karena rumit dan bisa memakan waktu lebih lama untuk mendiagnosis penyebab masalah ini (tanpa pengetahuan sebelumnya tentang antipola ini).
Praktik Terbaik
- Memiliki lebih dari satu TargetServer dalam konfigurasi
LoadBalancer
untuk ketersediaan yang lebih tinggi. Selalu tentukan Pemantau Kesehatan saat
MaxFailures
ditetapkan ke nilai bukan nol. Server target akan dihapus dari rotasi ketika jumlah kegagalan mencapai jumlah yang ditentukan dalamMaxFailures
. Memiliki HealthMonitor memastikan bahwa TargetServer dikembalikan ke rotasi saat segera setelah server target tersedia lagi, artinya ada tidak perlu men-deploy ulang proxy.Untuk memastikan bahwa health check dilakukan pada nomor port yang sama dengan Edge yang digunakan untuk terhubung ke server target, Apigee merekomendasikan agar Anda menghilangkan elemen turunan
<Port>
di bawah<TCPMonitor>
, kecuali jika berbeda dari porta TargetServer. Secara default,<Port>
sama dengan port TargetServer.Contoh konfigurasi dengan HealthMonitor:
<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>
Jika ada beberapa batasan, sehingga hanya satu TargetServer dan jika HealthMonitor tidak digunakan, maka jangan tentukan
MaxFailures
dalam konfigurasiLoadBalancer
.Nilai default MaxFailures adalah 0. Ini berarti bahwa Edge selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus server target dari rotasi.