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 pierwszą klasę obsługi pełnego cyklu życia aplikacji w chmurze, od programowania przez wdrożenie, 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, który opisuje 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 służy do bezpośredniego nawiązywania połączenia z klastrem usługi Service Fabric (niezależnie od tego, gdzie jest hostowany) i zarządzania klastrem, aplikacjami i usługami.

Role modelu usługi

Role modelu usługi to:

  • Deweloper usług: 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, integrując kolekcję usług w celu spełnienia określonych wymagań lub scenariuszy. Na przykład witryna internetowa handlu elektronicznego może zintegrować usługę "JSON Stateless Front-End Service", "Auction Stateful Service" i "Queue Stateful Service" w celu utworzenia rozwiązania do aukcji.
  • Administrator aplikacji: podejmuje decyzje dotyczące konfiguracji aplikacji (wypełnianie parametrów szablonu konfiguracji), wdrażanie (mapowanie na dostępne zasoby) 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) aplikacji. 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ług składowych oraz odpowiednio przesłaniając i parametryzując różne ustawienia konfiguracji i wdrażania usług składowych.

Zobacz Wprowadzenie do usług Reliable Actors i Wprowadzenie do usług Reliable Services , aby zapoznać się z przykładami.

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 tworzenie 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.

Testowanie

  1. Po wdrożeniu w lokalnym klastrze deweloperów lub klastrze testowym deweloper usługi uruchamia wbudowany scenariusz testu trybu failover przy użyciu klas FailoverTestScenarioParameters i FailoverTestScenario lub Invoke-ServiceFabricFailoverTestScenario. Scenariusz testowy 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 węzłów, pakietu kodu i błędów repliki do klastra.
  3. Deweloper usługitestuje komunikację między usługami przez tworzenie scenariuszy testowych, 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 usterki i udostępnia nową wersję manifestu usługi.
  2. Deweloper aplikacji zastępuje i parametryzuje ustawienia konfiguracji i wdrażania spójnych usług i 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, polecenia cmdlet Start-ServiceFabricApplicationUpgrade lub operacji REST uaktualniania aplikacji.
  7. Operator sprawdza postęp uaktualniania przy użyciu metody GetApplicationUpgradeProgressAsync, polecenia cmdlet Get-ServiceFabricApplicationUpgrade lub operacji REST Get Application Upgrade Progress.
  8. W razie potrzeby operator modyfikuje i ponownie uruchamia 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 aplikacji.
  10. Usługa Service Fabric uaktualnia docelową aplikację działającą w klastrze bez utraty dostępności żadnej z jej usług składowych.

Zobacz samouczek 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 działających 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 dowolnych aplikacji działających 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 lub usunięciu istniejących węzłów z klastra 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 REST usuwania 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 cofania aprowizacji operacji REST 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 kopie i aprowizowane pakiety, co może prowadzić do gromadzenia plików. Akumulacja plików może spowodować, że usługa ImageStoreService (fabric:/System/ImageStoreService) wypełni dysk i może zwiększyć czas kompilacji replik usługi ImageStoreService.

Aby uniknąć gromadzenia 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 w powyższej procedurze uniemożliwiają akumulację plików w magazynie obrazów.

Konfiguracja automatycznego oczyszczania

Krok 3 powyżej można zautomatyzować przy użyciu programu PowerShell lub kodu 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 w końcu 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 ich 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 do zapewnienia 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 tymczasowej lokalizacji przekazywania.
  2. Unregister-ServiceFabricApplicationType zwalnia miejsce do magazynowania przez usunięcie plików 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: