Doporučení pro navrhování pro jednoduchost a efektivitu
Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury 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žii. Při rozhodování o návrhu, která poskytují požadované výsledky, použijte praktický a vyvážený přístup. Schovávejte svůj návrh tak, aby bylo nutné snížit neektivost a potenciální problémy. |
|---|
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 |
|---|---|
| Úloha | 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 úlohy, protože vyžaduje větší koordinaci, komunikaci a správu 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 se na návrh kritických toků , 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, která komponenta koncepčně řeší, a zvažte odebrání komponenty z jednotlivých toků, abyste zjednodušili celkový návrh a současně poskytovali 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. Další informace najdete v tématu Doporučení k 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 tématu Doporučení pro definování 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řeinženýrování nebo podinženým technikám 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.
Zřetězení toho, že všechny úspěšné aplikace se v průběhu času mění, ať už jde 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 obecně se vyskytující aspekty 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 toky, abyste mohli využít výhod 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 architektury.
Zavedení párových programovacích nebo vyhrazených relací pro kontrolu kódu jako vývojové praxe
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ě 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á 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 Vysvětlení 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 store:
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
Objekty blob 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í služba, kterou můžete použít k sestavení orchestrace s minimálním kódem.
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 distribuce zpráv publikování a odběru zpráv, která nabízí flexibilní vzorce spotřeby zpráv, které používají 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
Ukázkovou úlohu, která určuje komponenty a jejich funkce na základě požadavků, najdete v tématu Model Reliable Web App.
Související odkazy
Kontrolní seznam pro spolehlivost
Projděte si kompletní sadu doporučení.