Ograniczenia wydajności aplikacji monolitycznej
Istnieje wiele powodów, dla których można zmienić architekturę systemu. Elastyczność operacyjna, koszt, skalowalność i wydajność to tylko niektóre czynniki, które odgrywają rolę w określaniu architektury systemu. W naszym przykładzie przyjrzymy się bliżej, jak efektywność staje się czynnikiem dla systemu dostarczania przez drony.
Wraz z rozwojem firmy Fabrikam w zakresie dostarczania dronów zwiększa się obciążenie systemu. Obecna architektura jest przeciążona. Fabrikam chce zapewnić lepszą elastyczność skalowania aplikacji, która nie jest dostępna w bieżącej architekturze monolitycznej. Zwiększenie skalowalności aplikacji jest jednym z powodów, dla których firma Fabrikam rozważa przeniesienie swojej aplikacji do architektury mikrousług.
Skalowanie monolitu kontra mikrousługi
Jedną z podstawowych zalet architektury mikrousług jest zwiększenie możliwości skalowania. Ponieważ usługi są oddzielone, łatwiej jest skalować każdą usługę indywidualnie w miarę wzrostu obciążenia.
Widzimy tę różnicę w możliwościach systemu dostarczania dronów. W architekturze monolitycznej wszystkie usługi są zawarte w jednym wystąpieniu aplikacji. Uwidaczniają interfejs API klientom w celu przesyłania żądań dostarczania i zarządzania nimi. W miarę zwiększania się żądań klientów obciążenie systemu wzrasta. Aby uniknąć negatywnego wpływu na środowisko użytkownika, należy przydzielić do systemu więcej zasobów.
W architekturze monolitycznej skalowanie tej usługi osobno wymaga również skalowania zasobów dla innych usług, ponieważ są one zawarte w każdym wystąpieniu aplikacji. Ten układ jest nieefektywny, ponieważ obciążenie innych usług może być minimalne i nie wymaga dodatkowego wykorzystania zasobów.
W architekturze mikrousług, ponieważ każda usługa jest oddzielna, możemy skalować interfejs API niezależnie od innych usług. To rozwiązanie zwiększa wydajność, ponieważ nie musimy korzystać z zasobów niepotrzebnych usług.
Wyzwania związane z architekturą monolityczną dostaw dronami
Usługa pakietu została zidentyfikowana jako krytyczna część firmy i była pierwotnie częścią monolitu. Klienci znacznie zwiększają ich zależność od niej, a wydajność ma negatywny wpływ na wzrost obciążenia. Aby rozwiązać ten problem, firma Fabrikam poświęciła zespołowi programistycznemu pełną kontrolę nad tym elementem działalności. Zespół planuje opracowywać i iterować tę usługę i odpowiadać wyłącznie za wszystkie aspekty usługi pakietu.
Ponieważ serwis paczkowy znajduje się w monolicie, zespół nie może działać autonomicznie. Muszą polegać na udostępnionych danych i strukturach danych. Nie są one również w stanie iterować tak szybko, jakby chcieli. Wraz z problemami z wydajnością i skalowalnością ta usługa jest identyfikowana jako główny kandydat na mikrousługę.
Przyjrzyjmy się bliżej temu, jak firma Fabrikam może analizować i rozkładać swoją aplikację, aby korzystać z architektury mikrousług.