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

  • Artykuł

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

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 trybu failover. Aby uzyskać szczegółowe informacje o automatycznym geodr, 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.

Zasób usługi Event Grid Obsługa trybu failover po stronie klienta Obsługa odzyskiwania po awarii geograficznej (GeoDR)
Tematy niestandardowe Obsługiwane Cross-Geo/Regional
Tematy systemowe Nieobsługiwane Włączone automatycznie
Domeny Obsługiwane Cross-Geo/Regional
Przestrzenie nazw partnerów Obsługiwane Nieobsługiwane
Przestrzenie nazw Obsługiwane Nieobsługiwane

Zagadnienia dotyczące trybu failover 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 tworzenia utraconych komunikatów, należy użyć tego samego regionu używanego w pomocniczym zasobie 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 platformy .NET, który próbuje najpierw opublikować w temacie podstawowym. Jeśli nie powiedzie się, przejdź do tematu pomocniczego w tryb failover. W obu przypadkach sprawdza również interfejs API kondycji drugiego tematu, wykonując żądanie GET dla https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health. Temat w dobrej kondycji na żądanie GET w punkcie końcowym /api/health powinien zawsze odpowiedzieć 200 OK.

Uwaga

Poniższy przykładowy kod jest przeznaczony tylko do celów demonstracyjnych i nie jest przeznaczony do użytku produkcyjnego.

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ć

Wszystkie składniki są już gotowe, możesz więc przetestować tę 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ędzie nadal przepływać za pośrednictwem usługi Event Grid, jednak gdy spojrzysz na klienta, zobaczysz, że są one teraz publikowane za pośrednictwem tematu pomocniczego.

Możliwe rozszerzenia

Istnieje wiele sposobów, w jakie można rozszerzyć ten przykład stosownie do potrzeb. W przypadku scenariuszy z dużą liczbą zdarzeń warto zaimplementować niezależne regularne sprawdzanie interfejsu API kondycji tematu. Dzięki temu w razie przestoju tematu nie trzeba sprawdzać go przy każdej pojedynczej publikacji. Po ustaleniu, że temat nie jest w dobrej kondycji, można przestawić domyślne publikowanie na temat pomocniczy.

Podobnie można zaimplementować logikę powrotu po awarii — w zależności od określonych potrzeb. Jeśli publikowanie w najbliższym centrum danych jest bardzo ważne ze względu na zmniejszenie opóźnień, można okresowo badać interfejs API kondycji tematu, dla którego włączono tryb failover. Po ponownym przejściu w dobrą kondycję można bezpiecznie wrócić po awarii do bliżej centrum danych.

Następne kroki