Lista kontrolna architektury oprogramowania zaplecza: jak zbudować produkt od podstaw

Budzisz się pewnego ranka, aby wypić filiżankę kawy i voila, nadeszła chwila Eureki. W końcu ustaliłeś swój model biznesowy i wszystko się ułożyło. Wiesz, że inwestorzy to pokochają i po prostu nie możesz się doczekać, aby zacząć budować produkt. Możesz skorzystać z pierwszej przewagi.

Te chwile są rzadkie, ale kiedy się zdarzają, musisz zacząć w odpowiednim momencie. Wszystko, czego potrzebujesz, to odpowiedni przewodnik, który pomoże Ci dowiedzieć się, co powinieneś, a czego nie powinieneś robić. To nie jest czas na eksperymenty, to czas na wykonanie. Teraz jest TWÓJ czas!

UWAGA - Poniższe informacje dotyczą tworzenia architektur oprogramowania od podstaw. Jeśli więc chcesz poznać szczegóły zastosowanych technologii, kontynuuj. W przeciwnym razie podziel się z tymi, którzy na pewno to pokochają: P

Skąd wziął się ten przewodnik

Sam pracowałem nad kilkoma produktami na wczesnym etapie i szczerze mówiąc popełniłem błędy. Zawsze chciałem mieć listę kontrolną do naśladowania podczas tworzenia produktu od podstaw.

Jest tak wiele rzeczy związanych z budowaniem architektury od podstaw, że całkowicie zapomnisz o niektórych elementach. I wrócą, aby cię ugryźć na późniejszych etapach cyklu produktu.

W końcu zdecydowałem się stworzyć tę listę kontrolną rzeczy, które powinieneś rozważyć przed naciśnięciem tego przycisku wdrażania po raz pierwszy.

Więc bez dalszego rozbudowywania, oto lista kontrolna, którą należy przejść, budując architekturę zaplecza dla produktu od podstaw.

Wybierz PRAWIDŁOWY język i framework (dla swojego projektu)

Wybór odpowiedniego języka i frameworka dla twojego produktu jest trudny i nie ma na to szczególnej srebrnej kuli. Moja rada jest taka, aby wybrać język, który najbardziej Ci odpowiada i znać zawiłości tego języka.

Powiedziawszy to, jest to rzadkie, ponieważ jest bardzo niewielu ludzi, którzy są ninja Javascript, Panterami Pythona lub jakimkolwiek dziwacznym imieniem.

Wybierz więc język, który ma naprawdę dobre wsparcie w branży, taki jak Javascript, Python, Java lub Go, aby wymienić tylko kilka. Możesz wybrać dowolny język, po prostu wybierz ten, który jest dla Ciebie najwygodniejszy.

I pamiętaj - budujesz MVP (Minimum Viable Product) i będziesz w trakcie tworzenia POC (Proof of Concept). Dlatego wypuść swój produkt tak szybko, jak to możliwe. Nie musisz tkwić w problemach, które mogą wynikać z nowego języka w mieście. Aby uniknąć tych problemów, wybierz szerzej używany, dobrze udokumentowany język.

Wreszcie, możesz skalować w późniejszym czasie. Jeśli jesteś na etapie tworzenia POC, po prostu zbuduj i zrób to. Ale jeśli tworzysz coś naprawdę konkretnego i istnieje język i struktura frameworka specjalnie do tego celu, zdecydowanie powinieneś wybrać tę technologię.

Ale w większości przypadków problemy, które próbujemy rozwiązać, można łatwo rozwiązać za pomocą dowolnego z wyżej wymienionych języków i ich odpowiednich frameworków. Po prostu wybierz jeden i uruchom swój produkt.

Dobry zasób, który pomoże Ci podjąć decyzję -

//content.techgig.com/top-5-programming-languages-for-backend-web-development/articleshow/67337449.cms

Implementuj mikrousługi uwierzytelniania i autoryzacji

Istnieje wiele sposobów uwierzytelnienia i autoryzacji użytkownika. Możesz wypróbować tokeny sesji, JWT (JSON Web Tokens) lub OAuth, żeby wymienić tylko kilka. Każda opcja ma swoje zalety i wady. Przyjrzyjmy się więc bliżej niektórym z nich.

Tokeny sieciowe JSON

JWT są szybkie i łatwe do wdrożenia. Dzieje się tak, ponieważ tokeny nigdy nie są przechowywane w systemie. Są po prostu kodowane, szyfrowane i wysyłane do użytkownika. Zatem walidacja tokena JWT jest szybsza niż jakakolwiek inna metoda.

