Udostępnij za pośrednictwem

Service Fabric application lifecycle (Cykl życia aplikacji usługi Service Fabric)

  • Artykuł

Podobnie jak w przypadku innych platform, aplikacja w usłudze Azure Service Fabric zwykle przechodzi następujące fazy: projektowanie, programowanie, testowanie, wdrażanie, uaktualnianie, konserwacja i usuwanie. Usługa Service Fabric zapewnia najwyższej klasy obsługę pełnego cyklu życia aplikacji w chmurze, od programowania przez wdrażanie, codzienne zarządzanie i konserwację po ostateczne zlikwidowanie. Model usługi umożliwia niezależnie uczestniczyć w cyklu życia aplikacji w kilku różnych rolach. Ten artykuł zawiera omówienie interfejsów API i sposobu ich użycia przez różne role w różnych fazach cyklu życia aplikacji usługi Service Fabric.

Sprawdź tę stronę, aby zapoznać się z filmem wideo szkoleniowym opisujący sposób zarządzania cyklem życia aplikacji:

Ważne

Istnieją dwa narzędzia interfejsu wiersza polecenia używane do interakcji z usługą Service Fabric. Interfejs wiersza polecenia platformy Azure służy do zarządzania zasobami platformy Azure, takimi jak klaster usługi Service Fabric hostowany na platformie Azure. Interfejs wiersza polecenia usługi Service Fabric jest używany do bezpośredniego łączenia z klastrem usługi Service Fabric (niezależnie od tego, gdzie jest hostowany) oraz do zarządzania klastrem, aplikacjami i usługami.

Role modelu usługi

Role modelu usługi to:

  • Deweloper usługi: opracowuje usługi modułowe i ogólne, które mogą być zmieniane i używane w wielu aplikacjach tego samego typu lub różnych typów. Na przykład usługa kolejki może służyć do tworzenia aplikacji do obsługi biletów (pomocy technicznej) lub aplikacji do handlu elektronicznego (koszyka).
  • Deweloper aplikacji: tworzy aplikacje przez zintegrowanie kolekcji usług w celu spełnienia określonych wymagań lub scenariuszy. Na przykład witryna internetowa handlu elektronicznego może zintegrować usługę frontonu bezstanowego w formacie JSON," "Auction Stateful Service" i "Queue Stateful Service" w celu utworzenia rozwiązania aukcji.
  • Administrator aplikacji: podejmuje decyzje dotyczące konfiguracji aplikacji (wypełnianie parametrów szablonu konfiguracji), wdrażanie (mapowanie dostępnych zasobów) i jakość usługi. Na przykład administrator aplikacji decyduje o ustawieniach regionalnych języka (angielski dla Stany Zjednoczone lub japońskiego dla Japonii), na przykład). Inna wdrożona aplikacja może mieć różne ustawienia.
  • Operator: wdraża aplikacje na podstawie konfiguracji aplikacji i wymagań określonych przez administratora aplikacji. Na przykład operator aprowizuje i wdraża aplikację oraz zapewnia, że działa na platformie Azure. Operatorzy monitorują informacje o kondycji i wydajności aplikacji oraz utrzymują infrastrukturę fizyczną zgodnie z potrzebami.

Programowanie

  1. Deweloper usługi opracowuje różne typy usług przy użyciu modelu programowania Reliable Actors lub Reliable Services.
  2. Deweloper usługi deklaratywnie opisuje opracowane typy usług w pliku manifestu usługi składającym się z co najmniej jednego kodu, konfiguracji i pakietów danych.
  3. Następnie deweloper aplikacji tworzy aplikację przy użyciu różnych typów usług.
  4. Deweloper aplikacji deklaratywnie opisuje typ aplikacji w manifeście aplikacji, odwołując się do manifestów usługi usług składowych i odpowiednio przesłaniając i parametryzując różne ustawienia konfiguracji i wdrażania usług składowych.

Aby zapoznać się z przykładami, zobacz Rozpoczynanie pracy z usługami Reliable Actors i Wprowadzenie do usług Reliable Services .

Wdróż

  1. Administrator aplikacji dostosowuje typ aplikacji do określonej aplikacji, która ma zostać wdrożona w klastrze usługi Service Fabric, określając odpowiednie parametry elementu ApplicationType w manifeście aplikacji.
  2. Operator przekazuje pakiet aplikacji do magazynu obrazów klastra przy użyciu metody CopyApplicationPackage lub polecenia cmdlet Copy-ServiceFabricApplicationPackage. Pakiet aplikacji zawiera manifest aplikacji i kolekcję pakietów usług. Usługa Service Fabric wdraża aplikacje z pakietu aplikacji przechowywanego w magazynie obrazów, który może być magazynem obiektów blob platformy Azure lub usługą systemową usługi Service Fabric.
  3. Następnie operator aprowizuje typ aplikacji w klastrze docelowym z przekazanego pakietu aplikacji przy użyciu metody ProvisionApplicationAsync, polecenia cmdlet Register-ServiceFabricApplicationType lub aprowizacji operacji REST aplikacji.
  4. Po aprowizacji aplikacji operator uruchamia aplikację z parametrami dostarczonymi przez administratora aplikacji przy użyciu metody CreateApplicationAsync, polecenia cmdlet New-ServiceFabricApplication lub operacji REST tworzenia aplikacji.
  5. Po wdrożeniu aplikacji operator używa metody CreateServiceAsync, polecenia cmdlet New-ServiceFabricService lub operacji REST Tworzenia usługi w celu utworzenia nowych wystąpień usługi dla aplikacji na podstawie dostępnych typów usług.
  6. Aplikacja jest teraz uruchomiona w klastrze usługi Service Fabric.

