Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące projektowania aplikacji usługi Azure Service Fabric

  • Artykuł

Ten artykuł zawiera wskazówki dotyczące tworzenia aplikacji i usług w usłudze Azure Service Fabric.

Zapoznaj się z usługą Service Fabric

Wskazówki dotyczące projektowania aplikacji

Zapoznaj się z ogólną architekturą aplikacji usługi Service Fabric i ich zagadnieniami dotyczącymi projektowania.

Wybieranie bramy interfejsu API

Użyj usługi bramy interfejsu API, która komunikuje się z usługami zaplecza, które następnie można skalować w poziomie. Najczęściej używane usługi bramy interfejsu API to:

Usługi bezstanowe

Zalecamy, aby zawsze zacząć od utworzenia usług bezstanowych przy użyciu usług Reliable Services i przechowywania stanu w bazie danych platformy Azure, usłudze Azure Cosmos DB lub usłudze Azure Storage. Stan zewnętrzny to bardziej znane podejście dla większości deweloperów. Takie podejście umożliwia również korzystanie z możliwości zapytań w sklepie.

Kiedy używać usług stanowych

Rozważ usługi stanowe, gdy masz scenariusz z małym opóźnieniem i musisz zachować dane blisko obliczeń. Niektóre przykładowe scenariusze obejmują urządzenia cyfrowej reprezentacji bliźniaczej IoT, stan gry, stan sesji, buforowanie danych z bazy danych oraz długotrwałe przepływy pracy do śledzenia wywołań do innych usług.

Zdecyduj o przedziale czasu przechowywania danych:

  • Dane buforowane. Użyj buforowania, gdy opóźnienie w magazynach zewnętrznych jest problemem. Użyj stanowej usługi jako własnej pamięci podręcznej danych lub rozważ użycie rozproszonej pamięci podręcznej usługi Service Fabric typu open source. W tym scenariuszu nie musisz się martwić, jeśli utracisz wszystkie dane w pamięci podręcznej.
  • Dane związane z czasem. W tym scenariuszu musisz przechowywać dane zbliżone do obliczeń przez pewien czas w celu opóźnienia, ale możesz sobie pozwolić na utratę danych w przypadku awarii. Na przykład w wielu rozwiązaniach IoT dane muszą być zbliżone do obliczeń, na przykład gdy jest obliczana średnia temperatura w ciągu ostatnich kilku dni, ale jeśli te dane zostaną utracone, określone zarejestrowane punkty danych nie są tak ważne. Ponadto w tym scenariuszu zwykle nie dbasz o tworzenie kopii zapasowych poszczególnych punktów danych. Kopię zapasową obliczanych wartości średnich, które są okresowo zapisywane w magazynie zewnętrznym.
  • Dane długoterminowe. Niezawodne kolekcje mogą trwale przechowywać dane. Jednak w takim przypadku należy przygotować się do odzyskiwania po awarii, w tym skonfigurować okresowe zasady tworzenia kopii zapasowych dla klastrów. W efekcie skonfigurujesz, co się stanie, jeśli klaster zostanie zniszczony w awarii, w którym trzeba utworzyć nowy klaster oraz jak wdrożyć nowe wystąpienia aplikacji i odzyskać dane z najnowszej kopii zapasowej.

Oszczędzaj koszty i poprawiaj dostępność:

  • Możesz obniżyć koszty, korzystając z usług stanowych, ponieważ nie ponosisz kosztów dostępu do danych i transakcji z magazynu zdalnego, a ponieważ nie musisz używać innej usługi, takiej jak Azure Cache for Redis.
  • Korzystanie z usług stanowych głównie w przypadku magazynu, a nie w przypadku obliczeń, jest kosztowne i nie zalecamy jej. Pomyśl o usługach stanowych jako obliczeniach przy użyciu taniego magazynu lokalnego.
  • Usuwając zależności od innych usług, możesz zwiększyć dostępność usługi. Zarządzanie stanem za pomocą wysokiej dostępności w klastrze izoluje cię od innych problemów z przestojami lub opóźnieniami usługi.

Jak pracować z usługami Reliable Services

Usługa Service Fabric Reliable Services umożliwia łatwe tworzenie usług bezstanowych i stanowych. Aby uzyskać więcej informacji, zobacz wprowadzenie do usług Reliable Services.

  • Zawsze należy przestrzegać tokenu anulowania w RunAsync() metodzie dla usług bezstanowych i stanowych oraz ChangeRole() metody dla usług stanowych. Jeśli tego nie zrobisz, usługa Service Fabric nie wie, czy twoja usługa może zostać zamknięta. Jeśli na przykład nie honorujesz tokenu anulowania, może wystąpić znacznie dłuższy czas uaktualniania aplikacji.
  • Otwieranie i zamykanie odbiorników komunikacji w odpowiednim czasie i honorowanie tokenów anulowania.
  • Nigdy nie mieszaj kodu synchronizacji za pomocą kodu asynchronicznego. Na przykład nie używaj .GetAwaiter().GetResult() w wywołaniach asynchronicznych. Użyj asynchronicznego całego stosu wywołań.

Jak pracować z elementami Reliable Actors

Usługa Service Fabric Reliable Actors umożliwia łatwe tworzenie stanowych, wirtualnych aktorów. Aby uzyskać więcej informacji, zobacz wprowadzenie do funkcji Reliable Actors.

  • Poważnie rozważ użycie komunikatów pub/sub między aktorami w celu skalowania aplikacji. Narzędzia, które zapewniają tę usługę, obejmują open source SoCreate Service Fabric Pub/Sub i Azure Service Bus.
  • Umożliw, aby aktor był tak szczegółowy, jak to możliwe.
  • Zarządzanie cyklem życia aktora. Usuń aktorów, jeśli nie zamierzasz ich ponownie używać. Usuwanie niepotrzebnych aktorów jest szczególnie ważne w przypadku korzystania z dostawcy stanu lotnego, ponieważ cały stan jest przechowywany w pamięci.
  • Ze względu na ich współbieżność opartą na kolei aktorzy najlepiej używać jako niezależnych obiektów. Nie twórz grafów wielu aktorów, synchronicznych wywołań metod (z których każdy najprawdopodobniej staje się oddzielnym wywołaniem sieciowym) ani nie tworzy żądań aktora cyklicznego. Będą one znacząco wpływać na wydajność i skalę.
  • Nie mieszaj kodu synchronizacji za pomocą kodu asynchronicznego. Spójnie używaj asynchronicznego, aby zapobiec problemom z wydajnością.
  • Nie uruchamiaj długotrwałych połączeń w aktorach. Długotrwałe wywołania blokują inne wywołania tego samego aktora ze względu na współbieżność opartą na kolei.
  • Jeśli komunikujesz się z innymi usługami przy użyciu komunikacji z usługą Service Fabric i tworzysz usługę , utwórz fabrykę ServiceProxyFactoryna poziomie usługi aktora, a nie na poziomie aktora.

Diagnostyka aplikacji

Szczegółowe informacje na temat dodawania rejestrowania aplikacji w wywołaniach usługi. Pomoże to zdiagnozować scenariusze, w których usługi siebie nazywają. Na przykład gdy A wywołuje funkcję B wywołuje wywołania C, wywołanie może zakończyć się niepowodzeniem w dowolnym miejscu. Jeśli nie masz wystarczającej ilości rejestrowania, błędy są trudne do zdiagnozowania. Jeśli usługi rejestrują zbyt wiele z powodu woluminów wywołań, pamiętaj, aby co najmniej rejestrować błędy i ostrzeżenia.

Wskazówki dotyczące projektowania na platformie Azure