19.03.01 - Apigee Edge untuk catatan rilis Public Cloud

Load balancing - kontrol lebih besar untuk menghapus server yang gagal

Saat mengonfigurasi load balancer untuk proxy API, Anda dapat menentukan jumlah respons terjadi sebelum server dihapus dari rotasi load balancing. Kegagalan respons berarti Apigee tidak menerima respons apa pun dari server target. Jika ini terjadi, kegagalan tambahan ini sebesar satu. Ketika Apigee menerima respons dari target, bahkan jika adalah error HTTP (seperti 500), yang dihitung sebagai respons dari server target, dan penghitung kegagalan direset. Untuk membantu memastikan bahwa respons HTTP yang buruk (seperti 500) juga menambah penghitung kegagalan untuk mengeluarkan server yang tidak responsif dari rotasi load balancing sebagai sesegera mungkin, Anda dapat menambahkan elemen <ServerUnhealthyResponse> baru dengan <ResponseCode> elemen turunan ke konfigurasi load balancer. Edge juga akan menghitung respons dengan kode tersebut sebagai kegagalan.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

Peningkatan kebijakan AccessControl

Kebijakan AccessControl menentukan alamat IP mana yang dapat melakukan panggilan ke proxy API. Elemen baru pada kebijakan tersebut memberikan kontrol lebih besar kepada developer API dalam mengidentifikasi IP yang perlu dievaluasi.

<IgnoreTrueClientIPHeader>: Opsional (default-nya adalah salah). Jika Anda menyetelnya ke true, kebijakan akan mengabaikan header True-Client-IP dan mengevaluasi alamat IP di header X-Forwarded-For, dengan mengikuti Perilaku evaluasi X-Forwarded-For yang telah Anda konfigurasi.

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

Untuk mengetahui detailnya, lihat postingan Komunitas ini.

Dua elemen baru tersedia di kebijakan RaiseFault untuk membuat FaultRules penanganan yang lebih bersih dan lebih andal.

• ShortFaultReason adalah boolean yang, jika disetel ke benar (true), akan menempatkan nama kebijakan dalam variabel fault.reason.
• AssignVariable, yang tersedia di FaultResponse, memungkinkan Anda menetapkan respons kesalahan ke variabel yang akan digunakan oleh kebijakan lain dalam alur proxy API.

Batas sekarang diberlakukan untuk Target yang Dihosting. Lihat Batas untuk mengetahui detail batas.

Sekarang Anda dapat menggunakan variabel template pesan untuk menetapkan alamat IP dan mask CIDR pada Kebijakan AccessControl. Misalnya, jika Anda ingin menyimpan Alamat IP dan mask di peta nilai kunci (KVM), Anda dapat mengambil nilai tersebut dari variabel yang Anda tetapkan dalam alur proxy API. Ini memungkinkan Anda mengubah nilai IP dengan lebih mudah saat {i>runtime<i} tanpa harus mengubah konfigurasi kebijakan.

Misalnya, daripada:

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

Anda dapat mengkonfigurasi kebijakan seperti ini, dengan asumsi nilai disimpan di KVM, dan Anda menggunakan kebijakan KeyValueMapOperations untuk mengambil nilai dan menetapkannya ke variabel yang ditampilkan di sini:

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

Pemantauan API menyediakan dua peran: Administrator Pemantauan API dan Pengguna Pemantauan API, yang dijelaskan dalam Mengakses Pemantauan API. Kebijakan ini tersedia pada Desember 2018.

Edge kini menambahkan header X-Apigee.Message-Timeout ke setiap permintaan. {i>Header<i} ini untuk penggunaan internal oleh Edge. Jangan mengandalkan nilai dalam header X-Apigee.* di proxy API Anda karena header ini tidak ditujukan untuk penggunaan pelanggan dan dapat dihapus atau diubah oleh Apigee kapan saja.

Menangani error penghapusan keystore agar panggilan API tidak gagal

x-apigee.edge.execution.sense.action selalu ditetapkan ke null

Dalam kebijakan ResponseCache, NIOTheread dijalankan tanpa penolakan dari kumpulan thread

Beberapa pengekspor log di router Apigee menyebabkan penggunaan CPU yang tinggi

404 berselang-seling di organisasi tertentu

Alur Bersama yang di-deploy tidak dieksekusi pada beberapa pemroses pesan

Perbaikan ini akan disertakan dalam rilis Edge untuk Private Cloud berikutnya.

Perbaikan ini akan disertakan dalam rilis Edge untuk Private Cloud berikutnya.

Perbaikan ini akan disertakan dalam rilis Edge untuk Private Cloud berikutnya.