Obsługa gRPC w Azure Front Door (wersja zapoznawcza)

Dotyczy: ✔️ Front Door Standard ✔️ Front Door Premium

W tym artykule dowiesz się, jak konfigurować i testować natywne usługi gRPC za pomocą Azure Front Door Standard i Premium. Możesz kierować wywołania na podstawie usługi i metody, rozkładać ruch pomiędzy sprawnymi źródłami oraz stosować obsługiwane mechanizmy sterowania metadanymi żądań.

Publiczna wersja zapoznawcza jest dostępna dla wszystkich klientów Azure Front Door Standard i Premium. Nie musisz rejestrować się w podglądzie ani spełniać dodatkowych wymagań dotyczących dostępu do podglądu.

Co to jest gRPC?

gRPC to otwartoźródłowy framework zdalnych wywołań procedur. Klient wywołuje metodę na zdalnej usłudze poprzez zdefiniowaną umowę usługową. Natywne gRPC używa HTTP/2 i powszechnie korzysta z Protocol Buffers do serializacji wiadomości.

gRPC zapewnia następujące korzyści:

• Efektywny transport poprzez ramowanie binarne HTTP/2, kompresję nagłówków i multipleksowanie połączeń.
• Silnie typowane kontrakty usług oraz generowany kod klienta i serwera w obsługiwanych językach.
• Połączenia unarne, streaming klienta, streaming serwera oraz dwukierunkowy streaming, z obsługą limitów czasu, anulowania, metadanych i kodów statusu.

Więcej informacji można znaleźć w artykule o podstawowych koncepcjach, architekturze i cyklu życia gRPC.

Protocol Buffers i ścieżki metod

Protocol Buffers zapewniają neutralną językowo i platformowo neutralną serializację danych strukturalnych. Plik .proto definiuje wiadomości, usługi i metody RPC. Kompilator Protocol Buffers, protoc, generuje odpowiedni kod.

Poniższy greet.proto przykład definiuje metodę unarną SayHello :

syntax = "proto3";

package greet;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

W pełni określona ścieżka żądania to /greet.Greeter/SayHello. Użyj tej ścieżki, aby dopasować metodę w trasie Azure Front Door.

Jak gRPC działa z Azure Front Door

Połączenie TLS klienta jest terminowane na krawędzi Azure Front Door. Front Door dopasowuje trasę gRPC, ocenia wspierane polityki względem metadanych żądań HTTP/2, wybiera sprawny serwer źródłowy i przekazuje wywołanie przez osobne połączenie HTTPS i HTTP/2. Wiadomości odpowiedzi i trailery gRPC wracają do klienta.

Następujące zachowanie dotyczy tras z włączonym gRPC w wersji zapoznawczej:

Prerequisites

• Profil usługi Azure Front Door w warstwie Standardowa lub Premium. Aby go utworzyć, zobacz Tworzenie profilu usługi Azure Front Door.
• Źródło gRPC akceptujące TLS i HTTP/2 na skonfigurowanym porcie źródła HTTPS. Każde źródło w grupie źródeł trasy musi być włączone dla gRPC.

Konfiguruj źródła i sondy kondycji

Skonfiguruj grupę origin przed dołączeniem jej do ścieżki gRPC:

1. W portalu Azure otwórz swój profil Front Door.
2. W obszarze Ustawienia wybierz Grupy origin i dodaj lub edytuj grupę origin dla swojej usługi gRPC.
3. Dodaj lub edytuj każde źródło. Włącz gRPC dla każdego źródła i skonfiguruj jego port HTTPS tak, aby był zgodny z usługą gRPC. Nie włączaj funkcji Private Link dla tych źródeł w wersji zapoznawczej.
4. Konfiguruj sondy zdrowotne, korzystając z poniższej tabeli.
5. Zapisz grupę początkową.

Natywna sonda gRPC wymaga standardowej usługi kondycji gRPC, a nie tylko aplikacyjnego RPC, takiego jak SayHello. Więcej informacji można znaleźć w sekcji gRPC health checking. W przypadku sond HTTP i HTTPS zobacz Azure Front Door health probes.

Zrzut ekranu pokazuje przykładowe ustawienia sondy i równoważenia obciążenia. Wybierz wartości spełniające wymagania Twojej aplikacji.

Konfiguruj trasę gRPC

Utwórz lub zaktualizuj trasę, aby wysyłać wywołania gRPC do grupy źródłowej:

1. W profilu Front Door, w ustawieniach, wybierz Front Door manager.
2. Wybierz endpoint, a następnie dodaj lub edytuj trasę routingu.
3. Wybierz domenę i grupę źródeł, która zawiera Twoje źródła z włączonym gRPC.
4. Włącz opcję włączenia gRPC.
5. Skonfiguruj trasę, korzystając z poniższej tabeli.
6. Zachowaj trasę.

Zrzut ekranu pokazuje przykładową trasę. Użyj własnej domeny, grupy origin i ścieżki metody RPC.

Zestawy reguł i Edge Actions są obsługiwane na trasach obsługujących gRPC. Jeśli zestaw reguł konfiguruje protokół przekazywania na HTTP, usługa Azure Front Door zwraca klientowi gRPC odpowiedź 301 HTTP. Ta odpowiedź nie obsługuje przekierowań dla ruchu gRPC. Utrzymuj skonfigurowane dla protokołu HTTPS trasy i przesyłanie dalej zestawów reguł.

