Dowiedz się więcej o różnicach między usługami Cloud Services i Usługą Service Fabric przed migracją aplikacji.
Microsoft Azure Service Fabric to platforma aplikacji w chmurze nowej generacji dla wysoce skalowalnych, wysoce niezawodnych aplikacji rozproszonych. Wprowadzono w nim wiele nowych funkcji tworzenia pakietów, wdrażania, uaktualniania i zarządzania rozproszonymi aplikacjami w chmurze.
Jest to przewodnik wprowadzający do migrowania aplikacji z usług Cloud Services do usługi Service Fabric. Koncentruje się głównie na różnicach architektury i projektowania między usługami Cloud Services i Service Fabric.
Aplikacje i infrastruktura
Podstawową różnicą między usługami Cloud Services i Service Fabric jest relacja między maszynami wirtualnymi, obciążeniami i aplikacjami. Obciążenie w tym miejscu jest definiowane jako kod, który piszesz w celu wykonania określonego zadania lub świadczenia usługi.
- Usługi Cloud Services dotyczą wdrażania aplikacji jako maszyn wirtualnych. Kod, który piszesz, jest ściśle powiązany z wystąpieniem maszyny wirtualnej, takim jak rola sieci Web lub procesu roboczego. Aby wdrożyć obciążenie w usługach Cloud Services, należy wdrożyć co najmniej jedno wystąpienie maszyny wirtualnej, które uruchamia obciążenie. Nie ma separacji aplikacji i maszyn wirtualnych, dlatego nie ma formalnej definicji aplikacji. Aplikację można traktować jako zestaw wystąpień roli sieci Web lub procesu roboczego w ramach wdrożenia usług Cloud Services lub jako całego wdrożenia usług Cloud Services. W tym przykładzie aplikacja jest wyświetlana jako zestaw wystąpień ról.
- Usługa Service Fabric dotyczy wdrażania aplikacji na istniejących maszynach wirtualnych lub maszynach z usługą Service Fabric w systemie Windows lub Linux. Zapisane usługi są całkowicie oddzielone od podstawowej infrastruktury, która jest oddzielona od platformy aplikacji usługi Service Fabric, dzięki czemu można wdrożyć aplikację w wielu środowiskach. Obciążenie w usłudze Service Fabric jest nazywane "usługą", a co najmniej jedna usługa jest grupowana w formalnie zdefiniowanej aplikacji działającej na platformie aplikacji usługi Service Fabric. W jednym klastrze usługi Service Fabric można wdrożyć wiele aplikacji.
Sama usługa Service Fabric jest warstwą platformy aplikacji działającą w systemie Windows lub Linux, natomiast usługi Cloud Services to system wdrażania maszyn wirtualnych zarządzanych przez platformę Azure z dołączonymi obciążeniami. Model aplikacji usługi Service Fabric ma wiele zalet:
- Szybkie czasy wdrażania. Tworzenie wystąpień maszyn wirtualnych może być czasochłonne. W usłudze Service Fabric maszyny wirtualne są wdrażane tylko raz, aby utworzyć klaster hostujący platformę aplikacji usługi Service Fabric. Od tego momentu pakiety aplikacji można wdrażać w klastrze bardzo szybko.
- Hosting o wysokiej gęstości. W usługach Cloud Services maszyna wirtualna roli procesu roboczego hostuje jedno obciążenie. W usłudze Service Fabric aplikacje są oddzielone od maszyn wirtualnych, które je uruchamiają, co oznacza, że można wdrożyć dużą liczbę aplikacji na małej liczbie maszyn wirtualnych, co może obniżyć całkowity koszt większych wdrożeń.
- Platforma Service Fabric może działać w dowolnym miejscu, na których znajdują się maszyny z systemem Windows Server lub Linux, niezależnie od tego, czy jest to platforma Azure, czy lokalna. Platforma zapewnia warstwę abstrakcji nad podstawową infrastrukturą, dzięki czemu aplikacja może działać w różnych środowiskach.
- Rozproszone zarządzanie aplikacjami. Usługa Service Fabric to platforma, która nie tylko hostuje aplikacje rozproszone, ale także ułatwia zarządzanie cyklem życia niezależnie od hostowania maszyny wirtualnej lub cyklu życia maszyny.
Architektura aplikacji
Architektura aplikacji usług w chmurze zwykle obejmuje wiele zależności usług zewnętrznych, takich jak Service Bus, Azure Table i Blob Storage, SQL, Redis i inne, aby zarządzać stanem i danymi aplikacji oraz komunikacją między rolami internetowymi i procesami roboczymi we wdrożeniu usług Cloud Services. Przykład kompletnej aplikacji usług Cloud Services może wyglądać następująco:
Aplikacje usługi Service Fabric mogą również używać tych samych usług zewnętrznych w kompletnej aplikacji. Korzystając z tej przykładowej architektury usług Cloud Services, najprostszą ścieżką migracji z usług Cloud Services do usługi Service Fabric jest zastąpienie tylko wdrożenia usług Cloud Services aplikacją usługi Service Fabric, zachowując ogólną architekturę tak samo. Role sieci Web i procesu roboczego można przenosić do usług bezstanowych usługi Service Fabric z minimalnymi zmianami kodu.
Na tym etapie system powinien nadal działać tak samo jak wcześniej. Korzystając z funkcji stanowych usługi Service Fabric, magazyny stanów zewnętrznych mogą być wewnętrznych jako usługi stanowe, jeśli ma to zastosowanie. Jest to bardziej zaangażowane niż prosta migracja ról sieci Web i procesów roboczych do usług bezstanowych usługi Service Fabric, ponieważ wymaga pisania usług niestandardowych, które zapewniają równoważne funkcje aplikacji, jak wcześniej usługi zewnętrzne. Korzyści wynikające z tego obejmują:
- Usuwanie zależności zewnętrznych
- Ujednolicenie modeli wdrażania, zarządzania i uaktualniania.
Przykładowa architektura wewnętrznych tych usług może wyglądać następująco:
Komunikacja i przepływ pracy
Większość aplikacji usługi w chmurze składa się z więcej niż jednej warstwy. Podobnie aplikacja usługi Service Fabric składa się z więcej niż jednej usługi (zazwyczaj wielu usług). Dwa typowe modele komunikacji to bezpośrednia komunikacja i zewnętrzny trwały magazyn.
Bezpośrednia komunikacja
Dzięki bezpośredniej komunikacji warstwy mogą komunikować się bezpośrednio za pośrednictwem punktu końcowego udostępnianego przez każdą warstwę. W środowiskach bezstanowych, takich jak Usługi w chmurze, oznacza to wybranie wystąpienia roli maszyny wirtualnej, losowego lub okrężnego w celu zrównoważenia obciążenia i bezpośredniego nawiązania połączenia z punktem końcowym.
Komunikacja bezpośrednia jest typowym modelem komunikacji w usłudze Service Fabric. Kluczową różnicą między usługami Service Fabric i Cloud Services jest to, że w usługach Cloud Services łączysz się z maszyną wirtualną, podczas gdy w usłudze Service Fabric łączysz się z usługą. Jest to ważne rozróżnienie z kilku powodów:
- Usługi w usłudze Service Fabric nie są powiązane z maszynami wirtualnymi, które je hostują; usługi mogą poruszać się w klastrze, a w rzeczywistości oczekuje się, że zostaną przeniesione z różnych powodów: równoważenie zasobów, tryb failover, uaktualnienia aplikacji i infrastruktury oraz umieszczanie lub ograniczenia obciążenia. Oznacza to, że adres wystąpienia usługi może ulec zmianie w dowolnym momencie.
- Maszyna wirtualna w usłudze Service Fabric może hostować wiele usług, z których każdy ma unikatowe punkty końcowe.
Usługa Service Fabric udostępnia mechanizm odnajdywania usług nazywany usługą Naming Service, który może służyć do rozpoznawania adresów punktów końcowych usług.
Kolejki
Typowym mechanizmem komunikacji między warstwami w środowiskach bezstanowych, takich jak usługi Cloud Services, jest użycie zewnętrznej kolejki magazynu do trwałego przechowywania zadań roboczych z jednej warstwy na drugą. Typowym scenariuszem jest warstwa internetowa, która wysyła zadania do kolejki platformy Azure lub usługi Service Bus, w której wystąpienia roli procesu roboczego mogą usuwać kolejkę i przetwarzać zadania.
Ten sam model komunikacji może być używany w usłudze Service Fabric. Może to być przydatne podczas migrowania istniejącej aplikacji usług Cloud Services do usługi Service Fabric.
Parzystość
Usługi w chmurze są podobne do usługi Service Fabric w stopniu kontroli i łatwości użycia, ale obecnie jest to starsza usługa i usługa Service Fabric jest zalecana do tworzenia nowych rozwiązań. Poniżej przedstawiono porównanie interfejsów API:
| Interfejs API usługi w chmurze | Service Fabric API | Uwagi |
|---|---|---|
| RoleInstance.GetID | FabricRuntime.GetNodeContext.NodeId lub . Nazwa węzła | Id jest właściwością NodeName |
| RoleInstance.GetFaultDomain | FabricClient.QueryManager.GetNodeList | Filtrowanie właściwości NodeName i używanie właściwości FD |
| RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | Filtruj w węźle NodeName i użyj właściwości Upgrade |
| RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext lub Naming (ResolveService) | CodePackageActivationContext, który jest dostarczany zarówno przez FabricRuntime.GetActivationContext, jak i w replikach za pośrednictwem serviceInitializationParameters.CodePackageActivationContext dostarczone podczas . Zainicjuj |
| RoleEnvironment.GetRoles | FabricClient.QueryManager.GetNodeList | Jeśli chcesz wykonać ten sam rodzaj filtrowania według typu, możesz pobrać listę typów węzłów z manifestu klastra za pośrednictwem fabricClient.ClusterManager.GetClusterManifest i pobrać typy ról/węzłów z tego miejsca. |
| RoleEnvironment.GetIsAvailable | Connect-WindowsFabricCluster lub utwórz sieć szkieletowąRuntime wskazującą określony węzeł | * |
| RoleEnvironment.GetLocalResource | CodePackageActivationContext.Log/Temp/Work | * |
| RoleEnvironment.GetCurrentRoleInstance | CodePackageActivationContext.Log/Temp/Work | * |
| LocalResource.GetRootPath | CodePackageActivationContext.Log/Temp/Work | * |
| Role.GetInstances | FabricClient.QueryManager.GetNodeList lub ResolveService | * |
| RoleInstanceEndpoint.GetIPEndpoint | FabricRuntime.GetActivationContext lub Naming (ResolveService) | * |
Następne kroki
Najprostszą ścieżką migracji z usług Cloud Services do usługi Service Fabric jest zastąpienie tylko wdrożenia usług Cloud Services aplikacją usługi Service Fabric, zachowując ogólną architekturę aplikacji mniej więcej tak samo. Poniższy artykuł zawiera przewodnik ułatwiając konwertowanie roli sieci Web lub procesu roboczego na usługę bezstanową usługi Service Fabric.