Číst v angličtině

Sdílet prostřednictvím

Doporučení pro navrhování pro jednoduchost a efektivitu

  • Článek

Toto doporučení pro kontrolní seznam spolehlivosti v rámci Azure Well-Architected Framework platí:

RE:01 Zaměřte se na návrh úloh na jednoduchost a efektivitu. Při plnění obchodních cílů a požadavků použijte praktický přístup, abyste se vyhnuli zbytečné složitosti.

Tato příručka popisuje doporučení pro minimalizaci zbytečné složitosti a režie, aby vaše úlohy byly jednoduché a efektivní. Zvolte nejlepší komponenty pro provádění potřebných úloh pro optimalizaci spolehlivosti úloh. Pokud chcete zjednodušit vývoj a správu, využijte výhod efektivity, které nabízejí služby poskytované platformou. Tento návrh vám pomůže vytvořit architekturu úloh, která je odolná, opakovatelná, škálovatelná a spravovatelná.

Definice

Pojem definice
Pracovní zatížení Samostatná funkce nebo výpočetní úloha, které můžete logicky oddělit od ostatních úloh.

Klíčové strategie návrhu

Klíčovou sadou návrhu pro spolehlivost je udržovat věci jednoduché a efektivní. Zaměřte se na návrh úloh na splnění obchodních požadavků, abyste snížili riziko zbytečné složitosti nebo nadbytečné režie. Zvažte doporučení v tomto článku, která vám pomůžou při rozhodování o návrhu vytvořit štíhlou, efektivní a spolehlivou úlohu. Různé úlohy můžou mít různé požadavky na dostupnost, škálovatelnost, konzistenci dat a zotavení po havárii.

Každé rozhodnutí o návrhu musíte odůvodnit obchodním požadavkem. Tento princip návrhu může vypadat jako zřejmý, ale pro návrh úloh je zásadní. Podporuje vaše aplikace miliony uživatelů nebo několik tisíc? Dochází k velkým nárůstům provozu nebo stabilnímu zatížení? Jaká úroveň výpadku aplikace je přijatelná? Obchodní požadavky řídí tyto aspekty návrhu.

Kompromis: Komplexní řešení může nabízet více funkcí a flexibilitu, ale může ovlivnit spolehlivost pracovní zátěže, protože vyžaduje větší koordinaci, komunikaci a řízení komponent. Případně jednodušší řešení nemusí plně splňovat očekávání uživatelů nebo může mít negativní vliv na škálovatelnost a rozšiřitelnost při vývoji úloh.

Spolupráce se zúčastněnými stranami na cvičeních návrhu

Spolupracujte se zúčastněnými stranami na:

  • Definujte a přiřaďte úroveň závažnosti k tokům uživatelů a systémovým tokům vaší úlohy. Zaměřte svůj návrh na kritické toky, abyste mohli určit požadované komponenty a nejlepší přístup k dosažení požadované úrovně odolnosti.

  • Definujte funkční a nefunkční požadavky. Zvažte funkční požadavky a určete, jestli aplikace provádí úlohu. Zvažte nefunkční požadavky, abyste zjistili, jak dobře aplikace provádí úlohu. Ujistěte se, že rozumíte nefunkčním požadavkům, jako je škálovatelnost, dostupnost a latence. Tyto požadavky ovlivňují rozhodnutí o návrhu a technologické volby.

  • Rozdělte úlohy do komponent. Při návrhu upřednostněte jednoduchost, efektivitu a spolehlivost. Určete komponenty, které potřebujete k podpoře vašich toků. Některé komponenty podporují více toků. Určete, kterou výzvu komponenta koncepčně řeší, a zvažte odebrání komponenty z jednotlivých toků, abyste zjednodušili celkový návrh a současně poskytli plnou funkčnost. Další informace najdete v tématu Doporučení k provádění analýzy režimu selhání.

  • Analýza režimu selhání slouží k identifikaci kritických bodů selhání a potenciálních rizik. Zvažte, jestli potřebujete počítat s nepravděpodobnými situacemi, například geografickou oblastí, u které dochází k významné přírodní katastrofě, která ovlivňuje všechny zóny dostupnosti v dané oblasti. Je nákladná a zahrnuje významné kompromisy ke zmírnění těchto neobvyklých rizik. Jasně porozumíte tolerance vaší firmy vůči rizikům. Pro více informací viz Doporučení pro provádění analýzy režimu selhání.

  • Definujte cíle dostupnosti a obnovení pro vaše toky, abyste mohli informovat architekturu vaší úlohy. Mezi obchodní metriky patří cíle na úrovni služeb (SLA), smlouvy o úrovni služeb (SLA), střední doba obnovení (MTTR), střední doba mezi selháním (MTBF), plánovaná doba obnovení (RTO) a cíle bodu obnovení (RPO). Definujte cílové hodnoty pro tyto metriky. Toto cvičení může vyžadovat kompromis a vzájemné porozumění mezi technologiemi a obchodními týmy, aby zajistilo, že cíle každého týmu splňují obchodní cíle a jsou realistické. Další informace najdete v Doporučeních pro stanovení cílů spolehlivosti.

