Имитация отработки отказа с помощью Azure API Management - PullRequest
Новая
       6

Имитация отработки отказа с помощью Azure API Management

0 голосов
/ 17 декабря 2018

Azure API Management поддерживает мультирегиональное развертывание, что отлично подходит для высокой доступности наших API и внутренних служб.Мы находимся в процессе тестирования нашего мультирегионального развертывания, используя это, но как мы можем это проверить?Как мы можем смоделировать или вручную инициировать аварийное переключение при управлении API?

Заранее спасибо

Ответы [ 2 ]

0 голосов
/ 18 декабря 2018

APIM премиум-класса обеспечивают мультирегиональные возможности.Это гарантирует, что узел APIM находится ближе к возможному клиенту, и, кроме того, в случае сбоя одного из регионов трафик будет перенаправлен в другие регионы.Но это гарантируется только между клиентом и узлом APIM, такие гарантии не предоставляются для бэкэнд-связи APIM <->, так как со стороны APIM нет способа вывести вашу бэкэнд-инфраструктуру.Таким образом, для этого требуется некоторая конфигурация.

Вы можете использовать Traffic Manager перед вашим бэкендом для объединения нескольких конечных точек бэкэнда в одну и полагаться на зонды работоспособности для маршрутизации трафика (так же, как APIM делает для своих собственных региональных конечных точек).

В качестве альтернативы вы можете обрабатывать несколько конечных точек бэкэнда в политиках APIM, переключая трафик между ними при некоторых условиях.Вот несколько простых реализаций этого: 

<policies>
    <inbound>
        <base />
    </inbound>
    <backend>
        <retry condition="@(context.Response.StatusCode >= 500)" count="1" interval="0" first-fast-retry="true">
            <choose>
                <when condition="@(context.Response.StatusCode >= 500)">
                    <set-backend-service base-url="https://my-second-endpoint" />
                </when>
            </choose>

            <forward-request />
        </retry>
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Теперь это довольно неэффективно, так как он всегда делает первый вызов конечной точке по умолчанию, ждет 500 и делает второй вызов альтернативной.Вы можете улучшить это, используя политики кэширования для хранения активной конечной точки и переключаясь при обнаружении 500.

Или вы можете использовать статическую конфигурацию и полагаться на внешние датчики работоспособности и автоматизацию для обновления политик APIM в случае инцидента.

0 голосов
/ 17 декабря 2018

Вы можете попытаться установить свой код состояния как 302, и, когда он будет соответствовать коду статуса, он будет использовать соответствующий бэкэнд-сервис.Вот пример кода:

<when condition="condition="@(context.Response != null && (context.Response.StatusCode==302))">

Для получения более подробной информации вы можете обратиться к этой статье и этой одной .

...