Wprowadzenie do architektury trójwarstwowej
Architektura trójwarstwowa jest najpowszechniejszą architekturą interakcji w Internecie. Pojawił się, gdy dwupoziomowa część serwerowa została podzielona na dwie części: warstwę logiczną i warstwę danych .
Wyglądało to mniej więcej tak:

Warstwa klienta to część „aplikacji rozproszonej” odpowiedzialna za interakcję użytkownika. Ta warstwa nie powinna zawierać logiki biznesowej i nie powinna przechowywać krytycznych danych. Nie powinien też wchodzić w bezpośrednią interakcję z warstwą bazy danych, a jedynie poprzez warstwę logiki biznesowej.
Jednak nadal jest tu pewna logika. Po pierwsze jest to interakcja z użytkownikiem poprzez interfejs, walidacja wprowadzonych przez niego danych, praca z plikami lokalnymi. Obejmuje to również wszystko, co dotyczy autoryzacji użytkownika i szyfrowania danych podczas pracy z serwerem.
Po drugie, jest to prosta logika biznesowa. Na przykład, jeśli sklep internetowy przesłał listę produktów, możemy je posortować i przefiltrować po stronie klienta. Istnieje również prymitywne przechowywanie danych: buforowanie, pliki cookie zalogowanego użytkownika i tym podobne.
Warstwa logiki biznesowej znajduje się na drugim poziomie, na niej skoncentrowana jest większość logiki biznesowej. Poza nią pozostają tylko fragmenty, które są eksportowane do klienta, a także elementy logiczne, które są zanurzone w bazie danych (procedury składowane i wyzwalacze).
Sama część serwera logiki biznesowej zawiera nie tylko tę samą logikę, ale także rozwiązuje problemy skalowania: kod jest dzielony na części i dystrybuowany do różnych serwerów. Niektóre bardzo pożądane usługi mogą działać na dziesiątkach serwerów. Obciążeniem między nimi zarządza system równoważenia obciążenia.
Aplikacje serwerowe są zwykle projektowane w taki sposób, aby można było łatwo uruchomić kolejną kopię serwera i rozpocząć współpracę z innymi jego kopiami. Oznacza to, że nawet w trakcie pisania kodu serwera nigdy nie będziesz mieć gwarancji, że Twoja klasa statyczna zostanie uruchomiona w jednej instancji.
Warstwa danych zapewnia przechowywanie danych i jest umieszczona na osobnym poziomie, realizowanym z reguły za pomocą systemów zarządzania bazami danych (DBMS), połączenie z tym komponentem odbywa się tylko z poziomu serwera aplikacji.
Powody wydzielenia warstwy danych
Wydzielenie warstwy danych na pełnoprawną trzecią warstwę nastąpiło z wielu powodów, ale głównym z nich jest zwiększone obciążenie serwera.
Po pierwsze, bazy danych zaczęły wymagać dużo pamięci i czasu procesora do przetwarzania danych. Dlatego zaczęto je umieszczać wszędzie na osobnych serwerach.
Przy zwiększonym obciążeniu można było łatwo zduplikować backend i stworzyć dziesięć kopii jednego serwera, ale niemożliwe było zduplikowanie bazy danych - baza danych nadal pozostawała pojedynczym i niepodzielnym elementem systemu.
Po drugie, bazy danych stały się inteligentne – mają własną logikę biznesową. Zaczęli wspierać procedury składowane, wyzwalacze, własne języki takie jak PLSQL. Pojawili się nawet programiści, którzy zaczęli pisać kod działający w DBMS.
Cała logika, która nie była powiązana z danymi, została przeniesiona do zaplecza i uruchomiona równolegle na dziesiątkach serwerów. Wszystko, co było krytycznie powiązane z danymi, pozostało w DBMS i już tam problemy zwiększonego obciążenia musiały zostać rozwiązane własnymi metodami:
- Klaster bazy danych to grupa serwerów baz danych, które przechowują te same dane i synchronizują je przy użyciu określonego protokołu.
- Sharding — dane są dzielone na logiczne bloki i dystrybuowane na różnych serwerach baz danych. Przy takim podejściu bardzo trudno jest utrzymać zmiany w bazie danych.
- Podejście NoSQL polega na przechowywaniu danych w bazach danych zbudowanych do przechowywania ogromnych ilości danych. Często nie są to nawet bazy danych, ale konkretne magazyny plików. Bardzo słaba funkcjonalność w porównaniu do relacyjnych baz danych.
- Buforowanie danych. Zamiast prostej pamięci podręcznej na poziomie bazy danych pojawił się cały buforujący DBMS, który przechowywał wynik tylko w pamięci.
Oczywiste jest, że do zarządzania tym zoo technologii serwerowych potrzebne były osobne osoby i/lub całe zespoły, co doprowadziło do usunięcia warstwy danych do osobnej warstwy.
Ważny! Wszystkie zaawansowane technologie rodzą się w czeluściach wielkich korporacji IT, kiedy stare podejścia nie radzą sobie już z nowymi wyzwaniami. Tworzenie baz danych w osobnej warstwie nie zostało wymyślone przez żadnego programistę, ale przez grupę inżynierów gdzieś w czeluściach Oracle czy IBM.
Ciekawy! Kiedy Zuckerberg zaczął pisać Facebooka, pracował po prostu nad PHP + MySQL. Kiedy były miliony użytkowników, napisali specjalny translator, który przetłumaczył cały kod PHP na C++ i skompilował go do natywnego kodu maszynowego.
Ponadto MySQL nie jest w stanie przechowywać danych miliardów użytkowników, dlatego Facebook opracował koncepcję baz danych NoSQL i napisał potężny serwerowy system NoSQL DBMS – Cassandra. Nawiasem mówiąc, jest w całości napisany w Javie.
Niejednoznaczność lokalizacji logiki aplikacji
I choć trójwarstwowa architektura niemal jednoznacznie rozdziela role między swoje części, to nie zawsze jest możliwe dokładne określenie, w którym miejscu w systemie należy dodać nową część logiki biznesowej (nowy kod).
Przykład takiej niejednoznaczności pokazano na poniższym obrazku:

Część serwerowa jest wypełniona szarym tłem, część kliencka jest wypełniona bielą. Dobrym przykładem tego drugiego podejścia (z prawej strony) są nowoczesne aplikacje mobilne. Strona klienta (w telefonie) zawiera widok (wyświetlacz), logikę i dane. I tylko czasami te dane są synchronizowane z serwerem.
Przykładem skrajnej lewej opcji jest typowy serwer PHP, który ma całą logikę na serwerze i daje klientowi już statyczny HTML. Gdzieś pomiędzy tymi dwoma skrajnościami Twój projekt będzie zlokalizowany.
Na początku pracy, po zapoznaniu się z projektem, będziesz musiał skonsultować się z pracującymi nad nim programistami, w których miejscach lepiej jest dla Ciebie zaimplementować logikę kolejnego zadania.
Możesz to zrobić. Po pierwsze, ze swoim statutem nie wchodzą do czyjegoś klasztoru. Po drugie, każdemu (i Tobie też) łatwiej będzie znaleźć potrzebny kod w miejscu, w którym spodziewasz się go znaleźć.
GO TO FULL VERSION