Upřednostnit jednodušší volby návrhu

Bez zapojení účastníků můžete provádět následující doporučení:

  • Snažte se o jednoduchost a přehlednost návrhu. Použijte odpovídající úroveň abstrakce a členitosti komponent a služeb. Vyhněte se přehnanému nebo nedostatečnému navrhování vašeho řešení. Pokud například kód rozdělíte do několika malých funkcí, je obtížné ho pochopit, otestovat a udržovat.

  • Přijměte, že všechny úspěšné aplikace se v průběhu času mění, ať už se jedná o opravu chyb, implementaci nových funkcí nebo technologií, nebo zajištění větší škálovatelnosti a odolnosti stávajících systémů.

  • Pokud je to možné, používejte možnosti platformy jako služby (PaaS) místo infrastruktury jako služby (IaaS). IaaS je jako krabice součástek. Můžete postavit cokoli, ale musíte to udělat sami. Možnosti PaaS se snadněji konfigurují a spravují. Nemusíte nastavovat virtuální počítače ani virtuální sítě. Nemusíte také provádět úlohy údržby, jako je instalace oprav a aktualizací.

  • Pomocí asynchronního zasílání zpráv oddělte producenta zpráv od příjemce.

  • Abstrahujte infrastrukturu od logiky domény. Ujistěte se, že logika domény nenarušuje funkce související s infrastrukturou, jako je zasílání zpráv nebo trvalost.

  • Přesuňte průřezové záležitosti do samostatné služby. Minimalizujte potřebu duplikovat kód napříč různými funkcemi, upřednostněte opakované použití služeb s dobře definovanými rozhraními, která můžou být snadno využita různými komponentami. Pokud například vyžaduje ověření požadavků několik služeb, můžete tuto funkci přesunout do vlastní služby. Pak můžete službu ověřování vyvíjet. Můžete například přidat nový tok ověřování, aniž byste se museli dotýkat některé ze služeb, které ho používají.

  • Vyhodnoťte vhodnost běžných vzorů a postupů pro vaše potřeby. Vyhněte se sledování trendů nebo doporučení, která nemusí být pro váš kontext nebo požadavky nejvhodnější. Například mikroslužby nejsou nejlepší volbou pro každou aplikaci, protože můžou představovat složité problémy, režijní náklady a závislosti.

Vývoj pouze dostatečného množství kódu

Principy jednoduchosti, efektivity a spolehlivosti platí také pro vaše vývojové postupy. Ve volně propojených komponentovaných úlohách určete funkce, které komponenta poskytuje. Vyvíjejte pracovní postupy, abyste mohli využít této funkce. Zvažte tato doporučení pro vaše vývojové postupy:

  • Funkce platformy používejte, když splňují vaše obchodní požadavky. Pokud chcete například přesměrovat vývoj a správu, použijte nízkokódová, bezkódová nebo bezserverová řešení, která nabízí poskytovatel cloudu.

  • Používejte knihovny a frameworky.

  • Zaveďte párové programování nebo vyhrazené relace pro kontrolu kódu jako součást vývojových praktik.

  • Implementujte přístup k identifikaci mrtvého kódu. Buďte skeptičtí na kód, který vaše automatizované testy nepokrývají.

Výběr správného úložiště dat

V minulosti mnoho organizací uložilo všechna svá data ve velkých relačních databázích SQL. Relační databáze poskytují atomické, konzistentní, izolované a odolné záruky (ACID) pro transakce relačních dat. Tyto databáze ale mají nevýhody:

  • Dotazy můžou vyžadovat nákladné spojení.

  • Potřebujete normalizovat data a restrukturalizovat je pro schéma při zápisu.

  • Kolize zámků může ovlivnit výkon.

Alternativy k relačním databázím