Ale ponieważ nie są one przechowywane w systemie, nie można tak naprawdę sprawić, aby token wygasł przed faktycznym czasem wygaśnięcia, co może stanowić problem w niektórych przypadkach.

Poznaj więc wady i zalety każdego systemu uwierzytelniania i wybierz ten, który najlepiej odpowiada Twoim wymaganiom. Osobiście wolę JWT (ale to mój własny wybór).

Upoważnienie

Nigdy nie zapomnij o wdrożeniu autoryzacji użytkowników. Nie chcesz, aby zalogowany Użytkownik 1 zmieniał dane Użytkownika 2. Może to spowodować czysty chaos w twoim systemie.

Zidentyfikuj punkty końcowe, które wymagają autoryzacji, i od razu je zaimplementuj. Nie chcesz, aby stan twojej bazy danych został uszkodzony w ten sposób. Zapamiętaj różnicę między 401 a 403.

Poniżej znajdują się pewne punkty końcowe, które zdecydowanie powinieneś wziąć pod uwagę podczas tworzenia systemu uwierzytelniania (utworzyłem go w Django przy użyciu JWT). Mogą istnieć pewne dodatki / usunięcia dla twojego przypadku użycia, ale to są te, które powinieneś rozważyć.

Wiele ram dostarcza je po wyjęciu z pudełka, ale rozważ je przed samodzielnym zbudowaniem. Aby uzyskać dalsze informacje, sprawdź authentication_classes i Permissions_classes w Django Rest Framework.

Spójrz na ten zasób Django REST Framework -

//www.django-rest-framework.org/tutorial/4-authentication-and-permissions/

Utwórz abstrakcyjny model podstawowy, który będzie dziedziczony przez każdy inny model w bazie danych

Pamiętaj o zasadzie DRY - nie powtarzaj się? Należy go przestrzegać do rdzenia w inżynierii oprogramowania.

Opierając się na powyższym procesie myślowym, w twojej bazie danych będą pewne kolumny, które będą obecne w każdej tabeli. Dlatego lepiej jest utworzyć dla nich klasę abstrakcyjną, aby inne klasy modeli mogły po nich dziedziczyć.

Przejdźmy przez ten kod i co to znaczy:

  • id - Chociaż nie jest tutaj napisane, jest automatycznie tworzone przez framework Django. Ale jeśli nie ma go w twoim, zapisz to w tej klasie. To po prostu pole automatycznie zwiększane, które może być używane jako klucz podstawowy w relacji z bazą danych.
  • created_at - Oznacza to, że pole / wiersz zostało wstawione do tabeli i zostało wypełnione przez samą strukturę. Nie musisz tego jawnie ustawiać.
  • updated_at - oznacza to, kiedy pole / wiersz zostało ostatnio zmodyfikowane / zaktualizowane w tabeli i ponownie jest wypełniane przez samą strukturę.
  • delete_at + is_deleted - Więc to jest kontrowersyjne pole. Nie mam dokładnej odpowiedzi, czy powinna tam być, czy nie - bo szczerze mówiąc, nic w internecie nigdy nie jest usuwane. To pole, jeśli jest wypełnione, oznacza, że ​​wiersz został usunięty z systemu (chociaż dane pozostają w systemie do przyszłych odniesień i można je pobrać z bazy danych i zapisać w kopiach zapasowych)
  • uuid - To zależy od tego, czy chcesz to umieścić w swojej tabeli, czy nie. Jeśli chcesz ujawnić klucz podstawowy swojej tabeli zewnętrznemu systemowi, lepiej ujawnić ten, a nie pole z automatycznie zwiększaną liczbą całkowitą. Możesz się zastanawiać, dlaczego ...? Cóż, dlaczego miałbyś chcieć powiedzieć zewnętrznemu systemowi, że masz 10378 zamówień w swoim stole? Ale znowu to osobisty wybór.

Skonfiguruj mikrousługę powiadomień

Każdy produkt musi wysyłać przypomnienia i powiadomienia do użytkownika w celu zaangażowania i transakcji. Więc każdy produkt będzie tego potrzebował.

Zdecydowanie powinieneś rozważyć utworzenie mikrousługi, która zapewnia usługi powiadomień (takie jak powiadomienia wypychane, wiadomości e-mail i SMS) dla użytkowników końcowych.

