Omówienie usług Reliable Services
Usługa Azure Service Fabric upraszcza pisanie usług bezstanowych i stanowych oraz zarządzanie nimi. W tym temacie omówiono:
- Model programowania usług Reliable Services dla usług bezstanowych i stanowych.
- Opcje, które należy dokonać podczas pisania usługi Reliable Service.
- Niektóre scenariusze i przykłady użycia usług Reliable Services i sposobu ich pisania.
Reliable Services to jeden z modeli programowania dostępnych w usłudze Service Fabric. Innym jest model programowania Reliable Actor, który zapewnia platformę aplikacji Virtual Actor na podstawie modelu Reliable Services. Aby uzyskać więcej informacji na temat elementów Reliable Actors, zobacz Wprowadzenie do usługi Service Fabric Reliable Actors.
Usługa Service Fabric zarządza okresem istnienia usług, od aprowizowania i wdrażania poprzez uaktualnianie i usuwanie za pośrednictwem zarządzania aplikacjami usługi Service Fabric.
Co to są usługi Reliable Services
Usługi Reliable Services udostępniają prosty, zaawansowany model programowania najwyższego poziomu, który ułatwia określenie, co jest ważne dla aplikacji. Model programowania usług Reliable Services zapewnia następujące elementy:
- Dostęp do interfejsów API usługi Service Fabric. W przeciwieństwie do usług Service Fabric modelowanych jako pliki wykonywalne gościa, usługi Reliable Services mogą używać bezpośrednio interfejsów API usługi Service Fabric. Dzięki temu usługi mogą:
- Wykonywanie zapytań względem systemu
- Raportowanie kondycji jednostek w klastrze
- Otrzymywanie powiadomień o zmianach konfiguracji i kodu
- Znajdowanie i komunikowanie się z innymi usługami,
- Korzystanie z niezawodnych kolekcji
- Uzyskaj dostęp do wielu innych funkcji— wszystkie z modelu programowania pierwszej klasy w kilku językach programowania.
- Prosty model do uruchamiania własnego kodu, który czuje się jak inne znane modele programowania. Kod ma dobrze zdefiniowany punkt wejścia i łatwo zarządzany cykl życia.
- Podłączany model komunikacji. Użyj wybranego transportu, takiego jak HTTP z internetowym interfejsem API, protokołami WebSocket, niestandardowymi protokołami TCP lub innymi elementami. Usługi Reliable Services oferują doskonałe gotowe opcje, których można użyć, lub możesz udostępnić własne.
- W przypadku usług stanowych model programowania usług Reliable Services umożliwia spójne i niezawodne przechowywanie stanu bezpośrednio w usłudze przy użyciu niezawodnych kolekcji. Kolekcje Reliable Collections to prosty zestaw klas kolekcji o wysokiej dostępności i niezawodności, które będą znane każdemu, kto używał kolekcji języka C#. Tradycyjnie usługi wymagały systemów zewnętrznych na potrzeby niezawodnego zarządzania stanem. Dzięki niezawodnym kolekcjom możesz przechowywać stan obok zasobów obliczeniowych z taką samą wysoką dostępnością i niezawodnością, której oczekujesz od magazynów zewnętrznych o wysokiej dostępności. Ten model zwiększa również opóźnienie, ponieważ współlokujesz zasoby obliczeniowe i stan, który musi działać.
Co sprawia, że usługi Reliable Services różnią się
Usługi Reliable Services różnią się od usług, które mogły zostać napisane wcześniej, ponieważ usługa Service Fabric udostępnia następujące elementy:
- Niezawodność — usługa pozostaje nawet w zawodnych środowiskach, w których maszyny kończą się niepowodzeniem lub napotykają problemy z siecią albo w przypadkach, w których same usługi napotykają błędy i awarie lub awarie. W przypadku usług stanowych stan jest zachowywany nawet w obecności sieci lub innych awarii.
- Dostępność — Twoja usługa jest osiągalna i elastyczna. Usługa Service Fabric utrzymuje żądaną liczbę uruchomionych kopii.
- Skalowalność — usługi są oddzielone od określonego sprzętu i mogą rosnąć lub zmniejszać w razie potrzeby przez dodanie lub usunięcie sprzętu lub innych zasobów. Usługi są łatwo partycjonowane (szczególnie w przypadku stanowym), aby upewnić się, że usługa może skalować i obsługiwać częściowe awarie. Usługi można tworzyć i usuwać dynamicznie za pomocą kodu, co umożliwia łączenie większej liczby wystąpień w razie potrzeby, na przykład w odpowiedzi na żądania klientów. Na koniec usługa Service Fabric zachęca usługi do bycia lekkimi. Usługa Service Fabric umożliwia aprowizację tysięcy usług w ramach jednego procesu, a nie wymaganie lub poświęcanie całych wystąpień lub procesów systemu operacyjnego do pojedynczego wystąpienia usługi.
- Spójność — wszelkie informacje przechowywane w usłudze Reliable Service mogą być spójne. Dotyczy to nawet wielu niezawodnych kolekcji w ramach usługi. Zmiany w kolekcjach w usłudze można wprowadzać w sposób niepodzielne transakcyjnie.
Cykl życia usługi
Niezależnie od tego, czy usługa jest stanowa, czy bezstanowa, usługa Reliable Services zapewnia prosty cykl życia, który pozwala szybko podłączyć kod i rozpocząć pracę. Wprowadzenie nowej usługi i jej uruchomienie wymaga zaimplementowania dwóch metod:
- CreateServiceReplicaListeners/CreateServiceInstanceListeners — ta metoda określa stosy komunikacji, których chce użyć. Stos komunikacji, taki jak internetowy interfejs API, definiuje punkt końcowy nasłuchiwania lub punkty końcowe dla usługi (jak klienci docierają do usługi). Definiuje również sposób interakcji komunikatów z pozostałą częścią kodu usługi.
- RunAsync — ta metoda polega na tym, że usługa uruchamia logikę biznesową i gdzie uruchamia wszystkie zadania w tle, które powinny być uruchamiane przez cały okres istnienia usługi. Podany token anulowania jest sygnałem, kiedy ta praca powinna zostać zatrzymana. Jeśli na przykład usługa musi ściągnąć komunikaty z niezawodnej kolejki i przetworzyć je, to właśnie tam odbywa się ta praca.
Jeśli po raz pierwszy zapoznasz się z niezawodnymi usługami, przeczytaj dalej! Jeśli szukasz szczegółowego przewodnika dotyczącego cyklu życia niezawodnych usług, zapoznaj się z omówieniem cyklu życia usług Reliable Services.
Przykładowe usługi
Przyjrzyjmy się bliżej, jak działa model usług Reliable Services zarówno z usługami bezstanowymi, jak i stanowymi.
Bezstanowe usługi Reliable Services
Usługa bezstanowa to usługa, w której nie ma stanu utrzymywanego w usłudze między wywołaniami. Każdy obecny stan jest całkowicie jednorazowy i nie wymaga synchronizacji, replikacji, trwałości ani wysokiej dostępności.
Rozważmy na przykład kalkulator, który nie ma pamięci i otrzymuje wszystkie terminy i operacje do wykonania jednocześnie.
W takim przypadku RunAsync() usługa (C#) lub runAsync() (Java) może być pusta, ponieważ nie ma przetwarzania zadań w tle, które musi wykonać usługa. Po utworzeniu usługi kalkulatora zwraca on ICommunicationListener (C#) lub CommunicationListener (Java) (na przykład internetowy interfejs API), który otwiera punkt końcowy nasłuchiwania na pewnym porcie. Ten punkt końcowy nasłuchiwania jest podłączany do różnych metod obliczeń (na przykład: "Add(n1, n2)") definiujących publiczny interfejs API kalkulatora.
Po wywołaniu z klienta wywoływana jest odpowiednia metoda, a usługa kalkulatora wykonuje operacje na podanych danych i zwraca wynik. Nie przechowuje żadnego stanu.
Brak przechowywania żadnego stanu wewnętrznego sprawia, że ten przykładowy kalkulator jest prosty. Ale większość usług nie jest naprawdę bezstanowa. Zamiast tego zewnętrznego stanu do innego sklepu. (Na przykład każda aplikacja internetowa, która opiera się na utrzymywaniu stanu sesji w magazynie zapasowym lub pamięci podręcznej, nie jest bezstanowa).
Typowym przykładem użycia usług bezstanowych w usłudze Service Fabric jest fronton, który uwidacznia publiczny interfejs API dla aplikacji internetowej. Następnie usługa frontonu komunikuje się z usługami stanowymi w celu ukończenia żądania użytkownika. W takim przypadku wywołania od klientów są kierowane do znanego portu, takiego jak 80, gdzie nasłuchuje usługa bezstanowa. Ta usługa bezstanowa odbiera wywołanie i określa, czy wywołanie pochodzi od zaufanej firmy i do której usługi jest przeznaczona. Następnie usługa bezstanowa przekazuje wywołanie poprawnej partycji usługi stanowej i czeka na odpowiedź. Gdy usługa bezstanowa otrzyma odpowiedź, odpowiada na oryginalnego klienta. Przykładem takiej usługi jest przykład Wprowadzenie do usługi Service Fabric (C# / Java) między innymi przykładami usługi Service Fabric w tym repozytorium.
Stateful Reliable Services
Usługa stanowa jest usługą, która musi mieć pewną część stanu spójną i obecną, aby usługa działała. Rozważ usługę, która stale oblicza średnią kroczącą niektórych wartości na podstawie otrzymywanych aktualizacji. Aby to zrobić, musi mieć bieżący zestaw żądań przychodzących, które musi przetworzyć i bieżącą średnią. Każda usługa, która pobiera, przetwarza i przechowuje informacje w magazynie zewnętrznym (takim jak obecnie magazyn obiektów blob lub tabel platformy Azure) jest stanowa. Po prostu utrzymuje swój stan w magazynie stanów zewnętrznych.
Większość usług przechowuje obecnie stan zewnętrznie, ponieważ magazyn zewnętrzny zapewnia niezawodność, dostępność, skalowalność i spójność tego stanu. W usłudze Service Fabric usługi nie są wymagane do przechowywania ich stanu zewnętrznego. Usługa Service Fabric zajmuje się tymi wymaganiami zarówno dla kodu usługi, jak i stanu usługi.
Załóżmy, że chcemy napisać usługę przetwarzającą obrazy. W tym celu usługa przyjmuje obraz i serię konwersji do wykonania na tym obrazie. Ta usługa zwraca odbiornik komunikacji (załóżmy, że jest to interfejs WebAPI), który uwidacznia interfejs API, taki jak ConvertImage(Image i, IList<Conversion> conversions). Po odebraniu żądania usługa przechowuje je w IReliableQueueobiekcie i zwraca do klienta identyfikator, aby mógł śledzić żądanie.
W tej usłudze RunAsync() może być bardziej złożona. Usługa ma pętlę wewnątrz niej RunAsync() , która ściąga żądania z IReliableQueue i wykonuje żądane konwersje. Wyniki są przechowywane w elemecie IReliableDictionary , aby po powrocie klienta mogli pobrać przekonwertowane obrazy. Aby upewnić się, że nawet jeśli coś nie powiedzie się, obraz nie zostanie utracony, ta usługa Reliable Service wycofa się z kolejki, wykona konwersje i zapisze wynik w jednej transakcji. W takim przypadku komunikat jest usuwany z kolejki, a wyniki są przechowywane w słowniku wyników tylko po zakończeniu konwersji. Alternatywnie usługa może ściągnąć obraz z kolejki i natychmiast zapisać go w magazynie zdalnym. Zmniejsza to ilość stanu, jakim usługa musi zarządzać, ale zwiększa złożoność, ponieważ usługa musi zachować niezbędne metadane do zarządzania magazynem zdalnym. W przypadku obu metod, jeśli coś nie powiodło się w środku, żądanie pozostanie w kolejce oczekujące na przetworzenie.
Chociaż ta usługa brzmi jak typowa usługa .NET, różnica polega na tym, że używane struktury danych (IReliableQueue i IReliableDictionary) są dostarczane przez usługę Service Fabric i są wysoce niezawodne, dostępne i spójne.
Kiedy używać interfejsów API usług Reliable Services
Rozważ użycie interfejsów API usług Reliable Services, jeśli:
- Chcesz, aby kod usługi (i opcjonalnie stan) był wysoce dostępny i niezawodny.
- Potrzebujesz gwarancji transakcyjnych w wielu jednostkach stanu (na przykład zamówienia i elementy wiersza zamówienia).
- Stan aplikacji może być naturalnie modelowany jako niezawodne słowniki i kolejki.
- Kod lub stan aplikacji musi być wysoce dostępny z odczytami i zapisami o małych opóźnieniach.
- Aplikacja musi kontrolować współbieżność lub stopień szczegółowości operacji transakcyjnych w co najmniej jednej kolekcji Reliable Collection.
- Chcesz zarządzać komunikacją lub kontrolować schemat partycjonowania usługi.
- Kod wymaga środowiska uruchomieniowego bez wątków.
- Aplikacja musi dynamicznie tworzyć lub niszczyć niezawodne słowniki, kolejki lub całe usługi w czasie wykonywania.
- Należy programowo kontrolować funkcje tworzenia i przywracania kopii zapasowej udostępnianej przez usługę Service Fabric dla stanu usługi.
- Aplikacja musi zachować historię zmian dla swoich jednostek stanu.
- Chcesz opracowywać lub korzystać z niestandardowych dostawców stanu opracowanych przez inne firmy.