Podstawowa architektura stosu uruchamiania

Wiele lekcji, które uczysz się w większych firmach, nie ma bezpośredniego zastosowania do pierwszego stosu startupu. W początkowym etapie eksplorowania produktu należy zoptymalizować wdrożenie pod kątem szybkości, kosztów i opcjonalnych możliwości. Opcjonalnie odnosi się do tego, jak szybko można zmienić kierunek w ramach danej architektury.

Firma w fazach rozszerzania lub wyodrębniania produktu może używać architektury zorientowanej na usługi lub mikrousług. Ten typ architektury wdrażania jest rzadko odpowiedni dla startupu, który nie znalazł jeszcze dopasowania produktu/rynku lub trakcji komercyjnej.

W przypadku podstawowego stosu startowego najlepszy jest prosty monolityczny projekt. Ten projekt ogranicza czas poświęcany na zarządzanie infrastrukturą, zapewniając jednocześnie dużą możliwość skalowania, ponieważ startup wygrywa więcej klientów.

Potencjalne przypadki użycia

W tym artykule przedstawiono przykład prostego podstawowego stosu uruchamiania i omówiono jego składniki.

Architektura

Startup, Contoso, zbudował prototyp aplikacji z zapleczem języka Ruby on Rails i frontonem React napisanym w języku TypeScript. Zespół firmy Contoso uruchamia pokazy na swoich laptopach. Teraz chcą wdrożyć swoją aplikację na potrzeby pierwszych spotkań sprzedaży klientów.

Chociaż aplikacja jest ambitna, nie potrzebuje jeszcze złożonej architektury opartej na mikrousługach. Firma Contoso zdecydowała się na prosty monolityczny projekt zawierający zalecane składniki stosu uruchamiania.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych

W tej podstawowej architekturze stosu uruchamiania:

• usługa aplikacja systemu Azure udostępnia prosty serwer aplikacji do wdrażania skalowalnych aplikacji bez konfigurowania serwerów, modułów równoważenia obciążenia lub innej infrastruktury. Usługa App Service obsługuje wdrożenia kontenerów, jak w tym przykładzie, a także obsługuje wdrożenia bez kontenerów dla ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP lub Python.
• Azure Database for PostgreSQL to usługa bazy danych platformy Azure przeznaczona dla wiodącego systemu zarządzania relacyjnymi bazami danych typu open source (RDBMS). Możesz skoncentrować się na tworzeniu aplikacji, a nie na zarządzaniu serwerami baz danych. Platforma Azure ma również zarządzane usługi baz danych dla usług SQL, MySQL, MariaDB, MongoDB, Apache Cassandra, Gremlin i Redis.
• Usługa Azure Virtual Network segmentuje ruch sieciowy i utrzymuje wewnętrzne usługi chronione przed zagrożeniami internetowymi. Serwery aplikacji używają integracji sieci wirtualnej do komunikowania się z bazą danych bez narażenia na Internet.
• Funkcja GitHub Actions tworzy ciągłą integrację i ciągłe wdrażanie (CI/CD) do zarządzania kodem źródłowym. Funkcja GitHub Actions ma rozbudowaną obsługę różnych języków i silną integrację z usługami platformy Azure.
• Usługa Azure Blob Storage przechowuje zasoby statyczne i przenosi obciążenie z serwerów aplikacji.
• Usługa Azure Front Door z zaporą aplikacji internetowej przyspiesza i zabezpiecza dostarczanie zawartości użytkownikom za pośrednictwem globalnej sieci dostarczania zawartości (CDN) i zapory aplikacji internetowej.
• Usługa Azure Monitor monitoruje i analizuje, co dzieje się w infrastrukturze aplikacji.

Podstawowe składniki stosu uruchamiania

Złożony stos może generować usterki, które wymagają stałej uwagi. Zaawansowana architektura może uniemożliwić tworzenie produktu. Usterki nie są spowodowane złożonością, ale złożony stos ułatwia wysyłanie usterek. Nie wszystkie zaawansowane architektury są stratą energii, ale marnują zasoby, jeśli nie znaleziono jeszcze odpowiedniego produktu/rynku. Twój pierwszy stos startowy powinien być prosty i wydostać się z drogi, więc możesz skoncentrować się na rozwoju produktu.