Powinna to być całkowicie oddzielna Mikrousługa. Nie buduj tego w ramach mikrousługi uwierzytelniania ani usługi aplikacji (rzeczywistej logiki biznesowej).

Istnieje wiele bibliotek / usług innych firm, które można wykorzystać do zbudowania ich dla swojej aplikacji. Wykorzystaj je i zbuduj na tym.

Pamiętaj, aby zbudować wszystkie 3 funkcjonalności:

  • Powiadomienia push (APNS + FCM),
  • E-maile (po prostu zintegruj klienta SMTP, aby rozpocząć)
  • i SMS-y

UWAGA - Posiadaj dwa kanały do ​​wysyłania SMS-ów, transakcyjny i promocyjny. Nigdy nie wysyłaj promocyjnych SMS-ów na kanale transakcyjnym, ponieważ istnieje szansa, że ​​zostaniesz pozwany przez dobrze poinformowanego i zmotywowanego użytkownika.

Prostym sposobem skonfigurowania klienta SMTP w aplikacji jest użycie tego w ustawieniach:

Zrobiłem to w Django, ale możesz zrobić to samo w wybranym języku i frameworku.

Skonfiguruj rejestrowanie błędów

Użyj oprogramowania pośredniego do rejestrowania błędów występujących w systemie produkcyjnym. Twój system produkcyjny nie będzie monitorowany przez ludzi siedzących tam w celu przeglądania dzienników aplikacji 24/7. Będziesz więc potrzebował systemu, który będzie rejestrował te wewnętrzne błędy serwera w centralnym miejscu. Następnie możesz je codziennie sprawdzać lub tworzyć webhooka, abyś mógł zostać ostrzeżony we właściwym czasie i zająć się nimi.

Na rynku dostępnych jest wiele narzędzi do rejestrowania błędów innych firm. Po prostu wybierz ten, który odpowiada Twoim wymaganiom. Głównie używam Sentry / Airbrake.

Rozważ skonfigurowanie webhooków, jak wspomniałem powyżej. Będą informować użytkowników o błędach i, na przykład, możesz publikować te błędy w momencie ich wystąpienia na niektórych wolnych kanałach. Następnie możesz regularnie sprawdzać te kanały i korygować je na podstawie ich wagi.

Oficjalna strona główna Airbrake - //airbrake.io/

Oficjalna strona główna Sentry - //sentry.io/welcome/

Implementacja żądania - odpowiedź i logowanie aplikacji

Scenariusz - użytkownik przychodzi do Twojego wsparcia i mówi, że nie otrzymał paragonu transakcyjnego za zakup dokonany w Twojej witrynie. Co zrobisz?

Jeśli umieściłeś rejestrowanie aplikacji w swoim systemie, nie martw się. Co mam przez to na myśli? Zawsze lepiej jest pokazać przykład niż próbować wyjaśnić słowami. Więc oto jest:

Zalogowałem się, że mam zamiar wysłać wiadomość e-mail na podany adres email_id. Mogę sprawdzić w dziennikach aplikacji, czy wiadomość e-mail została faktycznie wysłana do klienta, sprawdzając, czy taki dziennik istnieje w systemie. Pamiętaj, aby umieścić w systemie obszerne dzienniki, abyś mógł prześledzić drogę żądania.

Ponadto dobrym pomysłem jest zainstalowanie systemu asynchronicznego, który będzie pobierał takie żądania-odpowiedź i dzienniki aplikacji z systemu i zrzucał je w centralnym miejscu. Tam mogą być przetwarzane, aby były łatwiejsze do interpretacji.

Stos ELK jest do tego dobrym rozwiązaniem: ElasticSearch - Logstash - Kibana.

Więcej o stosie ELK - //www.elastic.co/what-is/elk-stack

UWAGA - Podczas rejestrowania żądań i odpowiedzi zwróć uwagę na następujące kwestie:

  • Nie rejestruj haseł.
  • Nie rejestruj tokenów (tokenów dostępu, które są używane do uwierzytelniania)
  • Nie rejestruj haseł jednorazowych

Wprowadź ograniczanie przepustowości w interfejsach API i ograniczanie szybkości na serwerach aplikacji

Scenariusz - właśnie uruchomiłeś swoją usługę i sprzedałeś produkt na platformach mediów społecznościowych. Dowiedział się o tym haker z czarnym kapeluszem i po prostu chciał bawić się twoim systemem. Dlatego zaplanowali atak DOS (Denial of Service) na twój system.

