|
|
Opublikowano 15.03.2018 10:03:44
|
|
|
|
W poprzedniej sekcji rozmawialiśmy o dwóch najniższych koncepcjach Service Fabric: jednym jest typ węzła i węzeł na poziomie sprzętowym. Drugim jest zastosowanie.
Typ węzła to zbiór węzłów, które są koncepcyjnymi abstrakcjami wdrażanych maszyn. W Service Fabric węzeł może być maszyną fizyczną, maszyną wirtualną lub nawet najpopularniejszym obecnie kontenerem.
Na typie węzła działa aplikacja (Application). Jest to abstrakcyjne rozumienie na poziomie oprogramowania systemowego. W aplikacji jest wiele mikroserwisów. Nawet wszystkie podstawowe usługi Service Fabric, takie jak FailoverManager Service i Naming Service, są mikrousługami.
Wszystkie rozproszone funkcje Service Fabric odpowiadają wdrożeniom Micro Service. Możemy dynamicznie dostosowywać liczbę instancji, ile mikro usługa musi uruchomić na ilu węzłach, aby rozłożyć obciążenie lub wykonać kopie zapasowe po awarii. Każda instancja nasłuchuje innego portu, a warstwa równoważenia obciążenia rozdziela żądania do różnych instancji.
Rzeczywisty scenariusz
Usługa stanowa jest jedną z mikro usług.
Zanim zaczniemy wprowadzać usługi państwowe, rozważmy następujące typowe scenariusze biznesowe.
Myślisz o wdrożeniu funkcji koszyka na swojej stronie internetowej. Po zalogowaniu użytkownicy umieszczają niektóre produkty w swoim koszyku zakupowym.
Przy następnym zalogowaniu użytkownik strona recepcji wywoła usługę obsługi koszyków i będzie musiała ponownie odczytać zapisane dane koszyka z tej usługi i wyświetlić je.
Jeśli tak, to jak byś to osiągnął?
Jeśli liczba użytkowników nie jest szczególnie duża, dodajemy tabelę koszyków do bazy i przypisujemy ją do tabeli użytkowników. Tabela kartridżów będzie miała pole ID użytkownika i zapisała dużą ilość danych z koszyka użytkownika.
To może przynieść kolejne problemy.
Jeśli liczba użytkowników będzie nadal rosła, wydajność tabel baz danych będzie się pogarszać.
Dane z tabel baz danych muszą być regularnie kopiowane na wypadek utraty danych
Jeśli występuje problem z wydajnością bazy danych, tabela musi zostać obalona lub nawet podzielona na particje
Sam system koszyków musi obsługiwać wszelkie zmiany w bazie danych, a nawet może wymagać zbalansowania obciążenia
Źródłem tego problemu jest to, że sam system nie jest zaprojektowany do skalowalności od samego początku. Ponadto bazy danych stanowią potencjalne wąskie gardło i zagrożenie dla wydajności.
Służba państwowa
Przyjrzyjmy się zupełnie nowej architekturze.
Od początku system koszyków zakupowych składa się z 36 podserwisów obsługujących wszystkie żądania (36, ponieważ inicjały identyfikatora użytkownika to 0-9 a-z, łącznie 36).
Żądanie użytkownika jest przetwarzane zgodnie z początkowym skrótem ID użytkownika do konkretnej podusługi.
Podusługa przechowuje dane z koszyka zakupowego wewnętrznie w lekkiej bazie danych i utrzymuje je na swoim urządzeniu pamięciowym.
Każda podusługa posiada również 3 kopie zapasowe, które stale synchronizują przechowywane dane, a te kopie są zawsze uruchamiane na różnych węzłach.
Jednocześnie tylko jedna kopia zapasowa odpowiada za przetwarzanie żądań jako stan aktywacji, a gdy pojawia się problem z aktywacją kopii zapasowej, pozostałe dwie kopie zapasowe aktywują jedną według algorytmu harmonogramowania.
Podsystem odzyskiwania po awarii tworzy nową kopię zapasową, aby zapewnić, że podusługa zawsze ma 3 zdrowe kopie zapasowe.
Serwis stanowy jest jednym z takich rozwiązań.
Wracając do powyższego scenariusza, system koszyków zakupowych to usługa stanowa.
36 podsystemów to 36 instancji tej usługi stanowej, którą nazywamy partycjami.
Kopia zapasowa w każdym podsystemie to Replica, a w partycji znajdują się 3 repliki.
Obecnie aktywną kopią zapasową jest Active Replica, a dwie nieaktywne zapasowe rezerwowe to Secondary Replica.
Każda replika tego samego Partiionu musi działać na innym węźle.
Kod usługi stanowej wykorzystuje <T>interfejsy takie jak IReliableCollection, IReliableDictionary< T1 oraz T2 >do zapisywania danych i synchronizacji wewnętrznej.
Ponadto Serwis Stanowy może implementować następujące funkcje:
Wszystkie powyższe liczby można zresetować, a w systemie wózków można mieć setki partycji, które obciążają więcej obciążeń. Możesz nawet mieć 5 lub więcej replik na partycję, aby zapewnić większą odporność.
Systemy zewnętrzne nie przejmują się liczbą partycji w usłudze stanowej, są one wywoływane za pomocą klucza partycji. Klucz partycji i odpowiadająca mu partycja są rozwiązywane przez mikro usługę Service Fabric. Na przykład w twojej firmie możesz mieć kilka milionów użytkowników, ale ustawić tylko 5 partycji. Podczas wywoływania usługi stanowej w koszyku zakupowym, system zewnętrzny musi jedynie podać identyfikator użytkownika (klucz partycji) oraz zapisane dane. To żądanie jest automatycznie mapowane na jedną z pięciu partycji na podstawie identyfikatora użytkownika i algorytmu skrótu.
Operacje danych w usługach stanowych wspierają transakcje. Żeby można było cofnąć ryzyko niepowodzenia
Mam nadzieję, że powyższe wprowadzenie pomoże Ci lepiej zrozumieć służbę państwową.
W kolejnych sekcjach omówimy przykłady kodów dla usługi stanowej. |
Poprzedni:Mam nadzieję, że uda wam się o tym porozmawiaćNastępny:Czterdzieści siedem sposobów optymalizacji programu C#
|
