Základní architektura zásobníku spouštění

Azure App Service
Azure Blob Storage
Azure Content Delivery Network
Azure Database for PostgreSQL
Azure Virtual Network

Mnoho lekcí, které se naučíte ve větších společnostech, se přímo nevztahuje na první stack startupu. V počáteční fázi zkoumání produktu je potřeba optimalizovat nasazení pro rychlost, náklady a volitelnost. Volitelnost označuje, jak rychle můžete změnit směry v dané architektuře.

Firma v rozšiřujících nebo extrahovaných fázích vývoje produktů může používat architekturu orientované na služby nebo mikroslužby. Tento typ architektury nasazení je zřídka vhodný pro startup, který ještě nenalezl produkt/trh nebo komerční trakci.

Pro základní spouštěcí zásobník je nejlepší jednoduchý monolitický návrh. Tento návrh omezuje dobu strávenou správou infrastruktury a současně poskytuje větší možnost škálování, protože startup vyhraje více zákazníků.

Potenciální případy použití

Tento článek představuje příklad jednoduchého základního spouštěcího zásobníku a popisuje jeho komponenty.

Architektura

Společnost Contoso vytvořila prototyp aplikace s back-endem Ruby on Rails a front-end React napsaným v TypeScriptu. Tým Contoso provozuje ukázky na svých přenosných počítačích. Teď chtějí nasadit svou aplikaci pro své první zákaznické prodejní schůzky.

I když je aplikace ambiciózní, zatím nepotřebuje složitou architekturu založenou na mikroslužbách. Společnost Contoso se rozhodla pro jednoduchý monolitický návrh, který obsahuje doporučené komponenty zásobníku spouštění.

Diagram that shows the core startup stack architecture Contoso used to deploy their application.

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat

V této základní architektuře zásobníku spouštění:

  • služba Aplikace Azure poskytuje jednoduchý aplikační server pro nasazení škálovatelných aplikací bez konfigurace serverů, nástrojů pro vyrovnávání zatížení nebo jiné infrastruktury.
  • Azure Database for PostgreSQL je databázová služba Azure pro přední opensourcový systém pro správu relačních databází (RDBMS). Můžete se soustředit na vývoj aplikace, nikoli na správu databázových serverů.
  • Azure Virtual Network segmentuje síťový provoz a udržuje interní služby chráněné před internetovými hrozbami. Vaše aplikační servery používají integraci virtuální sítě ke komunikaci s databází bez ohrožení internetu.
  • GitHub Actions sestavuje kontinuální integraci a průběžné nasazování (CI/CD) do správy zdrojového kódu. GitHub Actions má rozsáhlou podporu pro různé jazyky a silnou integraci se službami Azure.
  • Azure Blob Storage ukládá statické prostředky a přesouvá zatížení ze serverů aplikací.
  • Azure Content Delivery Network (CDN) urychluje doručování obsahu uživatelům prostřednictvím globální sítě.
  • Azure Monitor monitoruje a analyzuje, co se děje v infrastruktuře vaší aplikace.

Základní komponenty zásobníku spouštění

Složitý zásobník může generovat chyby, které vyžadují konstantní pozornost. Sofistikovaná architektura může od vytváření produktu oddálit. Chyby nejsou způsobené složitostí, ale složitý zásobník usnadňuje odeslání chyb. Ne všechny sofistikované architektury jsou plýtvání energií, ale plýtvají vašimi zdroji, pokud jste ještě nenalezli produkt nebo trh. První spouštěcí zásobník by měl být jednoduchý a vypadněte z cesty, abyste se mohli soustředit na vývoj produktů.

Následující jednoduchý diagram znázorňuje doporučený zásobník spouštění jádra. Tyto komponenty jsou dostatečné k tomu, aby se váš produkt dostal ze země a do rukou vašich zákazníků. Pro 80 procent startupů je tento zásobník vše, co potřebujete otestovat základní hypotézy integrované do vašeho produktu. Startupy pracující ve strojovém učení, internetu věcí (IoT) nebo vysoce regulovaných prostředích můžou vyžadovat více komponent.

A block diagram that shows a core startup stack.

CDN

S několika zákazníky na začátku se může zdát, že síť CDN je předčasně. Přidání CDN do produktu, který je již v produkčním prostředí, však může mít neočekávané vedlejší účinky. Nejlepší je implementovat síť CDN předem. CDN ukládá statický obsah do mezipaměti blíže vašim zákazníkům a poskytuje fasádu, za kterou můžete iterovat rozhraní API a architekturu.

Aplikační server

Váš kód musí běžet někde. V ideálním případě by tato platforma měla usnadnit nasazení a zároveň vyžadovat co nejmenší možný provozní vstup. Aplikační server by se měl škálovat horizontálně, ale v době, kdy jste stále ve fázi zkoumání, je v pořádku nějaký zásah ručního škálování.

Stejně jako většina tohoto zásobníku by se aplikační server měl v podstatě spustit sám. Aplikační server byl tradičně virtuální počítač nebo instance webového serveru spuštěná na holém serveru. Teď se můžete podívat na možnosti a kontejnery paaS (platforma jako služba) a odstranit provozní režii.

Statický obsah

Obsluha statického obsahu z aplikačního serveru ztrácí prostředky. Po konfiguraci kanálu CI/CD je práce na sestavení a nasazení statických prostředků s každou verzí triviální. Většina produkčních webových architektur nasazuje statické prostředky s CI/CD, takže je vhodné začít v souladu s tímto osvědčeným postupem.

Databáze

Po spuštění aplikace je potřeba ukládat data do databáze. Ve většině případů je nejlepším řešením relační databáze. Relační databáze má více metod přístupu a rychlost časově testovaného řešení. Mezi relační databáze patří Azure SQL Database, Azure Database for PostgreSQL a Azure Database for MariaDB. Některé případy použití vyžadují databázi dokumentů nebo databázi NoSQL, jako je MongoDB nebo Azure Cosmos DB.

Agregace protokolů

Pokud se s vaší aplikací něco nepovede, chcete trávit co nejmenší čas diagnostikou problému. Agregací protokolů a používáním trasování aplikací od začátku pomůžete vašemu týmu zaměřit se na samotné problémy. K získání dat monitorování nemusíte přistupovat k souboru na aplikačním serveru a překrývejte protokoly.

CI/CD

Nedostatek opakovatelných a rychlých nasazení je jedním z nejhorších překážek rychlosti při iteraci produktu. Dobře nakonfigurovaný kanál CI/CD zjednodušuje proces nasazení kódu na aplikačním serveru. Rychlá a snadná nasazení znamenají, že výsledky práce rychle uvidíte. Často se integrace vyhne rozdílným základům kódu, které vedou ke konfliktům při slučování.

Nasazení tohoto scénáře

Koncepty a techniky jsou stejné pro většinu projektů, které sestavíte pomocí souboru Dockerfile.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Další kroky