Ve velkém řešení pravděpodobně jedna technologie úložiště dat nesplňuje všechny vaše potřeby. Alternativy k relačním databázím zahrnují:

  • Úložiště klíčů a hodnot

  • Databáze dokumentů

  • Databáze vyhledávacích webů

  • Databáze s časovou řadou

  • Databáze skupin sloupců

  • Grafové databáze

Každá možnost má výhody a nevýhody. Různé datové typy jsou vhodnější pro různé typy úložiště dat. Vyberte technologii úložiště, která je pro vaše data nejvhodnější a jak je používáte.

Katalog produktů můžete například uložit do databáze dokumentů, jako je Azure Cosmos DB, která podporuje flexibilní schéma. Každý popis produktu je samostatný dokument. U dotazů v celém katalogu můžete katalog indexovat a uložit do služby Azure Cognitive Search. Inventář produktů může jít do databáze SQL, protože tato data vyžadují záruky ACID.

Doporučení

  • Zvažte další úložiště dat. Relační databáze nejsou vždy vhodné. Další informace najdete v tématu Pochopení modelů úložiště dat.

  • Mějte na paměti, že data zahrnují více než jen trvalá data aplikace. Zahrnují také protokoly aplikací, události, zprávy a mezipaměti.

  • Využijte polyglotní trvalost nebo řešení, která používají kombinaci technologií úložiště dat.

  • Vezměte v úvahu typ dat, která máte. Například obchod:

    • Transakční data v databázi SQL.

    • Dokumenty JSON v databázi dokumentů

    • Telemetrie v databázi časových řad

    • Protokoly aplikací ve službě Azure Cognitive Search

    • Bloby ve službě Azure Blob Storage

  • Určete prioritu dostupnosti před konzistencí. Věta CAP znamená, že musíte v distribuovaném systému učinit kompromisy mezi dostupností a konzistencí. Nemůžete se úplně vyhnout síťovým oddílům, což je druhá komponenta CAP teorému. K dosažení vyšší dostupnosti ale můžete použít model konečné konzistence.

  • Představte si sadu dovedností vašeho vývojového týmu. Existují výhody použití polyglotické trvalosti, ale je možné to přehnat. K přijetí nové technologie úložiště dat vyžaduje nové sady dovedností. Aby váš vývojový tým získal maximum z této technologie, musí:

    • Optimalizujte dotazy.

    • Vylaďte výkon.

    • Pracujte s příslušnými vzory použití.

Při výběru technologie úložiště zvažte tyto faktory:

  • Používejte kompenzační transakce. Při polyglotní trvalosti může jedna transakce zapisovat data do více úložišť. Pokud dojde k selhání, použijte kompenzační transakce k vrácení všech dokončených kroků zpět.

  • Zvažte ohraničené kontexty, což je koncept návrhu řízeného doménou. Ohraničený kontext je explicitní hranice kolem doménového modelu. Ohraničený kontext definuje, na které části domény se model vztahuje. V ideálním případě se ohraničený kontext mapuje na subdoménu obchodní domény. Zvažte polyglotní trvalost pro ohraničené kontexty ve vašem systému. Například produkty se mohou objevit v subdoméně katalogu produktů a subdoméně inventáře produktů. Tyto dvě subdomény ale s největší pravděpodobností mají různé požadavky na ukládání, aktualizaci a dotazování produktů.

Usnadnění Azure

Azure nabízí následující služby:

  • Azure Functions je bezserverová výpočetní platforma, kterou můžete použít pro vytváření orchestrace s minimálním množstvím kódu.

  • Azure Logic Apps je bezserverová platforma pro integraci pracovních postupů, kterou můžete použít k sestavení orchestrace pomocí grafického uživatelského rozhraní nebo úpravou konfiguračního souboru.

  • Azure Event Grid je vysoce škálovatelná, plně spravovaná služba pro rozesílání zpráv s modelem publikování a odběru, která nabízí flexibilní způsoby spotřeby zpráv využívající protokoly MQTT a HTTP. Pomocí Event Gridu můžete vytvářet datové kanály s daty zařízení, vytvářet bezserverové architektury řízené událostmi a integrovat aplikace.

Další informace naleznete v tématu:

Příklad

Najdete ukázkovou úlohu, která určuje komponenty a jejich funkce na základě požadavků, v části "Spolehlivý webový aplikační vzor".

Kontrolní seznam pro spolehlivost

Projděte si kompletní sadu doporučení.

Kontrolní seznam pro spolehlivost