Gdy aplikacja ma obsłużyć sklep internetowy, panel firmowy albo system wewnętrzny, pierwsza decyzja architektoniczna często wpływa na lata dalszego rozwoju. Architektura monolityczna pozwala zbudować taki system jako jedną wdrażaną całość, ale wymaga świadomego podejścia do zależności, modułów i bazy danych. Wyjaśniam, jak działa ten model, kiedy daje przewagę, gdzie zaczyna ograniczać zespół oraz jak zaprojektować go rozsądnie w środowisku .NET i Azure.
Monolit jest prosty we wdrożeniu, ale wymaga porządku w środku
- Jedna aplikacja zawiera większość funkcji biznesowych i jest wdrażana jako spójny system.
- Największa zaleta to prostszy rozwój, testowanie, uruchamianie i monitorowanie na początku projektu.
- Największe ryzyko pojawia się wtedy, gdy moduły mają niekontrolowane zależności i wspólną bazę danych bez jasno określonych granic.
- Monolit modularny pozwala zachować jedno wdrożenie, jednocześnie porządkując kod według obszarów biznesowych.
- Mikroserwisy nie są automatycznym ulepszeniem. Opłacają się dopiero wtedy, gdy system i organizacja rzeczywiście potrzebują niezależnego skalowania lub wdrażania.
Czym naprawdę jest monolit w aplikacji
W monolicie interfejs użytkownika, logika biznesowa, obsługa danych i integracje tworzą jeden logiczny system. Najczęściej buduje się go jako jedną aplikację uruchamianą w jednym procesie albo jako jeden pakiet wdrożeniowy, nawet jeśli wewnątrz rozwiązania znajduje się kilka projektów.To ważne rozróżnienie, bo monolit nie musi oznaczać jednego pliku z całym kodem. Aplikacja ASP.NET Core może mieć osobne projekty dla domeny, infrastruktury, API i testów, a mimo to nadal być monolitem, jeśli wszystkie elementy są wdrażane razem i działają jako jedna całość.
Jak wygląda przepływ żądania
Przykładowe żądanie złożenia zamówienia trafia do aplikacji, która w ramach jednego wdrożenia sprawdza koszyk, nalicza rabat, zapisuje zamówienie, aktualizuje stan magazynowy i wywołuje integrację z płatnościami. Komunikacja między tymi elementami odbywa się zwykle przez wywołania metod, wspólne modele albo bezpośredni dostęp do tej samej bazy danych.
Taki przepływ jest szybki do zrozumienia i debugowania. Jeżeli transakcja obejmuje kilka operacji, można często obsłużyć ją w ramach jednej transakcji bazodanowej, bez projektowania komunikacji asynchronicznej, mechanizmów ponawiania i obsługi częściowych awarii.
Monolit nie oznacza automatycznie złej architektury
W dyskusjach technicznych słowo „monolit” bywa używane jak synonim starego i trudnego w utrzymaniu systemu. To zbyt duże uproszczenie. Problemem nie jest samo jedno wdrożenie, lecz brak granic między odpowiedzialnościami, przypadkowe zależności i rosnąca liczba wyjątków dokładanych bez planu.
Dobrze zaprojektowany monolit może działać przez wiele lat, obsługiwać duży ruch i rozwijać się szybciej niż system podzielony na kilkanaście usług. Z mojego punktu widzenia etykieta architektury ma mniejsze znaczenie niż to, czy zespół potrafi szybko zmienić kod bez obawy, że każda poprawka uruchomi lawinę nieprzewidzianych skutków.
Dlaczego pojedyncza aplikacja często wygrywa na początku
Największą siłą tego podejścia jest niski koszt organizacyjny. Zespół nie musi od razu zarządzać rejestrem usług, konfiguracją sieci, wersjonowaniem kontraktów, kolejkami komunikatów i osobnymi potokami wdrożeniowymi. Dzięki temu można skupić się na sprawdzeniu modelu biznesowego, zamiast budować skomplikowaną platformę techniczną.
Szybszy start i prostsze wdrożenia
W aplikacji .NET wdrożenie może oznaczać opublikowanie jednego obrazu kontenera albo jednej aplikacji App Service. Pipeline CI/CD, czyli automatyczny proces budowania, testowania i wdrażania, jest zwykle łatwiejszy do utrzymania, ponieważ ma mniej niezależnych elementów.
Ma to znaczenie szczególnie w małym zespole. Jeżeli nad produktem pracują 2-6 osób, rozdzielenie systemu na wiele usług często zwiększa liczbę zadań operacyjnych szybciej niż wartość biznesową. Mniej komponentów oznacza mniej miejsc, w których może wystąpić awaria i mniej konfiguracji do odtworzenia podczas lokalnego uruchamiania.
Łatwiejsze testowanie i spójność danych
W monolicie test end-to-end może przejść przez cały proces biznesowy bez uruchamiania kilku niezależnych serwisów. Integracja modułów jest też prostsza, gdy wszystkie korzystają z jednego modelu uwierzytelniania, wspólnego logowania i tej samej transakcji.
Nie oznacza to, że każda operacja powinna używać jednej ogromnej transakcji. Oznacza jednak, że projektant może zacząć od prostszego modelu i wprowadzać asynchroniczność dopiero tam, gdzie faktycznie jest potrzebna. To podejście ogranicza ryzyko przedwczesnego komplikowania systemu.
Prostsze skalowanie poziome
Jeśli aplikacja jest bezstanowa, można uruchomić kilka jej kopii za load balancerem. W Azure może to być kilka instancji App Service, kontenerów albo replik aplikacji działających za usługą równoważącą ruch. Każda instancja obsługuje cały system, więc skalowanie nie wymaga najpierw rozstrzygania, które usługi powinny dostać więcej zasobów.
Minusem jest mniejsza precyzja. Gdy tylko moduł raportów zużywa dużo procesora, często trzeba skalować całą aplikację, nawet jeśli moduł zamówień działa bez problemów. Przy umiarkowanym ruchu nie jest to jednak wada, która sama w sobie uzasadnia migrację do mikroserwisów.
Gdzie monolit zaczyna ograniczać rozwój
Trudności pojawiają się zwykle stopniowo. Najpierw niewielka zmiana wymaga modyfikacji kilku projektów, później wdrożenie funkcji zajmuje więcej czasu, a na końcu zespół boi się dotykać fragmentów systemu, których nie rozumie. To sygnał, że problemem stała się złożoność wewnętrzna, a nie sam fakt posiadania jednej aplikacji.
Silne sprzężenie między modułami
Sprzężenie oznacza, że zmiana w jednym miejscu wymusza zmiany w wielu innych. Przykładem może być wspólny model klienta używany jednocześnie przez sprzedaż, faktury, powiadomienia i raporty. Dodanie jednego pola albo zmiana reguły walidacji może wtedy wymagać przebudowy całego rozwiązania.
W praktyce szczególnie niebezpieczne są bezpośrednie odwołania do tabel należących logicznie do innego modułu. Kod działa, ale granice domeny znikają. Po kilku latach nie wiadomo już, który fragment odpowiada za daną regułę, a każda refaktoryzacja przypomina porządkowanie kabli za biurkiem bez wyłączania prądu.
Wspólne wdrażanie i wspólna awaria
Jedna aplikacja zwykle oznacza jeden proces wdrożeniowy. Nawet mała poprawka w module administracyjnym może wymagać opublikowania całego systemu, przeprowadzenia pełnych testów regresji i zaplanowania okna wdrożeniowego.
Podobnie działa awaria. Błąd w generowaniu raportu może zużyć zasoby potrzebne modułowi zamówień, ponieważ oba działają w tym samym środowisku. Można ograniczać takie skutki przez limity, kolejki, osobne procesy robocze i izolację zasobów, ale wtedy monolit zaczyna korzystać z części wzorców znanych z systemów rozproszonych.
Wspólna baza nie rozwiązuje wszystkich problemów
Jedna baza danych upraszcza transakcje i raportowanie, lecz z czasem może stać się centralnym punktem zależności. Schemat jest wtedy współdzielony przez wiele części aplikacji, a zmiana tabeli wymaga koordynacji większej liczby osób.
Nie próbowałbym rozdzielać bazy tylko dlatego, że system ma już kilka modułów. Najpierw uporządkowałbym własność danych, dostęp przez interfejsy aplikacyjne i migracje schematu. Podział techniczny bez podziału odpowiedzialności daje głównie więcej konfiguracji, a nie prawdziwą niezależność.Klasyczny monolit, monolit modularny i mikroserwisy
Te trzy podejścia często trafiają do jednej dyskusji, choć rozwiązują różne problemy. Klasyczny monolit stawia na prostotę wdrożenia, monolit modularny dodaje rygor wewnętrzny, a mikroserwisy rozdzielają system na niezależnie wdrażane części.
| Cecha | Klasyczny monolit | Monolit modularny | Mikroserwisy |
|---|---|---|---|
| Wdrożenie | Jedno | Jedno | Wiele niezależnych |
| Granice kodu | Często słabe | Wyraźne moduły | Granice usług i kontraktów |
| Baza danych | Zwykle wspólna | Może być wspólna, ale z własnością danych modułów | Najczęściej osobna dla usługi |
| Skalowanie | Całej aplikacji | Całej aplikacji lub wybranych procesów | Niezależne dla usług |
| Koszt operacyjny | Niski | Umiarkowany | Wysoki |
| Najlepsze zastosowanie | Małe i średnie systemy | Większe systemy z planowanym rozwojem | Duże organizacje i niezależne domeny |
Monolit modularny jako rozsądny kompromis
W takim układzie aplikacja nadal jest jednym wdrażanym artefaktem, ale jej kod dzieli się według obszarów biznesowych, na przykład Zamówienia, Płatności, Magazyn i Tożsamość. Moduły komunikują się przez jasno określone interfejsy, a nie przez dowolne odwołania do klas i tabel.
W .NET można zacząć od osobnych projektów, przestrzeni nazw, wewnętrznych kontraktów i testów architektonicznych. Przydatne jest także ograniczenie widoczności klas oraz pilnowanie, aby moduł nie pobierał danych bezpośrednio z tabel innego modułu. Największą wartość daje dyscyplina granic, nie sama liczba projektów w pliku rozwiązania.
Kiedy mikroserwisy faktycznie mają sens
Mikroserwisy rozważam wtedy, gdy istnieje konkretna przyczyna niezależnego wdrażania lub skalowania. Może nią być bardzo różne obciążenie poszczególnych funkcji, niezależne zespoły odpowiedzialne za domeny, wymaganie użycia różnych technologii albo potrzeba odizolowania awarii.
Sama popularność mikroserwisów nie jest wystarczającym argumentem. Każda usługa dodaje własne logi, metryki, konfigurację, monitoring, testy kontraktowe, wersjonowanie i obsługę błędów sieciowych. Zyskujemy niezależność, ale płacimy za nią złożonością operacyjną, której nie widać na diagramie z kilkoma prostokątami.
Jak zaprojektować zdrowy monolit w .NET
Rozsądny projekt zaczyna się od podziału według odpowiedzialności biznesowych, a nie od automatycznego układania katalogów na warstwy. Warstwy techniczne nadal są potrzebne, lecz nie powinny sprawić, że kod zamówień, użytkowników i raportów zostanie wymieszany tylko dlatego, że wszystkie klasy serwisowe trafiły do jednego folderu.
Podziel rozwiązanie według domeny
Przykładowa struktura może wyglądać tak:
- Orders odpowiada za koszyk, zamówienia i ich statusy.
- Payments obsługuje płatności oraz komunikację z operatorem.
- Inventory zarządza stanami magazynowymi i rezerwacjami.
- Identity przechowuje reguły użytkowników i uprawnień.
- Notifications wysyła wiadomości, ale nie definiuje reguł zamówień.
Każdy moduł powinien mieć własne modele wejściowe, reguły i przypadki użycia. Jeśli dwa moduły potrzebują tej samej informacji, lepiej przekazać prosty kontrakt albo opublikować zdarzenie domenowe niż udostępniać cały model encji.
Ustal zasady komunikacji
W prostym monolicie moduły mogą komunikować się przez interfejsy aplikacyjne i synchroniczne wywołania. Gdy operacja nie musi zakończyć się przed odpowiedzią dla użytkownika, można użyć zdarzenia i kolejki, na przykład Azure Service Bus, aby odłączyć wysyłanie powiadomienia od głównej transakcji.Nie przenosiłbym jednak każdej funkcji do kolejki. Asynchroniczność oznacza opóźnienia, ponowienia, możliwość duplikacji komunikatu i trudniejsze diagnozowanie. Stosuję ją tam, gdzie użytkownik nie musi natychmiast otrzymać rezultatu albo gdzie obciążenie rzeczywiście uzasadnia odseparowanie pracy.
Zadbaj o obserwowalność i granice wdrożenia
Jedno wdrożenie nie zwalnia z monitorowania poszczególnych obszarów. Logi strukturalne, metryki czasu odpowiedzi, śledzenie korelacji żądań i alerty dla kluczowych operacji pokazują, który moduł powoduje problem, nawet jeśli wszystkie działają w jednym procesie.
Warto też mierzyć czas budowania, testów i wdrożeń. Jeżeli pipeline regularnie trwa 30-40 minut, a każda zmiana wymaga pełnej ręcznej weryfikacji, to sygnał do poprawy automatyzacji. Nie musi od razu oznaczać migracji do mikroserwisów.
Przeczytaj również: SRP w C# - co oznacza zasada jednej odpowiedzialności?
Przygotuj się na ewentualny podział
Jeśli istnieje prawdopodobieństwo późniejszego wydzielenia usługi, projektuj moduł tak, aby miał własność danych, ograniczoną liczbę zależności i stabilny kontrakt. Nie buduj jednak sztucznej granicy sieciowej przed potwierdzeniem potrzeby.
Najbezpieczniejsza ścieżka zwykle prowadzi przez stopniowe wydzielanie jednego obszaru, na przykład powiadomień albo wyszukiwania. Najpierw trzeba odłączyć kod i dane, później wprowadzić komunikację, a dopiero na końcu uruchomić osobny proces. Samo przeniesienie klas do nowego repozytorium nie tworzy mikroserwisu.
Monolit ma sens, gdy kontrolujesz jego granice
Wybrałbym pojedynczą aplikację dla nowego produktu, gdy domena nie jest jeszcze dobrze poznana, zespół jest niewielki, a najważniejsza jest szybka nauka i dostarczanie funkcji. W takiej sytuacji prostsze wdrożenie i spójne dane zwykle dają więcej niż niezależne skalowanie kilku usług.
Postawiłbym na monolit modularny, gdy system rośnie, zespoły zaczynają pracować nad różnymi obszarami, ale nadal nie ma wyraźnej potrzeby rozdzielania infrastruktury. To często najlepszy środek między chaotycznym wspólnym kodem a kosztowną architekturą rozproszoną.
Mikroserwisy zostawiłbym dla sytuacji, w których ich korzyść można opisać konkretnym wymaganiem, a nie modą technologiczną. Dobra architektura nie polega na maksymalnej liczbie usług, tylko na takim podziale systemu, który ułatwia zmiany, ogranicza ryzyko i pasuje do możliwości zespołu.