Jeśli konfigurujesz trasę przez infrastrukturę jako kod, wyraźnie użyj kompatybilnych ustawień HTTPS i gRPC. Niekompatybilne kombinacje protokołów HTTP są odrzucane.

Testowanie za pomocą grpcurl

Aby uruchomić poniższe przykłady testowe, zainstaluj grpcurl. Nie potrzebujesz tego narzędzia do konfiguracji wsparcia gRPC w Azure Front Door.

Użyj pliku lub skompilowanego deskryptora wdrożonej usługi .proto , aby przetestować trasę specyficzną dla metody bez polegania na odbiciu serwera. Reflection serwera to opcjonalna alternatywa. Poniższe przykłady wykorzystują pokazaną wcześniej umowę greet.Greeter.

Zamień contoso.azurefd.net na swój endpoint Front Door lub domenę niestandardową. Użyj domeny, która odpowiada certyfikatowi TLS punktu końcowego. Wszystkie przykłady łączą się przez TLS na porcie 443; nie dodawaj -plaintext.

Przetestuj trasę specyficzną dla metody za pomocą lokalnego pliku proto

Zapisz definicję usługi jako greet.proto w swoim aktualnym katalogu. Dla trasy odpowiadającej /greet.Greeter/SayHello, wykonaj:

grpcurl -import-path "." -proto "greet.proto" -d "{}" contoso.azurefd.net:443 greet.Greeter/SayHello

Podanie lokalnego proto pozwala grpcurl wywołać metodę aplikacji bez wstępnego wywołania mechanizmu refleksji. Możesz też dostarczyć skompilowany deskryptor grpcurl zamiast pliku proto.

Przetestuj celowo szeroką ścieżkę z odzwierciedleniem serwera

Refleksja serwera jest opcjonalna. Jeśli nie dostarczysz lokalnego prototypu lub deskryptora, grpcurl używa refleksji serwera, aby odnaleźć kontrakt usługi. Origin musi implementować refleksję, a trasa Front Door musi odpowiadać jego ścieżce RPC.

Na przykład RPC odbicia grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo korzysta ze ścieżki żądania /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo. Ścieżka ograniczona do /greet.Greeter/SayHello nie odpowiada tej ścieżce. Test może zakończyć się niepowodzeniem przed wywołaniem RPC aplikacji, nawet jeśli trasa aplikacji jest poprawna.

Jeśli celowo konfigurowałeś /* szeroką trasę i włączyłeś odbijanie dla origin, wymień usługi:

grpcurl contoso.azurefd.net:443 list

Następnie wywołaj metodę, używając kontraktu refleksyjnego:

grpcurl -d "{}" contoso.azurefd.net:443 greet.Greeter/SayHello

Rozwiązywanie problemów z testami grpcurl

Zagadnienia dotyczące usługi Web Application Firewall

Azure Front Door WAF może oceniać metadane obsługiwanych żądań HTTP/2, takie jak identyfikator URI, nagłówki, adres IP klienta oraz lokalizacja geograficzna. Obsługiwane scenariusze ograniczania szybkości oparte na metadanych mogą również mieć zastosowanie.

Front Door nie dekoduje wiadomości protobuf. Reguły WAF zależne od inspekcji ciała wiadomości gRPC nie zapewniają inspekcji ładunku protobuf. Weryfikuj wiadomości w aplikacji gRPC lub innym komponentie, który rozumie schemat protobuf. Nie traktuj sprawdzania metadanych jako ochrony na poziomie wiadomości.

Aby uzyskać więcej informacji, zobacz Web Application Firewall w witrynie Azure Front Door.

Monitorowanie ruchu gRPC

Konfiguruj logi diagnostyczne i koreluj logi dostępu Front Door z logami aplikacji gRPC po stronie źródła. Sprawdź zarówno status HTTP, jak i status gRPC zwrócony w nagłówkach końcowych. Odpowiedź HTTP 200 może nadal zawierać status aplikacji gRPC nie-OK.

Jeśli wysyłasz logi dostępu do tabeli AzureDiagnostics w przestrzeni roboczej Log Analytics, użyj następującego zapytania, aby sprawdzić metadane HTTP dla przykładowej usługi:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.CDN"
    and Category == "FrontDoorAccessLog"
| where TimeGenerated > ago(1d)
| where requestUri_s contains "/greet.Greeter/"
| project TimeGenerated, ResourceId, requestUri_s,
          httpVersion_s, httpStatusCode_s

Zamień /greet.Greeter/ na ścieżkę swojej usługi. Zapytanie pokazuje URI żądań, wersje HTTP i kody statusu HTTP, a nie status gRPC w zwiastunach odpowiedzi. Używaj logów gRPC po stronie źródła do analizowania stanu aplikacji i korelowania awarii z logami dostępu usługi Front Door.

Treści powiązane

• Azure Front Door route matching
• Skonfiguruj źródła
• Omówienie architektury routingu
• Monitorowanie usługi Azure Front Door