Implementacja trybu failover po stronie klienta w usłudze Azure Event Grid

Odzyskiwanie po awarii zwykle polega na utworzeniu zasobu kopii zapasowej, aby zapobiec zakłóceniom w funkcjonowaniu regionu. Podczas tego procesu będzie potrzebny podstawowy i pomocniczy region zasobów usługi Azure Event Grid w obciążeniu roboczym.

Istnieją różne sposoby odzyskiwania po poważnej utracie funkcjonalności aplikacji. W tym artykule opiszemy listę kontrolną, którą należy wykonać, aby przygotować klienta do odzyskania po awarii z powodu złej kondycji zasobu lub regionu.

Usługa Event Grid obsługuje ręczne i automatyczne odzyskiwanie po awarii geograficznej (GeoDR) po stronie serwera. Nadal można zaimplementować logikę odzyskiwania po awarii po stronie klienta, jeśli chcesz mieć większą kontrolę nad procesem przełączania awaryjnego. Aby uzyskać szczegółowe informacje na temat automatycznego odzyskiwania po awarii geograficznej, zobacz Odzyskiwanie po awarii geograficznej po stronie serwera w usłudze Azure Event Grid.

W poniższej tabeli przedstawiono obsługę trybu failover po stronie klienta i odzyskiwania po awarii geograficznej w usłudze Event Grid.

Zagrożenia związane z przełączaniem awaryjnym po stronie klienta

1. Utwórz i skonfiguruj podstawowy zasób usługi Event Grid.
2. Utwórz i skonfiguruj pomocniczy zasób usługi Event Grid.
3. Należy pamiętać, że oba zasoby muszą mieć taką samą konfigurację, zasoby podrzędne i możliwości, które są włączone.
4. Zasoby usługi Event Grid muszą być hostowane w różnych regionach.
5. Jeśli zasób usługi Event Grid ma zasoby zależne, takie jak zasób magazynu do nieodebranych komunikatów, należy użyć tego samego regionu co pomocniczy zasób usługi Event Grid.
6. Upewnij się, że punkty końcowe są regularnie testowane w celu zapewnienia gwarancji, że zasoby planu odzyskiwania są w miejscu i działają prawidłowo.

Podstawowy przykład implementacji trybu failover po stronie klienta dla tematów niestandardowych

Poniższy przykładowy kod to prosty wydawca dla platformy .NET, który próbuje najpierw opublikować w Twoim podstawowym temacie. Jeśli to się nie powiedzie, nastąpi przejście do tematu pomocniczego. W obu przypadkach sprawdza również api monitorowania zdrowia innego tematu, wykonując polecenie GET na https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health. Dobrze działający temat powinien zawsze zwracać 200 OK, kiedy wykonywane jest zapytanie GET na punkcie końcowym /api/health.

using System;
using System.Net.Http;
using System.Collections.Generic;
using System.Threading.Tasks;
using Azure;
using Azure.Messaging.EventGrid;

namespace EventGridFailoverPublisher
{
    // This captures the "Data" portion of an EventGridEvent on a custom topic
    class FailoverEventData
    {
        public string TestStatus { get; set; }
    }

    class Program
    {
        static async Task Main(string[] args)
        {
            // TODO: Enter the endpoint each topic. You can find this topic endpoint value
            // in the "Overview" section in the "Event Grid topics" page in Azure Portal..
            string primaryTopic = "https://<primary-topic-name>.<primary-topic-region>.eventgrid.azure.net/api/events";
            string secondaryTopic = "https://<secondary-topic-name>.<secondary-topic-region>.eventgrid.azure.net/api/events";

            // TODO: Enter topic key for each topic. You can find this in the "Access Keys" section in the
            // "Event Grid topics" page in Azure Portal.
            string primaryTopicKey = "<your-primary-topic-key>";
            string secondaryTopicKey = "<your-secondary-topic-key>";

            Uri primaryTopicUri = new Uri(primaryTopic);
            Uri secondaryTopicUri = new Uri(secondaryTopic);

            Uri primaryTopicHealthProbe = new Uri($"https://{primaryTopicUri.Host}/api/health");
            Uri secondaryTopicHealthProbe = new Uri($"https://{secondaryTopicUri.Host}/api/health");

            var httpClient = new HttpClient();

            try
            {
                var client = new EventGridPublisherClient(primaryTopicUri, new AzureKeyCredential(primaryTopicKey));

                await client.SendEventsAsync(GetEventsList());
                Console.Write("Published events to primary Event Grid topic.");

                HttpResponseMessage health = httpClient.GetAsync(secondaryTopicHealthProbe).Result;
                Console.Write("\n\nSecondary Topic health " + health);
            }
            catch (RequestFailedException ex)
            {
                var client = new EventGridPublisherClient(secondaryTopicUri, new AzureKeyCredential(secondaryTopicKey));

                await client.SendEventsAsync(GetEventsList());
                Console.Write("Published events to secondary Event Grid topic. Reason for primary topic failure:\n\n" + ex);

                HttpResponseMessage health = await httpClient.GetAsync(primaryTopicHealthProbe);
                Console.WriteLine($"Primary Topic health {health}");
            }

            Console.ReadLine();
        }

        static IList<EventGridEvent> GetEventsList()
        {
            List<EventGridEvent> eventsList = new List<EventGridEvent>();

            for (int i = 0; i < 5; i++)
            {
                eventsList.Add(new EventGridEvent(
                    subject: "test" + i,
                    eventType: "Contoso.Failover.Test",
                    dataVersion: "2.0",
                    data: new FailoverEventData
                    {
                        TestStatus = "success"
                    }));
            }

            return eventsList;
        }
    }
}

Czas to wypróbować

Teraz, gdy masz już wszystkie składniki, możesz przetestować implementację trybu failover.

Aby upewnić się, że tryb failover działa, możesz zmienić kilka znaków w kluczu podstawowego tematu, aby nie był już prawidłowy. Spróbuj ponownie uruchomić wydawcę. W przypadku poniższych przykładowych zdarzeń będą nadal przekazywane przez Event Grid, jednakże gdy spojrzysz na swojego klienta, zobaczysz, że są one teraz publikowane za pośrednictwem tematu pomocniczego.

Możliwe rozszerzenia

Istnieje wiele sposobów rozszerzania tego przykładu na podstawie Twoich potrzeb. W przypadku scenariuszy o dużym wolumenie danych warto regularnie sprawdzać interfejs API stanu tematu na własną rękę. W ten sposób, jeśli temat miał iść w dół, nie musisz sprawdzać go przy każdym publikowaniu. Gdy wiesz, że temat nie jest zdrowy, możesz domyślnie publikować w temacie drugorzędnym.

Podobnie możesz zaimplementować logikę odzyskiwania po awarii, dostosowaną do swoich indywidualnych potrzeb. Jeśli publikowanie w najbliższym centrum danych ma kluczowe znaczenie dla zmniejszenia opóźnienia, możesz okresowo sondować interfejs API kondycji tematu, który przeszedł w tryb failover. Po odzyskaniu stabilności można bezpiecznie przeprowadzić przywrócenie do bliższego centrum danych.

Dalsze kroki

• Dowiedz się, jak odbierać zdarzenia w punkcie końcowym http
• Dowiedz się, jak kierować zdarzenia do połączeń hybrydowych
• Dowiedz się więcej o odzyskiwaniu po awarii przy użyciu usług Azure DNS i Traffic Manager