Share via

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

  • Článek

Platí pro toto doporučení kontrolního seznamu spolehlivosti azure Well-Architected Framework:

RE:01 Navrhněte úlohu tak, aby odpovídala obchodním cílům a vyhnula se zbytečné složitosti nebo režijním nákladům. Při rozhodování o návrhu použijte praktický a vyvážený přístup, který zajistí požadované výsledky. Omezte svůj návrh tak, aby se snížila neefektivita a potenciální problémy.

Tato příručka popisuje doporučení pro minimalizaci zbytečné složitosti a režijních nákladů, 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 zmenšit zatížení vývoje a správy, využijte výhod efektivity, kterou 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

Období Definice
Úloha Samostatná funkce nebo výpočetní úloha, kterou můžete logicky oddělit od ostatních úkolů.

Klíčové strategie návrhu

Klíčovým předpokladem návrhu pro spolehlivost je udržovat věci jednoduché a efektivní. Zaměřte návrh úloh na splnění obchodních požadavků, abyste snížili riziko zbytečné složitosti nebo nadměrné režie. Zvažte doporučení v tomto článku, která vám pomůžou při rozhodování o vašem návrhu vytvořit štíhlé, efektivní a spolehlivé úlohy. 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 ospravedlnit obchodním požadavkem. Tento princip návrhu se může zdát 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ému nárůstu provozu nebo stabilnímu zatížení? Jaká úroveň výpadku aplikace je přijatelná? Tyto aspekty návrhu se řídí obchodními požadavky.

Kompromis: Komplexní řešení může nabídnout více funkcí a flexibility, ale může to mít vliv na spolehlivost úloh, protože vyžaduje větší koordinaci, komunikaci a správu komponent. Jednodušší řešení také nemusí plně splňovat očekávání uživatelů nebo může mít negativní vliv na škálovatelnost a rozšiřitelnost s tím, jak se zatížení vyvíjí.

Cvičení návrhu pro spolupráci

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

  • Definujte a přiřaďte úroveň důležitosti k tokům uživatelů a systémovým tokům úloh. Zaměřte se na kritické toky , které vám pomůžou 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 a určete, 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í rozhodování o návrhu a volbě technologií.

  • Rozložte úlohy do komponent. Upřednostněte jednoduchost, efektivitu a spolehlivost ve svém návrhu. Určete komponenty, které potřebujete k podpoře vašich toků. Některé komponenty podporují více toků. Identifikujte, které výzvy komponenta koncepčně řeší, a zvažte odebrání komponenty z jednotlivých toků, abyste zjednodušili celkový návrh a zároveň poskytovali plnou funkčnost. Další informace najdete v tématu Doporučení pro provádění analýzy režimu selhání.

  • Pomocí analýzy režimu selhání identifikujte jednotlivé body selhání a potenciální rizika. Zvažte, jestli potřebujete zohlednit nepravděpodobné situace, například geografickou oblast, u které dochází k závažné přírodní katastrofě, která ovlivňuje všechny zóny dostupnosti v dané oblasti. Je to nákladné a zahrnuje významné kompromisy ke zmírnění těchto neobvyklých rizik. Jasně porozumíte toleranci vaší firmy k rizikům. Další informace najdete v tématu Doporučení pro provádění analýzy režimu selhání.

  • Definujte pro své toky cíle dostupnosti a obnovení , abyste mohli informovat o architektuře úloh. Mezi obchodní metriky patří cíle na úrovni služeb (SLO), smlouvy o úrovni služeb (SLA), střední doba obnovení (MTTR), střední doba mezi selháním (MTBF), cíle doby 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 se zajistilo, že cíle jednotlivých týmů splňují obchodní cíle a jsou realistické. Další informace najdete v tématu Doporučení pro definování cílů spolehlivosti.