Zobacz Wdrażanie aplikacji , aby zapoznać się z przykładami.

Test

  1. Po wdrożeniu w lokalnym klastrze programistycznym lub klastrze testowym deweloper usługi uruchamia wbudowany scenariusz testu trybu failover przy użyciu klas FailoverTestScenarioParameters i FailoverTestScenario lub Invoke-ServiceFabricFailoverTestScenario. Scenariusz testu trybu failover uruchamia określoną usługę przez ważne przejścia i przejścia w tryb failover, aby upewnić się, że jest ona nadal dostępna i działa.
  2. Następnie deweloper usługi uruchamia wbudowany scenariusz testowania chaosu przy użyciu klas ChaosTestScenarioParameters i ChaosTestScenario lub Invoke-ServiceFabricChaosTestScenario. Scenariusz testu chaosu losowo wywołuje wiele błędów węzła, pakietu kodu i repliki do klastra.
  3. Deweloper usługi testuje komunikację między usługami, tworząc scenariusze testowe, które przenoszą repliki podstawowe wokół klastra.

Aby uzyskać więcej informacji, zobacz Wprowadzenie do usługi Analizy błędów.

Uaktualnienie

  1. Deweloper usługi aktualizuje usługi składowe utworzonej aplikacji i/lub naprawia błędy i udostępnia nową wersję manifestu usługi.
  2. Deweloper aplikacji zastępuje i parametryzuje ustawienia konfiguracji i wdrażania spójnych usług oraz udostępnia nową wersję manifestu aplikacji. Następnie deweloper aplikacji dołącza nowe wersje manifestów usługi do aplikacji i udostępnia nową wersję typu aplikacji w zaktualizowanym pakiecie aplikacji.
  3. Administrator aplikacji dołącza nową wersję typu aplikacji do aplikacji docelowej, aktualizując odpowiednie parametry.
  4. Operator przekazuje zaktualizowany pakiet aplikacji do magazynu obrazów klastra przy użyciu metody CopyApplicationPackage lub polecenia cmdlet Copy-ServiceFabricApplicationPackage. Pakiet aplikacji zawiera manifest aplikacji i kolekcję pakietów usług.
  5. Operator aprowizuje nową wersję aplikacji w klastrze docelowym przy użyciu metody ProvisionApplicationAsync, polecenia cmdlet Register-ServiceFabricApplicationType lub aprowizacji operacji REST aplikacji.
  6. Operator uaktualnia aplikację docelową do nowej wersji przy użyciu metody UpgradeApplicationAsync, start-ServiceFabricApplicationUpgrade lub uaktualnij operację REST aplikacji.
  7. Operator sprawdza postęp uaktualniania przy użyciu metody GetApplicationUpgradeProgressAsync, polecenia cmdlet Get-ServiceFabricApplicationUpgrade lub operacji REST Pobierania postępu uaktualniania aplikacji.
  8. W razie potrzeby operator modyfikuje i ponownie uzyskuje parametry bieżącego uaktualnienia aplikacji przy użyciu metody UpdateApplicationUpgradeAsync, polecenia cmdlet Update-ServiceFabricApplicationUpgrade lub operacji REST uaktualniania aplikacji aktualizacji.
  9. W razie potrzeby operator wycofa bieżące uaktualnienie aplikacji przy użyciu metody RollbackApplicationUpgradeAsync, polecenia cmdlet Start-ServiceFabricApplicationRollback lub operacji REST wycofywania uaktualnienia aplikacji.
  10. Usługa Service Fabric uaktualnia docelową aplikację działającą w klastrze bez utraty dostępności któregokolwiek z jej usług składowych.

Zapoznaj się z samouczkiem dotyczącym uaktualniania aplikacji, aby zapoznać się z przykładami.

Obsługa

  1. W przypadku uaktualnień i poprawek systemu operacyjnego interfejsy usługi Service Fabric z infrastrukturą platformy Azure w celu zagwarantowania dostępności wszystkich aplikacji uruchomionych w klastrze.
  2. W przypadku uaktualnień i poprawek do platformy usługi Service Fabric usługa Service Fabric uaktualnia się bez utraty dostępności żadnych aplikacji uruchomionych w klastrze.
  3. Administrator aplikacji zatwierdza dodawanie lub usuwanie węzłów z klastra po przeanalizowaniu historycznych danych wykorzystania pojemności i przewidywanym przyszłym zapotrzebowaniu.
  4. Operator dodaje i usuwa węzły określone przez administratora aplikacji.
  5. Po dodaniu nowych węzłów do klastra lub usunięciu istniejących węzłów usługa Service Fabric automatycznie równoważy obciążenie uruchomionych aplikacji we wszystkich węzłach w klastrze w celu uzyskania optymalnej wydajności.