Aby temu przeciwdziałać, możesz ustawić ograniczanie szybkości w oparciu o różne czynniki oprócz systemów równoważenia obciążenia dla serwerów aplikacji. To zajmie się atakami DOS i zapobiegnie atakowaniu twoich serwerów przez złośliwego użytkownika.

Scenariusz - punkt końcowy interfejsu API / otp / validate, który przyjmuje 4-cyfrowe hasła jednorazowe w celu uwierzytelnienia użytkownika i zwraca tokeny do wykorzystania w uwierzytelnianych interfejsach API. Złośliwy użytkownik pobiera numer mobile_number dla jednego z Twoich klientów i zaczyna uderzać w punkt końcowy API atakiem brute force zmieniającym adresy IP, atakiem DDOS (Distributed Denial of Service). Ogranicznik szybkości nie jest w stanie zatrzymać użytkownika, ponieważ adres IP zmienia się wraz z każdym wykonanym żądaniem.

Aby temu zapobiec, możesz również ograniczyć przepustowość interfejsów API w oparciu o użytkownika. Można skonfigurować liczbę żądań, które może wysłać określony użytkownik do punktu końcowego interfejsu API. W przypadku walidacji OTP dobra liczba to 5 żądań na 10 minut. Uniemożliwi to złośliwemu użytkownikowi wykonanie brutalnego ataku DDoS na powyższy interfejs API.

Ograniczanie przepustowości w REST Framework Django -

//www.django-rest-framework.org/api-guide/throttling/

Ustanów i skonfiguruj komunikację asynchroniczną od pierwszego dnia

Scenariusz - Musisz wysłać powitalną wiadomość e-mail do użytkownika podczas rejestracji w aplikacji. Klient frontonu trafia do Register API, po walidacji tworzysz użytkownika w zapleczu, a to rozpoczyna proces wysyłania powitalnej wiadomości e-mail.

Wysłanie tej powitalnej wiadomości e-mail zajmie trochę czasu, może kilka sekund. Ale dlaczego miałbyś chcieć, aby klient mobilny utknął w takim procesie? Może się to zdarzyć w tle bez utknięcia użytkownika bez konkretnego powodu na stronie rejestru. Każda sekunda jest cenna i nie chcesz, aby użytkownik stracił te cenne sekundy.

Po prostu wyślij wiadomość e-mail za pomocą zadania asynchronicznego. Użyj pracowników, zadań, brokerów wiadomości i wyników końcowych, aby to wykonać.

Dobrym przykładem tego ze świata Pythona jest pracownik selera. Po prostu umieść zadanie, które ma zostać wykonane w brokerze komunikatów (Rabbit MQ / SQS itp.). Seler wysłucha tego i wyśle ​​zadanie do wskazanego pracownika. Pracownik ten następnie przetworzy żądanie i umieści wynik w zapleczu wyników, którym może być system pamięci podręcznej / system bazy danych. (Na przykład Redis / PostgreSQL).

Możesz monitorować te zadania i kolejki za pomocą wielu bibliotek innych firm. Dobrym tego przykładem jest kwiat selera, który to wszystko monitoruje.

Możesz przeczytać więcej o RabbitMQ tutaj - //www.rabbitmq.com/

I seler - //docs.celeryproject.org/en/stable/django/first-steps-with-django.html

I wreszcie kwiat selera - //flower.readthedocs.io/en/latest/

Skonfiguruj zadania cron

Scenariusz - właśnie uruchomiłeś swój produkt i musisz wysyłać użytkownikom rekomendacje dotyczące nowych produktów na Twojej platformie. Będziesz je wysyłać na podstawie historii zakupów w każdy weekend.

Powyższe zadanie można łatwo wykonać za pomocą zadania cron. Jest łatwo konfigurowalny w każdym frameworku. Ważną rzeczą, o której należy pamiętać, jest to, że nie należy umieszczać zadań crona bezpośrednio w pliku crontab na serwerze. Powinieneś pozwolić, aby ramy sobie z tym poradziły.

Dzieje się tak, ponieważ inżynier wdrażania / inżynier Devops powinien być jedyną osobą, która ma taki dostęp do systemu ze względów bezpieczeństwa. Chociaż nie musisz tego wdrażać w ten sposób, dobrze jest mieć to od początku.

W świecie Django możesz użyć selera naciowego, aby skonfigurować swoje crony za pomocą selera.

Dowiedz się więcej o Seler Beat tutaj - // docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

Zarządzaj poprawnie swoimi sekretami (plik parametrów)