Na poniższym prostym diagramie przedstawiono zalecany stos uruchamiania podstawowego. Te składniki są wystarczające, aby produkt z ziemi i z rąk klientów. W przypadku 80 procent startupów ten stos jest potrzebny do przetestowania podstawowych hipotez wbudowanych w produkt. Startupy działające w uczeniu maszynowym, Internecie rzeczy (IoT) lub środowiskach wysoce regulowanych mogą wymagać większej liczby składników.

CDN

Z niewielu klientów na początku, CDN może wydawać się przedwczesne. Jednak dodanie sieci CDN do produktu już w środowisku produkcyjnym może mieć nieoczekiwane skutki uboczne. Najlepiej zaimplementować sieć CDN z góry. Usługa CDN buforuje zawartość statyczną bliżej klientów i udostępnia fasadę, za którą można iterować interfejsy API i architekturę.

Serwer aplikacji

Kod musi działać gdzieś. Najlepiej, aby ta platforma ułatwiała wdrożenia, jednocześnie wymagając najmniejszych możliwych danych wejściowych operacyjnych. Serwer aplikacji powinien być skalowany w poziomie, ale niektóre ręczne interwencje skalowania są w porządku, gdy nadal jesteś na etapie eksplorowania.

Podobnie jak większość tego stosu, serwer aplikacji powinien zasadniczo działać samodzielnie. Tradycyjnie serwer aplikacji był maszyną wirtualną lub wystąpieniem serwera internetowego działającym na serwerze bez systemu operacyjnego. Teraz możesz zapoznać się z opcjami typu platforma jako usługa (PaaS), takimi jak usługa App Service powyżej i kontenery, aby usunąć obciążenie operacyjne.

Zawartość statyczna

Obsługa zawartości statycznej z serwera aplikacji traci zasoby. Po skonfigurowaniu potoku ciągłej integracji/ciągłego wdrażania praca nad tworzeniem i wdrażaniem zasobów statycznych z każdą wersją jest banalna. Większość produkcyjnych platform internetowych wdraża zasoby statyczne za pomocą ciągłej integracji/ciągłego wdrażania, dlatego warto zacząć od dopasowania do tego najlepszego rozwiązania.

baza danych

Po uruchomieniu aplikacji musisz przechowywać dane w bazie danych. W większości przypadków najlepszym rozwiązaniem jest relacyjna baza danych. Relacyjna baza danych ma wiele metod dostępu i szybkość rozwiązania testowanego w czasie. Relacyjne bazy danych obejmują usługi Azure SQL Database, Azure Database for PostgreSQL i Azure Database for MariaDB. Niektóre przypadki użycia wymagają bazy danych dokumentów lub bazy danych NoSQL, takiej jak MongoDB lub Azure Cosmos DB.

Agregacja dzienników

Jeśli coś pójdzie nie tak z aplikacją, chcesz spędzić jak najwięcej czasu, jak to możliwe, diagnozowanie problemu. Agregując dzienniki i korzystając z śledzenia aplikacji od początku, możesz pomóc zespołowi skupić się na samych problemach. Nie musisz uzyskiwać dostępu do pliku na serwerze aplikacji i pore over logs w celu uzyskania danych monitorowania.

CI/CD

Brak powtarzalnych i szybkich wdrożeń jest jednym z najgorszych ograniczeń szybkości podczas iteracji produktu. Dobrze skonfigurowany potok ciągłej integracji/ciągłego wdrażania usprawnia proces wdrażania kodu na serwerze aplikacji. Szybkie i łatwe wdrożenia oznaczają, że wyniki pracy są widoczne szybko. Częsta integracja pozwala uniknąć rozbieżnych baz kodu, które prowadzą do konfliktów scalania. Koncepcje i techniki są takie same w przypadku większości projektów, które tworzysz przy użyciu pliku Dockerfile.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Andrew Harvey | CTO i ambasador startupów

Inni współautorzy:

• Nick Ward | Architekt rozwiązań w chmurze

Następne kroki

• Automatyzowanie przepływu pracy za pomocą funkcji GitHub Actions

Powiązane zasoby

• Architektura dla startupów
• Najlepsze rozwiązania w aplikacjach w chmurze
• Najlepsze rozwiązania dotyczące używania sieci dostarczania zawartości
• Dziesięć zasad projektowania dla aplikacji platformy Azure