Anda sedang melihat dokumentasi Apigee dan Apigee Hybrid.
Lihat dokumentasi
Apigee Edge.
Konfigurasi TargetEndpoint menentukan cara Apigee terhubung ke layanan atau API backend. Aplikasi ini mengirim permintaan dan menerima respons ke/dari layanan backend. Layanan backend dapat berupa server HTTP/HTTPS atau NodeJS.
Layanan backend di TargetEndpoint dapat dipanggil dengan salah satu cara berikut:
- URL langsung ke server HTTP atau HTTPS
- Konfigurasi TargetServer
Demikian pula, kebijakan ServiceCallout dapat digunakan untuk melakukan panggilan ke layanan eksternal apa pun dari alur Proxy API. Kebijakan ini mendukung penentuan URL target HTTP/HTTPS baik secara langsung dalam kebijakan itu sendiri atau menggunakan konfigurasi TargetServer.
Konfigurasi TargetServer
Konfigurasi TargetServer memisahkan URL endpoint konkret dari konfigurasi TargetEndpoint atau dalam kebijakan Panggilan Layanan. TargetServer dirujuk berdasarkan 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/Service Callout dapat dikonfigurasi dengan satu atau beberapa TargetServer 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 TargetServer:
<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 jumlah ini tercapai, server target akan ditandai sebagai tidak aktif dan dihapus
dari 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>Dalam contoh di atas, jika lima permintaan berturut-turut gagal untuk "target1", maka "target1" akan dihapus dari rotasi dan semua permintaan berikutnya hanya akan dikirim ke target2.
Antipola
Memiliki satu TargetServer dalam konfigurasi LoadBalancer dari kebijakan TargetEndpoint atau Panggilan Layanan dengan MaxFailures yang ditetapkan ke nilai non-nol tidak direkomendasikan karena dapat menimbulkan implikasi yang merugikan.
Pertimbangkan contoh konfigurasi berikut yang memiliki satu TargetServer bernama "target1" dengan MaxFailures yang 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 (jumlah yang ditentukan dalam MaxFailures),
TargetServer akan dihapus dari rotasi. Karena tidak ada TargetServer lain untuk melakukan failover,
semua permintaan berikutnya ke API Proxy yang memiliki konfigurasi ini akan gagal dengan error
503 Service Unavailable.
Meskipun TargetServer "target1" kembali ke kondisi normal dan dapat mengirim respons yang berhasil, permintaan ke Proxy API akan terus menampilkan error 503. Hal ini karena Apigee tidak otomatis mengembalikan TargetServer ke dalam rotasi meskipun target sudah aktif dan berjalan kembali. Untuk mengatasi masalah ini, Proxy API harus di-deploy ulang agar Apigee dapat menempatkan TargetServer kembali ke dalam rotasi.
Jika konfigurasi yang sama digunakan dalam kebijakan Panggilan Layanan, permintaan API akan mendapatkan Error 500 setelah permintaan ke TargetServer "target1" gagal 5 kali.
Dampak
Menggunakan satu TargetServer dalam konfigurasi LoadBalancer dari kebijakan TargetEndpoint atau Panggilan Layanan dengan MaxFailures yang ditetapkan ke nilai bukan nol akan menyebabkan:
- Permintaan API akan gagal dengan Error 503/500 secara terus-menerus (setelah permintaan gagal sebanyak MaxFailures) hingga Proxy API di-deploy ulang.
- Pemadaman yang lebih lama karena sulit dan dapat memerlukan waktu lebih lama untuk mendiagnosis penyebab masalah ini (tanpa pengetahuan sebelumnya tentang antipola ini).
Praktik Terbaik
- Memiliki lebih dari satu TargetServer dalam konfigurasi
LoadBalanceruntuk ketersediaan yang lebih tinggi. Selalu tentukan Pemantau Status jika
MaxFailuresdisetel ke nilai selain nol. Server target akan dihapus dari rotasi saat jumlah kegagalan mencapai jumlah yang ditentukan dalamMaxFailures. Dengan HealthMonitor, TargetServer akan dimasukkan kembali ke rotasi segera setelah server target tersedia lagi, yang berarti tidak perlu men-deploy ulang proxy.Untuk memastikan bahwa health check dilakukan pada nomor port yang sama dengan yang digunakan Apigee untuk terhubung ke server target, Apigee merekomendasikan agar Anda menghilangkan elemen turunan
<Port>di bawah<TCPMonitor>kecuali jika berbeda dengan port 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 batasan sehingga hanya ada satu TargetServer dan jika HealthMonitor tidak digunakan, jangan tentukan
MaxFailuresdalam konfigurasiLoadBalancer.Nilai default MaxFailures adalah 0. Artinya, Apigee selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus server target dari rotasi.