Dlaczego warto używać podejścia mikrousług do tworzenia aplikacji
W przypadku deweloperów oprogramowania faktorowanie 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, polega na tym, że deweloperzy kompilują aplikacje rozproszone dla chmury.
Oto kilka zmieniających się potrzeb biznesowych:
- Usługa, która została skompilowana 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 elastyczny sposób.
- 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 oparta na chmurze.
Podejście projektowe monolityczne a mikrousługi
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 będzie różnić się od tego, powiedzmy, tworzenia usługi, która dostarcza treści wideo do dziesiątek 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 są wzrostem i użyciem. Wzrost i skala są nieprzewidywalne. Chcemy szybko utworzyć prototyp, wiedząc również, że jesteśmy na drodze, która może poradzić sobie z przyszłym sukcesem. Jest to podejście oparte na chudym startupie: tworzenie, mierzenie, uczenie się i iterowanie.
W czasie ery klienta/serwera skupiliśmy się na tworzeniu aplikacji warstwowych przy użyciu określonych technologii w każdej warstwie. W celu opisania tych podejść pojawiły się terminy monolityczne . Interfejsy były zwykle między warstwami, a bardziej ściśle powiązany projekt był używany między składnikami w każdej warstwie. Deweloperzy zaprojektowali i zskładnikowane 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ą one również zarówno korzyści, jak i zobowiązania. Zaletą mikrousług jest to, że każda z nich zwykle hermetyzuje prostsze funkcje biznesowe, które 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 wzrasta, podobnie jak odpowiednie opóźnienia sieci. Wiele czatów, szczegółowych usług może 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 elementów 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).
W najprostszym podejściu projektowym mikrousług chodzi o oddzieloną federację 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żnych, skoncentrowanych na scenariuszach usługach jest lepszym podejściem długoterminowym.
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 funkcje od oddzielnych mniejszych usług.
Podejście mikrousług jest skalowane w poziomie przez niezależne wdrażanie każdej usługi, 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 przepracowania 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, wersje, 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.
- Napisany w dowolnym języku programowania przy użyciu dowolnej platformy.
- Składa się z kodu i opcjonalnego stanu, które 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żnych wersji i skalowalnych usług skoncentrowanych na klientach, 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 platformy
Jako deweloperzy chcemy być wolni, aby wybrać 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 osób łatwość zarządzania programowaniem uzyskanym z języka C# lub Java może być ważniejsze. W niektórych przypadkach może być konieczne użycie określonej biblioteki partnerskiej, technologii magazynu danych lub metody uwidaczniania usługi klientom.
Po wybraniu technologii należy rozważyć zarządzanie operacjami lub cyklem życia i skalowanie usługi.
Umożliwia niezależne wersjonowane, wdrożone i skalowane niezależnie kod i stan
Niezależnie od sposobu pisania mikrousług, kodu i opcjonalnie stanu należy niezależnie wdrożyć, uaktualnić i skalować. Ten problem jest trudny do rozwiązania, ponieważ sprowadza się do wyboru technologii. Aby przeprowadzić skalowanie, zrozumienie sposobu partycjonowania (lub fragmentu) zarówno kodu, jak i stanu jest trudne. Gdy kod i stan używają 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 ich uaktualniania 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:
Przechowywanie stanu dla dwóch podejść
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 powiązany z mikrousługą i używane są różne technologie.
W podejściu monolitycznym aplikacja zazwyczaj używa pojedynczej bazy danych. Zaletą korzystania z jednej bazy danych jest to, że znajduje się ona 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 tym wystąpieniu 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 zarówno kodu, jak i stanu w celu spełnienia wymagań usługi. Wadą jest to, że jeśli musisz utworzyć widoki lub zapytania danych aplikacji, musisz 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 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ć wycofana z wcześniejszej wersji. Przechowywanie wersji jest również przydatne w przypadku testowania A/B, gdzie różni użytkownicy korzystają z różnych wersji usługi. Na przykład często uaktualnianie mikrousługi dla określonego zestawu klientów w celu przetestowania nowych funkcji przed ich 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 podejścia 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ą otwarte.
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 które z nich uruchamia konkretną mikrousługę, elementy mogą działać źle.
W taki sam sposób, jak usługa DNS rozpoznaje określony adres URL określonego komputera, mikrousługa potrzebuje unikatowej nazwy, aby jej bieżąca lokalizacja mogła być wykrywalna. Mikrousługi wymagają nazw adresowych, które są niezależne od infrastruktury, na której działają. Oznacza to, że istnieje interakcja między sposobem wdrażania usługi i sposobem jej odnalezienia, 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 w celu obsługi błędów. Co się stanie, gdy maszyna, na której uruchomiono mikrousługę, kończy się niepowodzeniem? Musisz wykryć awarię, co jest własnym problemem. Należy jednak również ponownie uruchomić mikrousługę.
W celu zapewnienia dostępności mikrousług musi być odporna na awarie i możliwość ponownego uruchomienia na innym komputerze. 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, gdy występują błędy podczas uaktualniania aplikacji. Mikrousługa, pracując z systemem wdrażania, nie musi odzyskiwać danych. Musi określić, czy może on przejść do nowszej wersji, czy przywrócić poprzednią wersję, aby zachować spójny stan. Należy wziąć pod uwagę kilka pytań, takich jak dostępność wystarczającej liczby 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 wydawać się oczywiste i często pomijane, ale mikrousługa musi zgłaszać 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 ze 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 znormalizować sposób rejestrowania zdarzeń kondycji i diagnostyki, które ostatecznie znajdą się w magazynie zdarzeń na potrzeby wykonywania zapytań i wyświetlania. W przypadku podejścia mikrousług różne zespoły muszą uzgodnić jeden 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 raportowania bieżącego stanu 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.
Usługa 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, do dostarczania 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 wraz z upływem czasu, gdy coraz więcej usług go przyjęła. 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. Usługa Service Fabric jest kontenerem i orkiestratorem procesów.
- Wydajne 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 diagnostyki lub skorzystać z wbudowanej wysokiej dostępności.
Usługa Service Fabric jest niezależna od sposobu tworzenia usługi i możesz użyć 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 to pięć etapów, które można uruchomić i zatrzymać na dowolnym etapie. Etapy to:
- Zacznij od tradycyjnej aplikacji monolitycznej.
- Migracja. Używanie kontenerów lub plików wykonywalnych gościa do hostowania istniejącego kodu w usłudze Service Fabric.
- Modernizować. Dodaj nowe mikrousługi wraz z istniejącym kodem konteneryzowanym.
- Innowacje. Podziel aplikację monolityczną na mikrousługi w zależności od potrzeb.
- Przekształcanie aplikacji w mikrousługi. Przekształcanie istniejących aplikacji monolitycznych lub tworzenie nowych aplikacji 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 (Migracja)
Z dwóch powodów wiele firm migruje istniejące aplikacje monolityczne do kontenerów:
- Obniżenie kosztów ze względu na konsolidację i usunięcie istniejącego sprzętu lub z powodu uruchamiania aplikacji o większej gęstości.
- Spójny kontrakt wdrażania między programowaniem a operacjami.
Redukcje 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 wdrożenie jest trudniejsze do oceny, ale równie ważne. Oznacza to, że deweloperzy mogą wybrać odpowiednie technologie, ale operacje będą akceptować tylko jedną metodę wdrażania aplikacji i zarządzania nimi. Pozwala to złagodzić operacje z konieczności 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.
Modernizować
Modernizacja to dodanie nowych usług wraz z istniejącym kodem konteneryzowanym. 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 ćwiczysz ich opracowywanie i wdrażanie.
Innowacji
Podejście mikrousług odpowiada zmieniającym się potrzebom biznesowym. Na tym etapie należy zdecydować, czy zacząć dzielić aplikację monolityczną na usługi, czy wprowadzać innowacje. 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 należy rozłożyć pracę na potrzeby skalowania. Weź 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 z podziałem). Aby osiągnąć ten punkt, wykonano podróż mikrousług. Możesz zacząć tutaj, ale aby to zrobić bez platformy mikrousług, aby pomóc w znaczących 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 podejścia przypominającego mikrousługę. Na przykład usługa Bing używa mikrousług od lat. W przypadku innych zespołów podejście mikrousług było nowe. Zespoły wykazały, że nie było trudnych problemów, aby rozwiązać poza ich podstawowymi obszarami siły. Dlatego usługa Service Fabric zyskała trakcję 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 przeprojektów. Rozpocznij małe, skalowane w razie potrzeby, przestarzałe usługi, dodaj nowe i ewoluuj wraz z użyciem klienta. Wiemy również, że istnieje wiele innych problemów, które należy jeszcze rozwiązać, aby mikrousługi były bardziej dostępne dla większości deweloperów. Kontenery i model programowania aktorów to przykłady małych kroków w tym kierunku. Jesteśmy pewni, że pojawi się więcej innowacji, aby ułatwić podejście mikrousług.