Usuń

  1. Operator może usunąć określone wystąpienie uruchomionej usługi w klastrze bez usuwania całej aplikacji przy użyciu metody DeleteServiceAsync, polecenia cmdlet Remove-ServiceFabricService lub operacji REST usuwania usługi.
  2. Operator może również usunąć wystąpienie aplikacji i wszystkie jego usługi przy użyciu metody DeleteApplicationAsync, polecenia cmdlet Remove-ServiceFabricApplication lub operacji Usuwania rest aplikacji.
  3. Po zatrzymaniu aplikacji i usług operator może cofnąć aprowizację typu aplikacji przy użyciu metody UnprovisionApplicationAsync, polecenia cmdlet Unregister-ServiceFabricApplicationType lub operacji CofabricApplicationType aplikacji. Anulowanie aprowizacji typu aplikacji nie powoduje usunięcia pakietu aplikacji z magazynu obrazów.
  4. Operator usuwa pakiet aplikacji z magazynu obrazów przy użyciu metody RemoveApplicationPackage lub polecenia cmdlet Remove-ServiceFabricApplicationPackage.

Zobacz Wdrażanie aplikacji , aby zapoznać się z przykładami.

Zachowywanie miejsca na dysku w magazynie obrazów klastra

Usługa ImageStoreService przechowuje skopiowane i aprowidowane pakiety, co może prowadzić do akumulowania plików. Akumulacja plików może spowodować wypełnienie dysku przez usługę ImageStoreService (fabric:/System/ImageStoreService) i zwiększenie czasu kompilacji replik usługi ImageStoreService.

Aby uniknąć akumulowania plików, użyj następującej sekwencji aprowizacji:

  1. Kopiowanie pakietu do magazynu obrazów i używanie opcji kompresji

  2. Aprowizuj pakiet

  3. Usuwanie pakietu w magazynie obrazów

  4. Uaktualnianie aplikacji/klastra

  5. Anulowanie aprowizacji starej wersji

Kroki 3 i 5 opisane w powyższej procedurze uniemożliwiają gromadzenie plików w magazynie obrazów.

Konfiguracja automatycznego czyszczenia

Krok 3 powyżej można zautomatyzować przy użyciu programu PowerShell lub xml. Spowoduje to automatyczne usunięcie pakietu aplikacji po pomyślnej rejestracji typu aplikacji.

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

Krok 5 powyżej można zautomatyzować przy użyciu kodu XML. Spowoduje to automatyczne wyrejestrowanie nieużywanych typów aplikacji.

<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

Czyszczenie plików i danych w węzłach

Replikacja plików aplikacji będzie ostatecznie dystrybuować pliki do wszystkich węzłów w zależności od akcji równoważenia. Może to spowodować wykorzystanie dysku w zależności od liczby aplikacji i rozmiaru pliku. Nawet jeśli żadne aktywne wystąpienie nie jest uruchomione w węźle, pliki z poprzedniego wystąpienia będą przechowywane. To samo dotyczy danych z niezawodnych kolekcji używanych przez usługi stanowe. Służy to celowi wyższej dostępności. W przypadku nowego wystąpienia aplikacji w tym samym węźle nie trzeba kopiować żadnych plików. W przypadku niezawodnych kolekcji należy replikować tylko różnicę.

Aby całkowicie usunąć pliki binarne aplikacji, należy wyrejestrować typ aplikacji.

Zalecenia dotyczące zmniejszenia ciśnienia dysku:

  1. Remove-ServiceFabricApplicationPackage powoduje usunięcie pakietu z lokalizacji tymczasowego przekazywania.
  2. Unregister-ServiceFabricApplicationType zwalnia miejsce do magazynowania, usuwając pliki typu aplikacji z usługi magazynu obrazów i wszystkich węzłów. Menedżer usuwania jest uruchamiany co godzinę na wartość domyślną.
  3. CleanupUnusedApplicationTypes automatycznie czyści stare nieużywane wersje aplikacji. 
    {
  "name": "Management",
  "parameters": [
    {
      "name": "CleanupUnusedApplicationTypes",
      "value": true
    },
    {
      "name": "MaxUnusedAppTypeVersionsToKeep",
      "value": "3"
    }
  ]
}
  4. Remove-ServiceFabricClusterPackage usuwa stare nieużywane pliki binarne instalacji środowiska uruchomieniowego.

Uwaga

Funkcja jest opracowywana, aby umożliwić usłudze Service Fabric usuwanie folderów aplikacji po ewakuacji aplikacji z węzła.

Następne kroki

Aby uzyskać więcej informacji na temat tworzenia, testowania i zarządzania aplikacjami i usługami usługi Service Fabric, zobacz: