Konfigurieren einer Cacherichtlinie

  • 5 Minuten

Für die meisten Organisationen ist eine optimale API-Leistung unerlässlich. Durch die Verwendung eines Caches für kompilierte Antworten in Azure API Management können Sie die Antwortzeit von APIs auf Aufrufe reduzieren.

Angenommen, es besteht großer Bedarf an der Brettspiel-API für schnellere Antworten auf Anforderungen. Benutzer erkundigen sich beispielsweise häufig nach den Preisen der verschiedenen Größen der Spielbretter. API Management-Richtlinien können Antworten durch das Konfigurieren eines Caches für vorbereitete Antworten beschleunigen. Wenn eine Anforderung von einem*einer Benutzer*in empfangen wird, überprüft API Management, ob bereits eine geeignete Antwort im Cache gespeichert ist. Wenn dies der Fall ist, kann die Antwort ohne erneutes Erstellen aus der Datenquelle an den Benutzer gesendet werden.

Hier lernen Sie, wie Sie einen solchen Cache konfigurieren.

Steuern des API Management-Caches

Sie verwenden zum Einrichten eines Caches eine Richtlinie für ausgehenden Datenverkehr namens cache-store für das Speichern von Antworten. Außerdem verwenden Sie eine Richtlinie für eingehenden Datenverkehr namens cache-lookup, um zu überprüfen, ob für die aktuelle Anforderung eine zwischengespeicherte Antwort zur Verfügung steht. Im folgenden Beispiel werden diese beiden Richtlinien veranschaulicht:

<policies>
    <inbound>
        <base />
        <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <cache-store duration="60" />
        <base />
    </outbound>
    </on-error>
        <base />
    </on-error>
</policies>

Sie können im Cache anstelle einer vollständigen Antwort auch nur einzelne Werte speichern. Verwenden Sie die Richtlinie cache-store-value, um den Wert mit einem Identifizierungsschlüssel hinzuzufügen. Rufen Sie mithilfe der Richtlinie cache-lookup-value den Wert aus dem Cache ab. Verwenden Sie die Richtlinie cache-remove-value zum Entfernen eines Werts, bevor dieser abläuft:

<policies>
    <inbound>
        <cache-lookup-value key="12345"
            default-value="$0.00"
            variable-name="boardPrice"
            caching-type="internal" />
        <base />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <cache-store-value key="12345"
            value="$3.60"
            duration="3600"
            caching-type="internal" />
        <base />
    </outbound>
    </on-error>
        <base />
    </on-error>
</policies>

Verwenden von vary-by-Tags

Sie müssen sicherzustellen, dass eine Antwort aus dem Cache für die ursprüngliche Anforderung relevant ist. Sie möchten jedoch auch den Cache so viel wie möglich verwenden. Nehmen wir beispielsweise an, dass die „Stock Management“-API Ihres Unternehmens eine GET-Anforderung für die folgende URL erhalten hat und das Ergebnis gespeichert hat:

http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=1128

Diese Anforderung soll die Lagerbestände für das Produkt mit der Artikelnummer 3416 überprüfen. Die Kunden-ID wird von einer separaten Richtlinie verwendet und verändert die Antwort nicht. Nachfolgende Anforderungen für die gleiche Artikelnummer können vom Cache verarbeitet werden, solange der Datensatz nicht abgelaufen ist. So weit, so gut.

Nehmen wir jetzt an, dass ein anderer Kunde das gleiche Produkt bestellen möchte:

http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=5238

Standardmäßig kann die Antwort nicht aus dem Cache bereitgestellt werden, da sich die Kunden-IDs unterscheiden.

Die Entwickler*innen betonen allerdings, dass die Kunden-ID die Antwort nicht verändert. Es wäre effizienter, wenn Anforderungen für das gleiche Produkt von verschiedenen Kunden vom Cache zurückgegeben werden könnten. Den Kunden würden weiterhin die richtigen Informationen angezeigt werden.

Verwenden Sie das Element vary-by-query-parameter in der <cache-lookup>-Richtlinie, um dieses Standardverhalten zu ändern:

<policies>
    <inbound>
        <base />
        <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal">
            <vary-by-query-parameter>partnumber</vary-by-query-parameter>
        </cache-lookup>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <cache-store duration="60" />
        <base />
    </outbound>
    </on-error>
        <base />
    </on-error>
</policies>

Mithilfe dieser Richtlinie speichert und trennt der Cache die Antworten nach Produkten, da diese unterschiedliche Artikelnummern aufweisen. Der Cache speichert die Antworten nicht nach Kunde, da dieser Abfrageparameter nicht aufgeführt ist.

Azure API Management führt standardmäßig keine Untersuchung von HTTP-Headern durch, um zu ermitteln, ob eine zwischengespeicherte Antwort für eine bestimmte Anforderung geeignet ist. Verwenden Sie das Tag <vary-by-header>, wenn ein Header eine Antwort erheblich verändern kann. Arbeiten Sie mit Ihrem Entwicklerteam zusammen, um zu verstehen, wie jede API Abfrageparameter und Header verwendet, sodass Sie entscheiden können, welche vary-by-Tags in Ihrer Richtlinie verwendet werden sollen.

Im <cache-lookup>-Tag befindet sich außerdem das Attribut vary-by-developer, das vorhanden sein muss und standardmäßig auf FALSE festgelegt ist. Wenn dieses Attribut auf TRUE festgelegt ist, untersucht API Management den in den einzelnen Anforderungen angegebenen Abonnementschlüssel. Es wird nur dann eine Antwort aus dem Cache bereitgestellt, wenn die ursprüngliche Anforderung denselben Abonnementschlüssel aufweist. Legen Sie dieses Attribut auf TRUE fest, wenn jedem Benutzer eine andere Antwort für dieselbe URL angezeigt werden soll. Legen Sie das Attribut vary-by-developer-group auf TRUE fest, wenn jeder Benutzergruppe eine andere Antwort für dieselbe URL angezeigt werden soll.

Verwenden eines externen Caches

API Management-Instanzen verfügen in der Regel über einen internen Cache, der zum Speichern von vorbereiteten Antworten auf Anforderungen verwendet wird. Wenn Sie möchten, können Sie jedoch stattdessen einen Redis-kompatiblen externen Cache verwenden. Sie können beispielsweise den Azure Cache for Redis-Dienst als externes Cachesystem verwenden.

Mögliche Gründe für die Verwendung eines externen Caches:

  • Sie möchten vermeiden, dass der Inhalt des Caches gelöscht wird, wenn der API Management-Dienst aktualisiert wird.
  • Sie möchten mehr Kontrolle über die Cachekonfiguration als der interne Cache zulässt.
  • Sie möchten mehr Daten zwischenspeichern, als im internen Cache gespeichert werden können.

Ein weiterer Grund für das Konfigurieren eines externen Caches ist, dass Sie einen Cache mit dem Tarif „Consumption“ verwenden möchten. Dieser Tarif entspricht den Prinzipien des serverlosen Designs, und Sie sollten diesen mit serverlosen Web-APIs verwenden. Aus diesem Grund ist kein interner Cache enthalten. Wenn Sie im Tarif „Consumption“ einen Cache mit einer API Management-Instanz verwenden möchten, müssen Sie einen externen Cache verwenden.