Istnieje wiele sposobów zarządzania tajemnicami parametrów na serwerach produkcyjnych. Niektórzy z nich są:

  • Tworzenie pliku tajnego i przechowywanie go w prywatnym wiadrze s3 i pobieranie tego samego podczas wdrażania aplikacji.
  • Ustawianie parametrów w zmiennych środowiskowych podczas wdrażania aplikacji (ponowne przechowywanie ich w s3)
  • Umieszczenie sekretów w jakiejś tajnej usłudze zarządzania (np. //Aws.amazon.com/secrets-manager/) i używanie ich do uzyskiwania sekretów w aplikacji.

Możesz wybrać dowolną z tych metod zgodnie ze swoim komfortem i przypadkiem użycia. (Możesz też zachować różne tajne pliki dla środowisk lokalnych, pomostowych i produkcyjnych).

Wersjonuj swoje interfejsy API od pierwszego dnia

Jest to coś, co zdecydowanie powinieneś wziąć pod uwagę od pierwszego dnia. Nigdy nie dowiesz się, jak często Twoje modele biznesowe mogą się zmieniać, a aplikacja musi być kompatybilna z poprzednimi wersjami. Dlatego należy wersjonować swoje interfejsy API, aby zapewnić wszystkim płynne działanie.

Możesz mieć różne aplikacje dla różnych wersji i pozwolić nginx obsłużyć to dla Twojej aplikacji. Możesz też mieć przechowywanie wersji w samej aplikacji i pozwolić, aby obsłużyły ją trasy na serwerze aplikacji. Możesz wybrać dowolną metodę, aby to zaimplementować - głównym celem jest włączenie wersjonowania od samego początku.

Zdecyduj się na sprawdzanie wersji twardych i miękkich aktualizacji dla klientów frontonu

Jaka jest różnica między aktualizacjami twardymi i miękkimi?

Aktualizacje twarde odnoszą się do sytuacji, gdy użytkownik jest zmuszony zaktualizować wersję klienta do wyższego numeru wersji niż ten, który jest zainstalowany na jego telefonie komórkowym.

Aktualizacje miękkie odnoszą się do sytuacji, gdy użytkownikowi wyświetla się monit, że dostępna jest nowa wersja i może on zaktualizować swoją aplikację do nowej wersji, jeśli chce.

Twarde aktualizacje nie są zalecane, ale czasami trzeba je wymusić. W każdym przypadku zdecydowanie powinieneś rozważyć, w jaki sposób zamierzasz to zaimplementować w swoich aplikacjach.

Możesz to zrobić, wdrażając lub konfigurując go w Sklepie Play lub App Store. Innym sposobem jest utworzenie interfejsu API w aplikacji zaplecza, który będzie działał za każdym razem, gdy aplikacja mobilna zostanie uruchomiona. Spowoduje to wysłanie dwóch kluczy: hard_update -> true / false i soft_update -> true / false, w zależności od wersji użytkownika oraz wersji twardej i miękkiej aktualizacji ustawionej w systemie zaplecza.

Dobrym miejscem do przechowywania tych wersji jest pamięć podręczna (Redis / Memcache), którą można zmieniać w locie bez konieczności wdrażania aplikacji.

Wprowadź ciągłą integrację (CI) od pierwszego dnia

Scenariusz - jeden ze stażystów pracujących w Twoim projekcie nie jest wystarczająco biegły, aby pisać kod na poziomie produkcyjnym. Mogli zmienić coś, co może zepsuć jakiś krytyczny komponent w twoim projekcie. Jak możesz się upewnić, że w takich przypadkach wszystko jest w porządku?

Wprowadź ciągłą integrację. Będzie uruchamiał lintery i przypadki testowe dla każdego zatwierdzenia i będzie się łamał, jeśli zostaną naruszone jakiekolwiek reguły. To z kolei zablokuje scalanie żądania ściągnięcia, dopóki wszystkie reguły lintingu i przypadki testowe nie przejdą. Fajnie jest mieć coś, a na dłuższą metę pomaga też, więc miej to na uwadze.

Na rynku dostępnych jest wiele opcji. Możesz zdecydować się zaimplementować go samodzielnie (Jenkins CI / CD) lub użyć TravisCI, CircleCI itp. Do tego samego.

Przeczytaj o TravisCI tutaj - //travis-ci.org/

Oraz CircleCI - //circleci.com/

Włącz obsługę platformy Docker (preferencje osobiste)

Utwórz plik Dockerfile i docker-compose.yml dla swojej aplikacji, aby każdy od początku uruchamiał aplikację przy użyciu platformy Docker. Jednym z głównych powodów, dla których warto zastosować takie podejście, jest zachowanie spójności w środowisku lokalnym / przejściowym / produkcyjnym, aby żaden programista nie mógł tego powtórzyć:

Ale to działało na mojej maszynie.

Nie jest trudno zastosować go od pierwszego dnia. Na początku po prostu użyj Dockera w swoim lokalnym środowisku, aby konfiguracja aplikacji przebiegła naprawdę płynnie. Pamiętaj jednak, jak możesz go uruchomić zarówno z Dockerem, jak i bez niego w środowisku produkcyjnym.

Oto więcej informacji na temat Docker Hub - //hub.docker.com/

Użyj narzędzia APM

Narzędzie do monitorowania aplikacji jest niezbędne, jeśli chcesz monitorować interfejsy API aplikacji, transakcje, połączenia z bazą danych i tak dalej.

Scenariusz - dysk twardy twojego serwera cron jest prawie pełny i nie jest on w stanie uruchomić zadań cron. Ponieważ nie może znaleźć miejsca na dysku, twoje crony nie działają. Jak więc możesz otrzymać powiadomienie, kiedy to się stanie?

Istnieje wiele narzędzi APM, których możesz użyć do monitorowania tego. Możesz je skonfigurować w zależności od tego, kiedy chcesz otrzymać powiadomienie. Otrzymasz powiadomienia na wybranym przez siebie medium, gdy taki chaos wydarzy się w Twoim systemie - i wierz mi, że dzieje się to cały czas. Więc lepiej bądź na to przygotowany. New Relic to dobra opcja.

Przeczytaj więcej o New Relic tutaj - //newrelic.com/

Użyj ElasticSearch, aby usprawnić wyszukiwanie w całej aplikacji w aplikacjach klienckich

Według Wikipedii

Elasticsearch to wyszukiwarka oparta na bibliotece Lucene. Zapewnia rozproszoną, obsługującą wielu dzierżawców wyszukiwarkę pełnotekstową z interfejsem WWW HTTP i pozbawionymi schematów dokumentami JSON. Elasticsearch jest rozwijany w Javie.

Na początku będziesz kuszony, aby użyć tradycyjnych zapytań do bazy danych, aby uzyskać wyniki w tym pasku wyszukiwania dla aplikacji klienckiej. Czemu? Ponieważ jest to łatwe.

Jednak tradycyjne bazy danych nie są przeznaczone do takich wydajnych zapytań. Znajdź dobry moment na migrację wyszukiwania do ElasticSearch i wprowadzenie potoku danych do systemu. Dostarcza dane do wyszukiwania elastycznego, a następnie łączy wyszukiwanie z ElasticSearch z serwerem aplikacji.

Oto dobry przegląd Elasticsearch, na początek.

Oraz dokumentacja ElasticSearch - //www.elastic.co/guide/index.html

Umieść firewall na serwerze produkcyjnym

Zdecydowanie powinieneś to zrobić - to pozycja obowiązkowa. Umieść zaporę na serwerze produkcyjnym i zamknij wszystkie porty z wyjątkiem tych, które mają być używane przez interfejsy API (połączenia https). Kieruj punkty końcowe interfejsu API za pomocą odwrotnego serwera internetowego proxy, takiego jak NGiNX lub Apache. Żaden port nie powinien być dostępny dla świata zewnętrznego poza portami dozwolonymi przez NGiNX.

Dlaczego powinieneś używać NGiNX:

  • //www.nginx.com/resources/wiki/community/why_use_it/
  • //blog.serverdensity.com/why-we-use-nginx/
  • //www.freecodecamp.org/news/an-introduction-to-nginx-for-developers-62179b6a458f/

Podsumowując

Powyższe punkty opierają się na moich własnych preferencjach i rozwijałem je przez lata. Tu i tam będą niewielkie różnice, ale koncepcje pozostają takie same.

Ostatecznie robimy to wszystko, aby mieć sprawny system zbudowany od podstaw i uruchomiony w produkcji tak szybko, jak to możliwe, po tym, jak wpadniesz na pomysł.

Próbowałem spisać całą swoją wiedzę, którą zdobyłem przez lata, i mogę się mylić w kilku miejscach .I f myślisz, że możesz zaoferować lepsze informacje , uprzejmie prosimy o komentarz. I jak zawsze podziel się, jeśli uważasz, że jest to pomocne.