Další doporučení k návrhu

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

  • Snažte se o jednoduchost a srozumitelnost návrhu. Pro komponenty a služby používejte odpovídající úroveň abstrakce a členitosti. Vyhněte se přeinženýrování nebo podinženýrování řešení. Pokud například rozdělíte kód do několika malých funkcí, je obtížné ho pochopit, otestovat a udržovat.

  • Připouštíme, ž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 o větší škálovatelnost a odolnost stávajících systémů.

  • Pokud je to možné, používejte možnosti platforma jako služba (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 obecně se vyskytující aspekty do samostatné služby. Minimalizujte potřebu duplikovat kód napříč různými funkcemi a upřednostněte opakované použití služeb s dobře definovanými rozhraními, která mohou být snadno využívána různými komponentami. Pokud například několik služeb potřebuje ověřovat požadavky, můžete tuto funkci přesunout do vlastní služby. Pak můžete ověřovací službu vyvíjet. Můžete například přidat nový tok ověřování, aniž byste se dotkli 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 nejvhodnější pro váš kontext nebo požadavky. Například mikroslužby nejsou nejlepší volbou pro každou aplikaci, protože můžou způsobovat problémy se složitostí, režií a závislostmi.

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

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

  • Funkce platformy používejte, pokud splňují vaše obchodní požadavky. Pokud chcete například přesunout zatížení vývoje a správy, použijte řešení s nízkým kódem, bez kódu nebo bezserverová řešení, která nabízí váš poskytovatel cloudu.

  • Používejte knihovny a architektury.

  • Jako vývojový postup zaveřte párové programování nebo vyhrazené relace kontroly kódu.

  • Implementujte přístup k identifikaci neaktivního kódu. Buďte skeptičtí ke kódu, který automatizované testy nepokrývají.

Použití nejlepšího úložiště dat pro vaše data

V minulosti mnoho organizací ukládala všechna svá data do velkých relačních databází 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 změnit jejich strukturu pro schéma při zápisu.

  • Kolize zámků můžou mít vliv na 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. Mezi alternativy k relačním databázím patří:

  • Úložiště párů klíč-hodnota

  • 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á klady a zápory. Různé datové typy jsou vhodnější pro různé typy úložiště dat. Vyberte si technologii úložiště, která nejlépe vyhovuje vašim datům 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. Popis každého produktu je samostatný dokument. U dotazů na celý katalog můžete katalog indexovat a index uložit v Azure Cognitive Search. Inventář produktů může být součástí 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 Principy modelů úložiště dat.

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

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

  • Vezměte v úvahu typ dat, která máte. Můžete například uložit:

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

    • Dokumenty JSON v databázi dokumentů.

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

    • Protokoly aplikací v Azure Cognitive Search.

    • Objekty blob v Azure Blob Storage.

  • Upřednostnit dostupnost před konzistencí. Cap teorém znamená, že v distribuovaném systému je třeba udělat kompromisy mezi dostupností a konzistencí. Síťovým oddílům, které jsou druhou součástí CAP teorému, se nemůžete zcela vyhnout. Pokud ale chcete dosáhnout vyšší dostupnosti, můžete si osvojit model konečné konzistence.

  • Zvažte dovednosti vašeho vývojového týmu. Existují výhody použití polyglotické trvalosti, ale je možné to přehnat. Vyžaduje nové dovednosti, aby bylo možné přijmout novou technologii úložiště dat. Aby váš vývojový tým získal z této technologie co nejvíce, musí:

    • Optimalizujte dotazy.

    • Nalaď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 a vraťte zpět všechny dokončené kroky.

  • Zvažte ohraničené kontexty, což je koncept návrhu řízený 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. Produkty se například můžou zobrazovat v subdoméně katalogu produktů a v subdoméně inventáře produktů. S největší pravděpodobností ale tyto dvě subdomény 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í služba, kterou můžete použít k sestavení orchestrace s minimálním kódem.

  • Azure Logic Apps je bezserverová platforma integrace 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 distribuce zpráv publikování a odběru, která nabízí flexibilní vzorce spotřeby zpráv využívající protokoly MQTT a HTTP. S Event Gridem 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

Příklad úlohy, která určuje komponenty a jejich funkce na základě požadavků, najdete v tématu Model Spolehlivé webové aplikace.

Kontrolní seznam pro spolehlivost

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

Kontrolní seznam pro spolehlivost