Mikroserwisy

Mikroserwisy, architektura mikroserwisów – styl tworzenia architektury aplikacji komputerowych implementujący wzorzec architektury zorientowanej na usługi, który aranżuje aplikację jako zbiór luźno połączonych ze sobą niewielkich serwisów komunikujących się poprzez lekkie protokoły komunikacyjne. Celem jest zapewnienie niezależności poszczególnych komponentów, które mogą być rozwijane niezależnie od pozostałych elementów składowych systemu oraz wyraźny podział komponentów tak, by realizowały jedną, konkretną logikę biznesową lub programową.

Historia

Dokładna data powstania koncepcji mikroserwisów nie jest znana. Jednym z jej prekursorów był wiceprezes ThoughtWorks Fred George, który w 2004 roku rozpoczął prace nad prototypową architekturą bazującą na zasadach sformułowanych przez Jeffa Baya^[1].

Silny wpływ na tworzenie nowej architektury miały prace Petera Rodgersa, które rozpoczęły się w 1999 roku w ramach projektu „Dexter” prowadzonego w laboratoriach firmy Hewlett-Packard. Celem było utwardzenie kodu i opracowanie rozwiązań, które uodporniłyby duże systemy informatyczne na negatywne efekty zachodzących w nich zmian^[2]. Na początku 2005 podczas konferencji Web Services Edge Rodgers wprowadził termin „mikro-web-serwis”, sugerując, że poszczególne komponenty oprogramowania są jak mikrousługi sieciowe^[3].

W 2007 roku Juval Löwy w swojej książce^[4] i wypowiedziach^[5][6] wezwał do tworzenia systemów, w których każda klasa byłaby serwisem. Ponieważ wymagało to technologii wspierającej tworzenie tak granularnych serwisów, rozszerzył on framework Windows Communication Foundation w taki sposób, by wspierał on traktowanie klas jak serwisów przy zachowaniu standardowego modelu obiektowego^[7][8].

Podczas warsztatów dla architektów oprogramowania prowadzonych w pobliżu Wenecji w maju 2011 roku użyto terminu „mikroserwis” do opisu tego stylu architektonicznego^[9], a rok później określenie to zostało przyjęte jako najbardziej trafne. James Lewis przedstawił część tych pomysłów jako studium przypadku podczas konferencji 33rd Degree w Krakowie w marcu 2012 roku^[10].

Charakterystyka

Mikroserwisem nazywamy część większej aplikacji – komponent, proces lub usługę – dostarczający określoną funkcję w sposób całkowicie niezależny od pozostałych składowych systemu, dzięki czemu może być on rozwijany, wdrażany i utrzymywany w sposób autonomiczny^[11]. Wbrew swojej nazwie taki byt nie musi być niewielkim elementem, gdyż jego zadanie jest ściśle powiązane z realizowaną funkcją biznesową, która jest dostarczana do pozostałych składowych systemu^[12]. Komunikacja pomiędzy poszczególnymi mikroserwisami odbywa się poprzez neutralne z punktu widzenia technologii protokoły, takie jak przykładowo HTTP^[13][14]. Pod względem strategii wpisują się one w wywodzący się z filozofii Unixa termin „rób jedną rzecz i rób ją dobrze”^[15].

Do zalet wynikających z architektury mikroserwisów zalicza się^[11][16]:

• skalowalność – poszczególne komponenty mogą być skalowane niezależnie od pozostałych;
• dowolność technologii – każdy element może być tworzony w technologii najlepiej odpowiadającej jego funkcjonalności, dodatkowo łatwiej jest kontrolować poziom długu technologicznego;
• modularność – małe komponenty pozwalają na łatwe wdrożenie i rozbudowę bez konieczności ingerencji w całą aplikację;
• stabilność – błąd w jednym obszarze jest łatwiejszy do zidentyfikowania i naprawienia, redukując ryzyko zatrzymania systemu.

Krytyka

Architektura mikroserwisów niesie ze sobą poważne konsekwencje względem procesu tworzenia i utrzymania oprogramowania. Duża liczba rozproszonych mikroserwisów komplikuje projekt i wymusza wprowadzenie systemu komunikacji zarówno pomiędzy poszczególnymi procesami, jak i pod względem obsługi wyjątków^[16]. Ponadto tworzenie znacznej liczby małych elementów jest czasochłonne, wymagając dodatkowo zarządzania infrastrukturą, na której będą one działać i się skalować^[11]. Testowanie takiego systemu wymaga złożonego podejścia i jest często mocno utrudnione ze względu na mnogość powiązanych usług^[16].

W porównaniu do systemów monolitycznych koszt komunikacji między kolejnymi serwisami jest znacznie wyższy od analogicznych wywołań w trakcie procesu ze względu na opóźnienia sieci i konieczność właściwego przetworzenia odpowiedzi^[17].

Alternatywnym rozwiązaniem dla architektury mikroserwisów jest modularny monolit. To podejście również posiada strukturę modułową, ale jednocześnie ma prostszą infrastrukturę. Dzięki temu, taki system jest łatwiejszy w testowaniu funkcji biznesowych czy w komunikacji technicznej. ^[18][19]

Przypisy