Architektura mikrousług w kontekście orkiestracji kontenerów
Źródło: Dereckson, CC0, Wikimedia Commons
Spis treści
Podział na niezależne usługi
Architektura mikrousług zakłada podział aplikacji na niezależnie wdrażane i skalowane komponenty, z których każdy odpowiada za określony fragment funkcjonalności biznesowej. W przeciwieństwie do architektury monolitycznej, poszczególne usługi mogą być rozwijane, testowane i wdrażane niezależnie od siebie, co bezpośrednio wpływa na wymagania stawiane infrastrukturze wdrożeniowej.
Komunikacja między usługami
Ponieważ mikrousługi działają jako odrębne procesy, komunikują się ze sobą za pośrednictwem sieci — najczęściej z wykorzystaniem protokołów HTTP lub gRPC, a także asynchronicznych kolejek komunikatów. Zarządzanie tą komunikacją, w tym trasowaniem ruchu i obsługą awarii, staje się istotnym elementem projektowania architektury wraz ze wzrostem liczby usług — zagadnienie to opisano szerzej w artykule Service mesh a tradycyjne trasowanie ruchu.
Wymagania stawiane platformie orkiestracji
Duża liczba niezależnie wdrażanych usług generuje potrzebę zautomatyzowanego zarządzania ich rozmieszczeniem, skalowaniem i odzyskiwaniem sprawności po awarii — funkcje te realizowane są przez platformy orkiestracji kontenerów, takie jak Kubernetes, opisany w artykule Czym jest Kubernetes. Im większa liczba usług w systemie, tym istotniejsza staje się rola automatyzacji tych procesów.
Wybór odpowiedniego modelu wdrożenia — chmury publicznej, prywatnej lub hybrydowej — również wpływa na sposób, w jaki architektura mikrousług jest realizowana w praktyce, co opisano w artykule Modele wdrożeń chmurowych a wybór platformy orkiestracji.