19.03.01 - Apigee Edge untuk catatan rilis Public Cloud

Load balancing - lebih banyak kontrol untuk menghapus server yang gagal

Saat mengonfigurasi load balancer untuk proxy API, Anda dapat menentukan jumlah kegagalan respons yang terjadi sebelum server dihapus dari rotasi load balancing. Kegagalan respons berarti Apigee tidak menerima respons apa pun dari server target. Jika ini terjadi, penghitung kegagalan akan bertambah satu. Saat Apigee menerima respons dari target, meskipun responsnya 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 akan menambah penghitung kegagalan untuk menyingkirkan server yang tidak responsif dari rotasi load balancing sesegera mungkin, Anda dapat menambahkan elemen <ServerUnhealthyResponse> baru dengan elemen turunan <ResponseCode> 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 yang dapat melakukan panggilan ke proxy API. Elemen baru pada kebijakan tersebut memberi developer API kontrol yang lebih besar dalam mengidentifikasi alamat IP yang akan dievaluasi.

<IgnoreTrueClientIPHeader>: Opsional (default-nya adalah false). Jika Anda menetapkannya ke benar (true), kebijakan akan mengabaikan header True-Client-IP dan mengevaluasi alamat IP di header X-Forwarded-For, 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 dalam kebijakan RaiseFault untuk menjadikan penanganan FaultRules lebih bersih dan lebih andal.

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

Batas kini diterapkan untuk Target yang Dihosting. Lihat Batas untuk mengetahui detail tentang batas.

Kini 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 dalam peta nilai kunci (KVM), Anda dapat mengambil nilai tersebut dari variabel yang ditetapkan dalam alur proxy API. Hal ini memungkinkan Anda mengubah nilai IP dengan lebih mudah saat runtime tanpa harus mengubah konfigurasi kebijakan Anda.

Misalnya, daripada:

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

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

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

API Monitoring menyediakan dua peran: Administrator API Monitoring dan API Monitoring User, yang dijelaskan dalam Access API Monitoring. Fitur ini tersedia pada Desember 2018.

Edge kini menambahkan header X-Apigee.Message-Timeout ke setiap permintaan. Header ini untuk penggunaan internal oleh Edge. Jangan mengandalkan nilai di 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 sehingga panggilan API tidak gagal

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

Dalam kebijakan ResponseCache, NIOTheread dieksekusi tanpa penolakan dari kumpulan thread

Beberapa pengekspor log di router Apigee menyebabkan penggunaan CPU yang tinggi

404 yang berselang-seling di organisasi tertentu

Alur Bersama yang Di-deploy tidak berjalan di beberapa pemroses pesan

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

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

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