Czy każdy może skierować mnie do czegoś, co wyjaśni, kiedy powinienem utworzyć aplikację usługi Azure Service Fabric a aplikację usługi aplikacji Azure? Mam aplikację, którą chcę zbudować, ale nie mogę ustalić, czy powinienem ją zbudować przy użyciu usługi Azure Service Fabric lub usługi aplikacji Azure.Usługa aplikacji Azure a usługa usług Azure
Firma Microsoft utworzyła document z porównaniem dla usługi aplikacji Azure, maszyn wirtualnych, usługi sieciowej i usług w chmurze.
Niestety, nie ma oficjalnych wskazówek dotyczących tego, kiedy należy korzystać z czego. Są to dwie oddzielne platformy, według różnych paradygmatów rozwoju.
Usługa aplikacji zapewnia funkcjonalność, której usługa Service Fabric nie zapewnia po wyjęciu z pudełka. Rzeczy takie, jak automatyczne skalowanie, uwierzytelnianie, ograniczanie szybkości, integracja z aplikacjami SaaS itp. Niektóre lub wszystkie te rzeczy mogą pojawiać się stopniowo w usłudze serwisowej, ale powiedziałbym, że z minuty na minutę są skierowane do różnych odbiorców - a mniej doświadczony zespół może łatwiej pracować z usługą App.
Tkanina serwisowa z drugiej strony ułatwia kompozycję części. Na przykład w "tradycyjnym" podejściu, jeśli masz interfejs API, który przemawia do składnicy danych i do pamięci podręcznej, aby uniknąć uderzeń w składnicy danych, musiałbyś obsłużyć różne scenariusze tolerancji błędów. Dzięki usłudze Service Fabric pamięć podręczna może być przechowywana w procesie API w niezawodny sposób i nie będziesz mieć do czynienia z zewnętrznym komponentem pamięci podręcznej. Dane są umieszczane razem z usługą (szybciej są pobierane/edytowane!) I są niezawodne, ponieważ są dystrybuowane we wszystkich węzłach, w których usługa jest wdrożona. Podobnie jest z kolejkami. Jeśli myślisz o systemie typu przepływu pracy, gdzie jest API, usługa pracy i kolejka, która znajduje się między nimi i pozwala im się komunikować, musisz zarządzać 3 różnymi komponentami i komunikacją między nimi. Dzięki aplikacji Service Fabric kolejka trafia do aplikacji. A to już tylko połowa z nich :) zyskujesz także moc używania modelu aktora do obliczeń rozproszonych bez typowych problemów związanych z współbieżnością. Wreszcie dzięki usłudze Service Fabric możesz korzystać z bardziej kompletnego środowiska programistycznego na swoim lokalnym komputerze - nie musisz zajmować się tworzeniem kolejek itp. Na koncie programisty Azure lub czymś podobnym.
Warto również zauważyć, że nic nie stoi na przeszkodzie, aby użyć obu paradygmatów - wyobraź sobie dwie aplikacje, z których co najmniej jedna jest aplikacją usługową, która eksponuje interfejsy API i aplikację logiczną, która znajduje się nad nimi.
Twoja decyzja powinna być oparta na tym, co próbujesz zbudować, w jakim czasie, kiedy chcesz ją wydać (usługa Fabric jest obecnie tylko w prywatnym podglądu, więc minie trochę czasu, zanim dotrą do GA) i jaki rodzaj zespołu masz. Wyobrażam sobie, że dzięki usłudze App Service łatwo będzie osiągnąć sukces, nawet jeśli nie masz masowo doświadczonego zespołu, ale Service Fabric da ci większą moc, elastyczność i kontrolę.
Dziękuję Charisk, to zdecydowanie pomaga. Myślę, że model hybrydowy jest atrakcyjny. Chciałbym wykorzystać prostotę i dodatkowe funkcje usługi aplikacji dla moich aplikacji internetowych i API, ale chciałbym zbudować tylny koniec systemu z wykorzystaniem tkaniny usługowej. Przekopię się, aby zrozumieć, jak to zrobić więcej. Mamy nadzieję, że istnieje sposób, aby uzyskać najlepsze z obu światów. :) – StewartArmbrecht
Usługa aplikacji jest usługą bardziej zarządzaną, SF to więcej, niż możesz zarządzać własną i możesz również prowadzić działalność we własnej siedzibie. SF ma lepsze wsparcie dla twórców aplikacji innych niż MS, np. Natywnych aplikacji itp.
Zgodnie z tym dokumentem: "Usługa serwisowa to dobry wybór, jeśli tworzysz nową aplikację lub przepisujesz istniejącą aplikację, aby używała architektury mikroserwisu . "
Jeśli Twój hosting kilku aplikacji nie powinieneś patrzeć na SF, Z drugiej strony, jeśli wdrożenie ponad 10 usług niż stanie się lepszym rozwiązaniem.
Należy również pamiętać, że SF ma mechanizm przechowywania danych dołączony do usług.Jest dobry na 3 rzeczy 1) Ogromne klastry danych 2) Proste dane, często w usługach Micros DB stają się dużym obciążeniem, ponieważ każda usługa powinna mieć własne dane, a rzeczy takie jak SQL są nieco przesadzone, gdy masz tylko 1-3 tabele. 3) Magazyn stanu dla modelu programistycznego Actor.
Wydaje mi się, że aplikacje SF i Web będą w przyszłości ograniczać liczbę użytkowników usługi "Cloud Service".
Nie sądzę, że istnieje ostateczny przewodnik - zależy to od tego, co próbujesz zbudować i od tego, jaki masz zespół. Może możesz podzielić się niektórymi z tych informacji? – charisk
Jest to niestandardowa aplikacja do zarządzania projektami dla przedsiębiorstw, która może zostać rozszerzona do systemu zarządzania treścią i nie tylko. Można go łatwo zbudować przy użyciu standardowego interfejsu API i aplikacji internetowych, ale nie jestem pewien, co by się poddałem. Podoba mi się skalowalność usługi Service Fabric, zarówno pod względem wydajności, jak i rozwoju. Jednak nie wiem, co by się poddałem, jeśli przyjmuję to podejście w stosunku do podejścia App Service. Miałem nadzieję, że to będzie coś, co przedstawi wady i zalety każdego podejścia. Jak decydujesz między tymi dwoma? – StewartArmbrecht
Ten artykuł może pomóc w porównywaniu usług aplikacji Azure, maszyn wirtualnych, usług sieciowych i usług w chmurze - https://docs.microsoft.com/en-us/azure/app-service-web/choose-web-site- cloud-service-vm – mvark