1.1 Architektura aplikacji
Ten kurs jest przeznaczony dla początkujących, ponieważ nie będziesz długo projektować architektury poważnej aplikacji. Ale nie martw się, dobra architektura to raczej wyjątek niż reguła. Bardzo trudno jest wybrać odpowiednią architekturę aplikacji przed zbudowaniem aplikacji.
Przykłady popularnych architektur dla dużych aplikacji serwerowych:
- Architektura warstwowa (Architektura warstwowa).
- Architektura warstwowa.
- Architektura zorientowana na usługi (SOA).
- Architektura mikrousług (Microservice Architecture).
Każdy z nich ma swoje wady i zalety. Ale studiowanie ich nic ci nie da. Architektura jest odpowiedzią na pytanie „jak zorganizować interakcję tysięcy obiektów w systemie” . I dopóki nie doświadczysz pełnej złożoności problemu, nie będziesz w stanie zrozumieć pełnej wszechstronności rozwiązania.
Wszystkie aplikacje używają jakiejś architektury lub przynajmniej udają, że tak jest. Dlatego znajomość popularnych podejść do projektowania aplikacji pozwoli Ci szybko i lepiej zrozumieć, jak działa aplikacja. A to oznacza wprowadzanie zmian dokładnie tam, gdzie ich potrzebujesz.
Co oznacza „wprowadź zmiany tam, gdzie to konieczne”? Czy są miejsca, w których nie musisz wprowadzać zmian? Dokładnie.
Mówiąc konkretnie, załóżmy, że pracujesz nad średnim projektem backendowym . Jest pisany przez 5 lat przez 20-osobowy zespół. Projekt zajął 100 osobolat i zawiera około 100 tysięcy linii kodu. W sumie składa się z dwóch tysięcy zajęć, które podzielone są na 10 modułów o różnej wielkości.
I dodaj surową rzeczywistość. Logika niektórych zadań rozłożona jest na kilka modułów. Ponadto logika biznesowa może znajdować się w interfejsie (napisanym w JavaScript) i/lub zapisana jako procedura składowana bezpośrednio w bazie danych. Czy nadal jesteś pewien, że możesz od razu określić miejsce, w którym dokładnie dokonasz zmian ?
To nie jest jakiś koszmar, który wymyśliłem, żeby cię przestraszyć. To typowy projekt. Zdarza się jeszcze gorzej. Dlaczego to się dzieje? Przyczyn może być wiele, ale prawie zawsze są takie:
- Nad projektem pracuje bardzo dużo osób - każdy widzi to trochę inaczej.
- Przez 5 lat w projekcie zmieniło się 10 osób, nowicjusze niewiele z tego rozumieli.
- Tworzenie oprogramowania to ciągłe dokonywanie zmian, które nieustannie zmieniają wszystko.
- Pięć lat temu, kiedy decydowaliśmy się na architekturę, idea projektu była nieco inna.
Ale najważniejsze jest to, że niezależnie od architektury projektu, wszyscy pracujący nad nim programiści trzymali się tego samego zrozumienia, jak ten projekt działa. Zacznijmy od najprostszej koncepcji - architektury klient-serwer.
1.2 Koncepcja interakcji klient-serwer
Teraz zrozumiemy koncepcję leżącą u podstaw architektury klient-serwer i pozwolimy lepiej zrozumieć, jak zorganizowana jest interakcja milionów programów w Internecie.
Jak sama nazwa wskazuje, ta koncepcja obejmuje dwie strony: klienta i serwer . Tutaj wszystko jest jak w życiu: klient jest klientem tej lub innej usługi, a serwer jest usługodawcą. Klient i serwer to fizycznie programy , na przykład typowym klientem jest przeglądarka .
Jako serwer można podać następujące przykłady:
- Serwery internetowe, takie jak Tomcat.
- Serwery baz danych, takie jak MySQL.
- Bramki płatnicze, takie jak Stripe.
Klient i serwer zazwyczaj komunikują się przez Internet (choć mogą pracować w tej samej sieci lokalnej i ogólnie w dowolnych innych typach sieci). Komunikacja odbywa się za pośrednictwem standardowych protokołów, takich jak HTTP, FTP lub protokołów niższego poziomu, takich jak TCP lub UDP.
Protokół jest zwykle wybierany zgodnie z rodzajem usługi świadczonej przez serwery. Na przykład, jeśli jest to połączenie wideo, zwykle używany jest protokół UDP.
Pamiętasz, jak działa Tomcat i jego serwlety? Serwer odbiera wiadomość HTTP, rozpakowuje ją, wydobywa z niej wszystkie niezbędne informacje i przekazuje ją do serwletu w celu przetworzenia. Następnie wynik przetwarzania jest ponownie pakowany w odpowiedź HTTP i wysyłany do klienta.
Jest to typowa interakcja klient-serwer. Przeglądarka jest klientem WWW, a Tomcat serwerem WWW. Tomcat jest nawet nazywany serwerem WWW.
Ale jeśli się nad tym zastanowić, to nie nazwa jest ważna, ale istota - podział ról między programami. Skrypt JS działający na stronie HTML mógłby równie dobrze być nazywany klientem , a serwlet serwerem . Pracują przecież w parach w ramach koncepcji klient-serwer .
1.3 Ważny niuans
Warto również zauważyć, że interakcja klient-serwer opiera się na zasadzie, że interakcję inicjuje klient : serwer jedynie odpowiada klientowi i zgłasza, czy może świadczyć usługę klientowi, a jeśli tak, to na jakich warunkach .
Nie ma znaczenia, gdzie fizycznie znajduje się klient i gdzie znajduje się serwer. Oprogramowanie klienta i oprogramowanie serwera są zwykle instalowane na różnych komputerach, ale mogą również działać na tym samym komputerze.
Koncepcja ta została opracowana jako pierwszy krok w kierunku uproszczenia złożonego systemu. Ona ma te mocne strony:
- Uproszczenie logiki : serwer nie wie nic o kliencie io tym, jak wykorzysta jego dane w przyszłości.
- Mogą istnieć słabi klienci : wszystkie zadania wymagające dużej ilości zasobów można przenieść na serwer.
- Samodzielne tworzenie kodu klienta i kodu serwera.
- Wiele różnych klientów, na przykład Tomcat i różne przeglądarki.
Najbardziej podstawową wersję interakcji klienta z serwerem przedstawia rysunek:
Warto tutaj zwrócić uwagę na dwa szczegóły. Po pierwsze, rysunek pokazuje, że wielu klientów może uzyskać dostęp do jednego serwera. Po drugie, mogą uzyskać do niego dostęp w tym samym czasie. Jest to również ważna część serwera.
Jeden klient zazwyczaj wchodzi w interakcję z jednym użytkownikiem, więc często nawet autoryzacja nie jest tam potrzebna. Jednak serwer przetwarza żądania od tysięcy klientów i tworząc dla niego kod, musisz umieć odróżnić autoryzację od uwierzytelnienia.
Ważne jest również, aby serwer przetwarzał równolegle tysiące żądań. A to oznacza, że podczas tworzenia kodu backendowego będziesz musiał stale myśleć o zadaniu współbieżnego dostępu do zasobów. Ponadto kod serwera ma bardzo duże prawdopodobieństwo wyścigu (wyścig wątków), zakleszczenia (wzajemne blokowanie wątków).
Cykl życia ważnych obiektów musi być monitorowany:
Nie możesz po prostu rozpocząć nowego wątku na serwerze przez new Thread().start(). Zamiast tego musisz mieć pulę wątków, która będzie współużytkowana przez wszystkie wątki usługi.
Ponadto nie możesz po prostu uruchomić zadania asynchronicznego, ponieważ są one również wykonywane w osobnych wątkach. Tworząc takie zadanie, zawsze powinieneś wiedzieć, która pula wątków je wykonuje i co się stanie, jeśli taka pula się przepełni.
Cała praca z plikami i katalogami musi być wykonywana za pomocą try-with-resources. Jeśli w normalnej aplikacji zapomniałeś zamknąć strumień lub plik, czy to problem? Zamknie się po wyjściu z programu. Ale jeśli gdzieś w kodzie zapomniałeś zamknąć plik na serwerze, a twój serwer działa od miesięcy ... Wkrótce zgromadzą się tysiące takich niezamkniętych plików, a system operacyjny przestanie otwierać nowe pliki do odczytu (praca z plikami jest kontrolowany przez system operacyjny). Teamlead nie pogłaszcze cię po głowie...
1.4 Architektura klient-serwer
kolejny ważny punkt. Architektura klient-serwer definiuje jedynie ogólne zasady interakcji między komputerami , szczegóły interakcji określają różne protokoły.
Ta koncepcja (klient-serwer) mówi nam, że musimy podzielić maszyny w sieci na maszyny klienckie, które zawsze czegoś potrzebują, oraz serwery, które dają to, czego potrzebują. W takim przypadku klient zawsze rozpoczyna interakcję, a zasady, według których zachodzi interakcja, są opisane w protokole.
Istnieją dwa rodzaje architektury interakcji klient-serwer: pierwszy nazywany jest dwuwarstwową architekturą klient-serwer , drugi to wielowarstwowa architektura klient-serwer (czasami nazywana architekturą trójwarstwową lub architekturą trójwarstwową, ale to jest przypadek szczególny).
Zasada działania dwuwarstwowej architektury interakcji klient-serwer polega na tym, że przetwarzanie żądania odbywa się na jednym serwerze bez odwoływania się w procesie tego przetwarzania do innych serwerów.
Dwupoziomowy model interakcji klient-serwer można narysować jako prosty diagram.
Tutaj widać, że pierwszy poziom to wszystko, co dotyczy klienta, a drugi poziom to wszystko, co dotyczy serwera.