Dlaczego warto używać podejścia mikrousług do tworzenia aplikacji
W przypadku deweloperów oprogramowania uwzględnianie aplikacji w części składników nie jest niczym nowym. Zazwyczaj jest używane podejście warstwowe z magazynem zaplecza, logiką biznesową warstwy środkowej i interfejsem użytkownika frontonu. To , co zmieniło się w ciągu ostatnich kilku lat, to to, że deweloperzy kompilują aplikacje rozproszone dla chmury.
Oto kilka zmieniających się potrzeb biznesowych:
- Usługa, która jest tworzona i obsługiwana na dużą skalę, aby dotrzeć do klientów w nowych regionach geograficznych.
- Szybsze dostarczanie funkcji i możliwości w celu reagowania na potrzeby klientów w sposób elastyczny.
- Ulepszone wykorzystanie zasobów w celu zmniejszenia kosztów.
Te potrzeby biznesowe wpływają na sposób tworzenia aplikacji.
Aby uzyskać więcej informacji na temat podejścia platformy Azure do mikrousług, zobacz Mikrousługi: rewolucja aplikacji obsługiwana przez chmurę.
Podejście projektowe monolityczne a mikrousług
Aplikacje ewoluują wraz z upływem czasu. Pomyślne aplikacje ewoluują, będąc przydatnym dla ludzi. Nieudane aplikacje nie ewoluują i są ostatecznie przestarzałe. Oto pytanie: ile wiesz o swoich wymaganiach dzisiaj i jakie będą one w przyszłości? Załóżmy na przykład, że tworzysz aplikację raportowania dla działu w firmie. Masz pewność, że aplikacja ma zastosowanie tylko w zakresie firmy i że raporty nie będą przechowywane długo. Twoje podejście różni się od tego, powiedzmy, tworzenia usługi, która dostarcza zawartość wideo do dziesiątków milionów klientów.
Czasami wyjście z drzwi jako dowód koncepcji jest czynnikiem napędzającym. Wiesz, że aplikacja może zostać przeprojektowana później. Nie ma sensu w nadmiernej inżynierii czegoś, co nigdy nie jest używane. Z drugiej strony, gdy firmy tworzą chmurę, oczekiwania to wzrost i użycie. Wzrost i skala są nieprzewidywalne. Chcemy szybko utworzyć prototyp, wiedząc również, że jesteśmy na ścieżce, która może poradzić sobie z przyszłym sukcesem. Jest to podejście oparte na lean startup: kompilowanie, mierzenie, uczenie się i iterowanie.
W czasie epoki klienta/serwera skupiliśmy się na tworzeniu aplikacji warstwowych przy użyciu określonych technologii w każdej warstwie. Termin aplikacja monolityczna pojawiła się w celu opisania tych podejść. Interfejsy miały tendencję do między warstwami, a bardziej ściśle powiązany projekt był używany między składnikami w każdej warstwie. Deweloperzy zaprojektowali i skompilowane klasy, które zostały skompilowane w biblioteki i połączone ze sobą w kilka plików wykonywalnych i bibliotek DLL.
Istnieją korzyści wynikające z podejścia do projektowania monolitycznego. Aplikacje monolityczne są często prostsze do projektowania, a wywołania między składnikami są szybsze, ponieważ te wywołania są często za pośrednictwem komunikacji międzyprocesowej (IPC). Ponadto każdy testuje pojedynczy produkt, który wydaje się być bardziej wydajnym wykorzystaniem zasobów ludzkich. Wadą jest to, że istnieje ścisłe sprzężenie między warstwami i nie można skalować poszczególnych składników. Jeśli musisz wykonać poprawki lub uaktualnienia, musisz poczekać, aż inne osoby zakończą testowanie. Trudniej jest być zwinny.
Mikrousługi odnoszą się do tych wad i ściślej są zgodne z poprzednimi wymaganiami biznesowymi. Ale mają również zarówno korzyści, jak i zobowiązania. Zalety mikrousług są takie, że każda z nich zwykle hermetyzuje prostszą funkcjonalność biznesową, którą można skalować w poziomie lub w poziomie, testować, wdrażać i zarządzać niezależnie. Jedną z ważnych zalet podejścia mikrousług jest to, że zespoły są napędzane bardziej przez scenariusze biznesowe niż przez technologię. Mniejsze zespoły tworzą mikrousługę na podstawie scenariusza klienta i używają dowolnych technologii, których chcą używać.
Innymi słowy, organizacja nie musi standaryzacji technologii do obsługi aplikacji mikrousług. Poszczególne zespoły, które są właścicielami usług, mogą robić to, co ma sens w oparciu o wiedzę zespołową lub co jest najbardziej odpowiednie do rozwiązania problemu. W praktyce preferowany jest zestaw zalecanych technologii, takich jak konkretny sklep NoSQL lub struktura aplikacji internetowych.
Wadą mikrousług jest to, że trzeba zarządzać bardziej oddzielnymi jednostkami i zajmować się bardziej złożonymi wdrożeniami i przechowywaniem wersji. Ruch sieciowy między mikrousługami zwiększa się, podobnie jak w przypadku odpowiednich opóźnień sieci. Wiele czatów, szczegółowe usługi mogą spowodować koszmar wydajności. Bez narzędzi ułatwiania wyświetlania tych zależności trudno jest zobaczyć cały system.
Standardy sprawiają, że podejście mikrousług działa, określając sposób komunikowania się i tolerowania tylko potrzebnych rzeczy z usługi, a nie sztywnych kontraktów. Ważne jest, aby zdefiniować te kontrakty z góry w projekcie, ponieważ usługi aktualizują się niezależnie od siebie. Inny opis ukuty do projektowania za pomocą podejścia mikrousług to "szczegółowa architektura zorientowana na usługi (SOA).
Najprostszym podejściem do projektowania mikrousług jest oddzielenie federacji usług, z niezależnymi zmianami w poszczególnych i uzgodnionych standardach komunikacji.
W miarę tworzenia większej liczby aplikacji w chmurze ludzie odkryli, że ta dekompozycja ogólnej aplikacji w niezależne, ukierunkowane na scenariusze usługi jest lepszym długoterminowym podejściem.
Porównanie metod tworzenia aplikacji
Aplikacja monolityczna zawiera funkcje specyficzne dla domeny i jest zwykle podzielona na warstwy funkcjonalne, takie jak internet, firma i dane.
Aplikację monolityczną można skalować, klonując ją na wielu serwerach/maszynach wirtualnych/kontenerach.
Aplikacja mikrousług oddziela funkcjonalność od oddzielnych mniejszych usług.
Podejście mikrousług jest skalowane w poziomie, wdrażając niezależnie każdą usługę, tworząc wystąpienia tych usług między serwerami/maszynami wirtualnymi/kontenerami.
Projektowanie przy użyciu podejścia mikrousług nie jest odpowiednie dla wszystkich projektów, ale jest bardziej zgodne z opisanymi wcześniej celami biznesowymi. Rozpoczęcie od podejścia monolitycznego może mieć sens, jeśli wiesz, że będziesz mieć możliwość późniejszego przerobienia kodu w projekcie mikrousług. Częściej zaczynasz od aplikacji monolitycznej i powoli rozbijasz ją na etapach, zaczynając od obszarów funkcjonalnych, które muszą być bardziej skalowalne lub zwinne.
W przypadku korzystania z podejścia mikrousług należy utworzyć aplikację wielu małych usług. Te usługi działają w kontenerach wdrożonych w klastrze maszyn. Mniejsze zespoły opracowują usługę, która koncentruje się na scenariuszu i niezależnie testuje, wersję, wdrażanie i skalowanie każdej usługi, aby cała aplikacja mogła ewoluować.
Co to jest mikrousługa?
Istnieją różne definicje mikrousług. Jednak większość z tych cech mikrousług jest powszechnie akceptowana:
- Hermetyzowanie scenariusza biznesowego lub klienta. Jaki problem rozwiązujesz?
- Opracowany przez mały zespół inżynieryjny.
- Napisane w dowolnym języku programowania przy użyciu dowolnej platformy.
- Składa się z kodu i opcjonalnego stanu, z których obie są niezależnie wersjonowane, wdrożone i skalowane.
- Interakcja z innymi mikrousługami za pośrednictwem dobrze zdefiniowanych interfejsów i protokołów.
- Mają unikatowe nazwy (adresy URL), które są używane do rozpoznawania ich lokalizacji.
- Zachowaj spójność i dostępność w obecności awarii.
Podsumowując:
Aplikacje mikrousług składają się z małych, niezależnie wersjonowanych i skalowalnych usług ukierunkowanych na klienta, które komunikują się ze sobą za pośrednictwem standardowych protokołów z dobrze zdefiniowanymi interfejsami.
Napisane w dowolnym języku programowania przy użyciu dowolnej struktury
Jako deweloperzy chcemy swobodnie wybierać język lub strukturę, w zależności od naszych umiejętności i potrzeb usługi, którą tworzymy. W przypadku niektórych usług możesz cenić korzyści z wydajności języka C++ powyżej innych elementów. W przypadku innych użytkowników łatwość zarządzania programowaniem uzyskiwana z języka C# lub Java może być ważniejsza. W niektórych przypadkach może być konieczne użycie określonej biblioteki partnerskiej, technologii magazynu danych lub metody uwidoczniania usługi klientom.
Po wybraniu technologii należy rozważyć zarządzanie operacjami lub cyklem życia i skalowanie usługi.
Umożliwia niezależne wersje, wdrażanie i skalowanie kodu i stanu
Bez względu na sposób pisania mikrousług, kodu i opcjonalnie stanu należy niezależnie wdrażać, uaktualniać i skalować. Ten problem jest trudny do rozwiązania, ponieważ sprowadza się do wyboru technologii. Aby skalować, zrozumienie sposobu partycjonowania (lub fragmentu) zarówno kodu, jak i stanu jest trudne. Gdy kod i stan korzystają z różnych technologii, które są obecnie wspólne, skrypty wdrażania dla mikrousługi muszą być w stanie je skalować. Ta separacja dotyczy również elastyczności i elastyczności, dzięki czemu można uaktualnić niektóre mikrousługi bez konieczności uaktualniania wszystkich z nich jednocześnie.
Wróćmy do naszego porównania podejścia monolitycznego i mikrousług na chwilę. Na tym diagramie przedstawiono różnice w podejściach do przechowywania stanu:
Magazyn stanu dla dwóch metod
Podejście monolityczne po lewej stronie ma jedną bazę danych i warstwy określonych technologii.
Podejście mikrousług po prawej stronie zawiera graf połączonych mikrousług, w których stan jest zwykle zakresem mikrousług i używane są różne technologie.
W podejściu monolitycznym aplikacja zwykle używa pojedynczej bazy danych. Zaletą korzystania z jednej bazy danych jest to, że znajduje się w jednej lokalizacji, co ułatwia wdrażanie. Każdy składnik może mieć jedną tabelę do przechowywania stanu. Zespoły muszą ściśle oddzielić stan, co jest wyzwaniem. Nieuchronnie ktoś będzie kuszony, aby dodać kolumnę do istniejącej tabeli klienta, wykonać sprzężenie między tabelami i utworzyć zależności w warstwie magazynu. Po wykonaniu tej czynności nie można skalować poszczególnych składników.
W podejściu mikrousług każda usługa zarządza i przechowuje własny stan. Każda usługa jest odpowiedzialna za skalowanie kodu i stanu razem w celu spełnienia wymagań usługi. Wadą jest to, że w przypadku konieczności tworzenia widoków lub zapytań dotyczących danych aplikacji należy wykonać zapytanie w wielu magazynach stanów. Ten problem jest zwykle rozwiązywany przez oddzielną mikrousługę, która tworzy widok w kolekcji mikrousług. Jeśli musisz uruchomić wiele zaimprowizujących zapytań dotyczących danych, rozważ zapisanie danych poszczególnych mikrousług w usłudze magazynowania danych na potrzeby analizy w trybie offline.
Mikrousługi są wersjonowane. Istnieje możliwość, aby różne wersje mikrousługi działały obok siebie. Nowsza wersja mikrousługi może zakończyć się niepowodzeniem podczas uaktualniania i musi zostać przywrócona do wcześniejszej wersji. Przechowywanie wersji jest również przydatne w przypadku testowania A/B, w którym różni użytkownicy korzystają z różnych wersji usługi. Na przykład często uaktualniamy mikrousługę dla określonego zestawu klientów, aby testować nowe funkcje przed szerszym wdrożeniem.
Współdziała z innymi mikrousługami za pośrednictwem dobrze zdefiniowanych interfejsów i protokołów
W ciągu ostatnich 10 lat opublikowano obszerne informacje opisujące wzorce komunikacji w architekturach zorientowanych na usługi. Ogólnie rzecz biorąc, komunikacja z usługą używa metody REST z protokołami HTTP i TCP i XML lub JSON jako format serializacji. Z perspektywy interfejsu chodzi o podejście do projektowania internetowego. Ale nic nie powinno uniemożliwiać korzystania z protokołów binarnych lub własnych formatów danych. Należy pamiętać, że użytkownicy będą mieli trudniejszy czas korzystania z mikrousług, jeśli te protokoły i formaty nie są otwarcie dostępne.
Ma unikatową nazwę (ADRES URL) używaną do rozpoznawania jego lokalizacji
Mikrousługa musi być adresowalna wszędzie tam, gdzie jest uruchomiona. Jeśli myślisz o maszynach i o tym, który z nich uruchamia konkretną mikrousługę, elementy mogą działać źle szybko.
W taki sam sposób, w jaki usługa DNS rozpoznaje określony adres URL określonej maszyny, mikrousługa potrzebuje unikatowej nazwy, aby jej bieżąca lokalizacja mogła zostać wykryta. Mikrousługi wymagają adresowych nazw niezależnych od infrastruktury, w której są uruchomione. Oznacza to, że istnieje interakcja między sposobem wdrażania usługi i sposobem jej odnajdowania, ponieważ musi istnieć rejestr usług. Gdy maszyna ulegnie awarii, usługa rejestru musi poinformować, do której lokalizacji została przeniesiona usługa.
Pozostaje spójny i dostępny w obecności awarii
Radzenie sobie z nieoczekiwanymi awariami jest jednym z najtrudniejszych problemów do rozwiązania, zwłaszcza w systemie rozproszonym. Większość kodu, który piszemy jako deweloperzy, służy do obsługi wyjątków. Podczas testowania poświęcamy również najwięcej czasu na obsługę wyjątków. Proces jest bardziej zaangażowany niż pisanie kodu do obsługi błędów. Co się stanie, gdy maszyna, na której uruchomiono mikrousługę, ulegnie awarii? Należy wykryć awarię, co jest trudnym problemem samodzielnie. Należy jednak również ponownie uruchomić mikrousługę.
Aby zapewnić dostępność, mikrousługę musi być odporna na błędy i możliwość ponownego uruchomienia na innej maszynie. Oprócz tych wymagań dotyczących odporności dane nie powinny zostać utracone, a dane muszą pozostać spójne.
Odporność jest trudna do osiągnięcia w przypadku awarii podczas uaktualniania aplikacji. Mikrousługa, pracując z systemem wdrażania, nie musi odzyskiwać. Musi określić, czy może przejść do nowszej wersji, czy przywrócić poprzednią wersję, aby zachować spójny stan. Należy wziąć pod uwagę kilka pytań, takich jak to, czy jest dostępna wystarczająca liczba maszyn, aby kontynuować, i jak odzyskać poprzednie wersje mikrousługi. Aby podjąć te decyzje, potrzebna jest mikrousługa do emitowania informacji o kondycji.
Zgłasza kondycję i diagnostykę
Może się wydawać oczywiste i często pomijane, ale mikrousługa musi zgłosić swoją kondycję i diagnostykę. W przeciwnym razie masz niewielki wgląd w jego kondycję z perspektywy operacji. Korelowanie zdarzeń diagnostycznych w zestawie niezależnych usług i radzenie sobie z niesymetrycznością zegara maszynowego, aby zrozumieć kolejność zdarzeń, jest trudne. W taki sam sposób, jak w przypadku interakcji z mikrousługą za pośrednictwem uzgodnionych protokołów i formatów danych, należy standaryzować sposób rejestrowania kondycji i zdarzeń diagnostycznych, które ostatecznie znajdą się w magazynie zdarzeń na potrzeby wykonywania zapytań i wyświetlania. W przypadku podejścia do mikrousług różne zespoły muszą uzgodnić pojedynczy format rejestrowania. Konieczne jest spójne podejście do wyświetlania zdarzeń diagnostycznych w aplikacji jako całości.
Kondycja różni się od diagnostyki. Kondycja dotyczy mikrousługi, która zgłasza swój bieżący stan w celu podjęcia odpowiednich działań. Dobrym przykładem jest praca z mechanizmami uaktualniania i wdrażania w celu zachowania dostępności. Chociaż usługa może być obecnie w złej kondycji z powodu awarii procesu lub ponownego uruchomienia maszyny, usługa może nadal działać. Ostatnią rzeczą, której potrzebujesz, jest pogorszyć sytuację, uruchamiając uaktualnienie. Najlepszym rozwiązaniem jest zbadanie najpierw lub zezwolenie na odzyskanie mikrousługi. Zdarzenia dotyczące kondycji z mikrousługi pomagają nam podejmować świadome decyzje, a w efekcie pomóc w tworzeniu usług samonaprawiania.
Wskazówki dotyczące projektowania mikrousług na platformie Azure
Odwiedź centrum architektury platformy Azure, aby uzyskać wskazówki dotyczące projektowania i tworzenia mikrousług na platformie Azure.
Service Fabric jako platforma mikrousług
Usługa Azure Service Fabric pojawiła się, gdy firma Microsoft przeszła z dostarczania produktów boxed, które były zwykle monolityczne, po dostarczanie usług. Doświadczenie w tworzeniu i obsłudze dużych usług, takich jak Azure SQL Database i Azure Cosmos DB, ukształtowało usługę Service Fabric. Platforma ewoluowała w miarę upływu czasu, gdy coraz więcej usług ją przyjęło. Usługa Service Fabric musiała działać nie tylko na platformie Azure, ale także w autonomicznych wdrożeniach systemu Windows Server.
Celem usługi Service Fabric jest rozwiązanie trudnych problemów związanych z tworzeniem i uruchamianiem usługi oraz efektywne korzystanie z zasobów infrastruktury, dzięki czemu zespoły mogą rozwiązywać problemy biznesowe przy użyciu podejścia mikrousług.
Usługa Service Fabric ułatwia tworzenie aplikacji korzystających z podejścia mikrousług, zapewniając:
- Platforma udostępniająca usługi systemowe do wdrażania, uaktualniania, wykrywania i ponownego uruchamiania usług, odnajdywania usług, kierowania komunikatów, zarządzania stanem i monitorowania kondycji.
- Możliwość wdrażania aplikacji działających w kontenerach lub jako procesów. Service Fabric to kontener i orkiestrator procesów.
- Produktywne interfejsy API programowania ułatwiające tworzenie aplikacji jako mikrousług: ASP.NET Core, Reliable Actors i Reliable Services. Możesz na przykład uzyskać informacje o kondycji i diagnostyce lub skorzystać z wbudowanej wysokiej dostępności.
Usługa Service Fabric jest niezależna od sposobu tworzenia usługi i możesz korzystać z dowolnej technologii. Zapewnia jednak wbudowane interfejsy API programowania, które ułatwiają tworzenie mikrousług.
Migrowanie istniejących aplikacji do usługi Service Fabric
Usługa Service Fabric umożliwia ponowne użycie istniejącego kodu i modernizację go za pomocą nowych mikrousług. Modernizacja aplikacji składa się z pięciu etapów i można rozpocząć i zatrzymać na dowolnym etapie. Etapy to:
- Zacznij od tradycyjnej aplikacji monolitycznej.
- Migracji. Używanie kontenerów lub plików wykonywalnych gościa do hostowania istniejącego kodu w usłudze Service Fabric.
- Modernizacji. Dodaj nowe mikrousługi wraz z istniejącym konteneryzowanym kodem.
- Innowacji. Podziel aplikację monolityczną na mikrousługi w zależności od potrzeb.
- Przekształcanie aplikacji w mikrousługi. Przekształć istniejące aplikacje monolityczne lub tworzyć nowe aplikacje greenfield.
Pamiętaj, że możesz rozpocząć i zatrzymać się na dowolnym z tych etapów. Nie musisz przechodzić do następnego etapu.
Przyjrzyjmy się przykładom dla każdego z tych etapów.
Migrate
Z dwóch powodów wiele firm migruje istniejące aplikacje monolityczne do kontenerów:
- Obniżenie kosztów z powodu konsolidacji i usunięcia istniejącego sprzętu lub z powodu uruchamiania aplikacji o większej gęstości.
- Spójny kontrakt wdrażania między programowaniem i operacjami.
Obniżki kosztów są proste. W firmie Microsoft wiele istniejących aplikacji jest konteneryzowanych, co prowadzi do milionów dolarów oszczędności. Spójne wdrażanie jest trudniejsze do oceny, ale równie ważne. Oznacza to, że deweloperzy mogą wybierać odpowiednie technologie, ale operacje akceptują tylko jedną metodę wdrażania aplikacji i zarządzania nimi. Pozwala to złagodzić konieczność radzenia sobie ze złożonością obsługi różnych technologii bez zmuszania deweloperów do wyboru tylko niektórych. Zasadniczo każda aplikacja jest konteneryzowana do autonomicznych obrazów wdrażania.
Wiele organizacji zatrzymuje się tutaj. Mają one już zalety kontenerów, a usługa Service Fabric zapewnia pełne środowisko zarządzania, w tym wdrażanie, uaktualnienia, przechowywanie wersji, wycofywanie i monitorowanie kondycji.
Modernizacji
Modernizacja to dodanie nowych usług obok istniejącego kodu konteneryzowanego. Jeśli zamierzasz napisać nowy kod, najlepiej wykonać małe kroki w dół ścieżki mikrousług. Może to oznaczać dodanie nowego punktu końcowego interfejsu API REST lub nowej logiki biznesowej. W ten sposób rozpoczniesz proces tworzenia nowych mikrousług i opracowywania i wdrażania ich.
Innowacje
Podejście mikrousług odpowiada zmieniającym się potrzebom biznesowym. Na tym etapie musisz zdecydować, czy rozpocząć dzielenie aplikacji monolitycznej na usługi, czy wprowadzanie innowacji. Klasycznym przykładem jest to, że baza danych używana jako kolejka przepływu pracy staje się wąskim gardłem przetwarzania. Wraz ze wzrostem liczby żądań przepływu pracy praca musi być dystrybuowana na dużą skalę. Weźmy ten konkretny fragment aplikacji, która nie jest skalowana lub która musi być aktualizowana częściej, i podziel ją jako mikrousługę i innowacje.
Przekształcanie aplikacji w mikrousługi
Na tym etapie aplikacja składa się w pełni z mikrousług (lub podzielonych na). Aby osiągnąć ten punkt, wykonano podróż mikrousług. Możesz zacząć tutaj, ale w tym celu bez platformy mikrousług, aby pomóc w istotnych inwestycjach.
Czy mikrousługi są odpowiednie dla mojej aplikacji?
Być może. W firmie Microsoft, ponieważ coraz więcej zespołów zaczęło tworzyć chmurę ze względów biznesowych, wiele z nich zdało sobie sprawę z zalet korzystania z podejścia przypominającego mikrousługę. Na przykład usługa Bing od lat korzysta z mikrousług. W przypadku innych zespołów podejście mikrousług było nowe. Zespoły wykazały, że były trudne problemy do rozwiązania poza ich podstawowymi obszarami siły. Dlatego usługa Service Fabric zyskała przyczepność jako technologię usług budowlanych.
Celem usługi Service Fabric jest zmniejszenie złożoności tworzenia aplikacji mikrousług, dzięki czemu nie trzeba przechodzić przez tyle kosztownych zmian projektu. Rozpocznij małe, skalowane w razie potrzeby, przestarzałe usługi, dodaj nowe i ewoluuj wraz z użyciem klientów. Wiemy również, że istnieje wiele innych problemów, które jeszcze należy rozwiązać, aby mikrousługi były bardziej dostępne dla większości deweloperów. Kontenery i model programowania aktora to przykłady małych kroków w tym kierunku. Na pewno pojawi się więcej innowacji, aby ułatwić podejście mikrousług.