Aspekty dat pro mikroslužby

Tento článek popisuje aspekty správy dat v architektuře mikroslužeb. Vzhledem k tomu, že každá mikroslužba spravuje vlastní data, je integrita dat a konzistence dat kritickou výzvou.

Základním principem mikroslužeb je, že každá služba spravuje svoje vlastní data. Dvě služby by neměly sdílet úložiště dat. Každá služba místo toho zodpovídá za své vlastní privátní úložiště dat, ke kterému ostatní služby nemohou přistupovat přímo.

Důvodem tohoto pravidla je vyhnout se neúmyslnému párování mezi službami, což může vést v případě, že služby sdílejí stejná podkladová datová schémata. Pokud dojde ke změně schématu dat, musí být tato změna koordinovaná v rámci každé služby, která na této databázi spoléhá. Izolováním úložiště dat jednotlivých služeb můžeme omezit rozsah změn a zachovat flexibilitu skutečně nezávislých nasazení. Dalším důvodem je to, že každá mikroslužba může mít vlastní datové modely, dotazy nebo vzory čtení a zápisu. Použití sdíleného úložiště dat omezuje schopnost každého týmu optimalizovat úložiště dat pro jejich konkrétní službu.

Tento přístup přirozeně vede k polyglotní trvalosti použití více technologií úložiště dat — v rámci jedné aplikace. Jedna služba může vyžadovat funkce schema-on-read databáze dokumentů. Další může potřebovat referenční integritu poskytovanou RDBMS. Každý tým může pro svoji službu udělat tu nejlepší volbu. Další informace o obecném principu polyglotní trvalosti najdete v tématu Použití nejlepšího úložiště dat pro úlohu.

Výzvy

Tento distribuovaný přístup ke správě dat vyvstává z některých problémů. Nejprve může být mezi úložištěmi dat redundance, kdy se stejná položka dat objeví na více místech. Data mohou být například uložena jako součást transakce a pak uložena jinde pro účely analýzy, vytváření sestav nebo archivace. Duplicitní nebo dělené údaje mohou vést k problémům s integritou a konzistencí dat. Pokud relace mezi daty zahrnují více služeb, nemůžete k vynucení těchto relací použít tradiční techniky správy dat.

Tradiční modelování dat používá pravidlo "jeden fakt na jednom místě". Každá entita se ve schématu zobrazí přesně jednou. Jiné entity na něj mohou obsahovat odkazy, ale nikoli je duplikovat. Zřejmou výhodou tradičního přístupu je, že aktualizace se provádí na jednom místě, což zabraňuje problémům s konzistencí dat. V architektuře mikroslužeb musíte zvážit, jak se aktualizace šíří napříč službami a jak spravovat konzistenci typu Případné, když se data objeví na více místech bez silné konzistence.

Přístupy ke správě dat

Neexistuje žádný jediný přístup, který je ve všech případech správný, ale tady je několik obecných pokynů pro správu dat v architektuře mikroslužeb.

• Kde je to možné, zapojte konečnou konzistenci. Porozumíte místům v systému, kde potřebujete silnou konzistenci nebo transakce ACID, a míst, kde je přijatelná případná konzistence.

• Pokud potřebujete záruky silné konzistence, může jedna služba představovat zdroj pravdivých informací pro danou entitu, která se zveřejňuje prostřednictvím rozhraní API. Další služby můžou obsahovat vlastní kopii dat nebo podmnožinu dat, která je nakonec konzistentní s hlavními daty, ale nepovažuje se za zdroj pravdivých informací. Představte si například systém elektronického obchodování se službou objednávek zákazníků a službou doporučení. Služba doporučení může naslouchat událostem ze služby objednávek, ale pokud zákazník požádá o refundaci, je to služba objednávek, nikoli služba doporučení, která obsahuje úplnou historii transakcí.

• V případě transakcí používejte vzory, jako je scheduler agent supervisor a kompenzační transakce, aby byla data konzistentní napříč několika službami. Možná budete muset uložit další část dat, která zachycuje stav jednotky práce, která zahrnuje více služeb, aby se zabránilo částečnému selhání mezi více službami. Pracovní položku můžete například ponechat v odolné frontě, zatímco probíhá vícekrokové transakce.

• Ukládejte pouze data, která služba potřebuje. Služba může potřebovat jenom podmnožinu informací o entitě domény. Například v kontextu ohraničeném expedice potřebujeme vědět, který zákazník je přidružený ke konkrétnímu doručení. Nepotřebujeme ale fakturační adresu zákazníka, kterou spravuje kontext ohraničující — účty. Tady vám může pomoct pečlivé uvažování o doméně a použití přístupu DDD.

• Zvažte, jestli jsou vaše služby koherentní a volně svázané. Pokud si dvě služby mezi sebou průběžně vyměňují informace, což vede k rozhraním API pro chatování, možná budete muset překreslit hranice služeb sloučením dvou služeb nebo refaktoringem jejich funkcí.

• Použijte styl architektury řízený událostmi. V tomto stylu architektury služba publikuje událost, když dojde ke změnám veřejných modelů nebo entit. K odběru těchto událostí se mohou přihlásit služby, které mají zájem. Jiná služba může například pomocí událostí vytvořit materializované zobrazení dat, které je vhodnější pro dotazování.

• Služba, která vlastní události, by měla publikovat schéma, které lze použít k automatizaci serializace a deserializace událostí, aby se zabránilo úzkou párování mezi vydavateli a odběrateli. Představte si schéma JSON nebo rozhraní, jako je Microsoft Bond,Protobuf nebo Avro.

• Ve velkém měřítku se události stávají kritickým bodem systému, proto zvažte použití agregace nebo dávkování, abyste snížili celkové zatížení.

Příklad: Výběr úložišť dat pro aplikaci pro doručování pomocí dronů

Předchozí články v této sérii popisují jako příklad spuštěnou službu doručování pomocí dronů. Další informace o scénáři a odpovídající referenční implementaci najdete tady.

Z rekapitulace tato aplikace definuje několik mikroslužeb pro plánování dodávek pomocí dronů. Když uživatel naplánuje nové doručení, žádost klienta obsahuje informace o doručení, jako jsou místa vyzvednutí a předání, a o balíčku, jako je například velikost a hmotnost. Tyto informace definují pracovní jednotku.

Různé back-endové služby se starají o různé části informací v požadavku a mají také různé profily čtení a zápisu.

Služba doručení

Služba Delivery ukládá informace o každém aktuálně naplánovaném nebo probíhajícím doručení. Naslouchá událostem z dronů a sleduje stav probíhajících dodávek. Odesílá také události domény s aktualizacemi stavu doručení.

Očekává se, že uživatelé budou během čekání na balíček často kontrolovat stav doručení. Proto služba Delivery service vyžaduje úložiště dat, které klade důraz na propustnost (čtení a zápis) v rámci dlouhodobého úložiště. Služba Delivery service také neprovádí žádné složité dotazy ani analýzu, jednoduše načte nejnovější stav pro dané doručení. Tým služby Delivery service si Azure Cache for Redis pro vysoký výkon čtení a zápisu. Informace uložené v Redisu jsou relativně krátkodobé. Po dokončení doručování je záznamem služba Historie doručení.

Služby historie doručení

Služba Delivery History naslouchá událostem stavu doručení ze služby Delivery Service. Tato data ukládá v dlouhodobém úložišti. Pro tato historická data existují dva různé případy použití, které mají různé požadavky na úložiště dat.

Prvním scénářem je agregace dat pro účely analýzy dat za účelem optimalizace firmy nebo zlepšení kvality služby. Všimněte si, že služba Delivery History (Historie doručení) ne provede skutečnou analýzu dat. Zodpovídá pouze za příjem dat a úložiště. V tomto scénáři musí být úložiště optimalizované pro analýzu dat na velké sadě dat s využitím přístupu schématu při čtení, aby vyhovovalo různým zdrojům dat. Azure Data Lake Store je pro tento scénář vhodný. Data Lake Store je systém souborů Apache Hadoop kompatibilní se systémem Hadoop systém souborů DFS (Distributed File System) (HDFS) a je vyladěný pro scénáře analýzy dat.

Druhý scénář umožňuje uživatelům hledat historii doručení po dokončení doručení. Azure Data Lake není pro tento scénář optimalizované. Pro zajištění optimálního výkonu Microsoft doporučuje ukládat data časových řad ve službě Data Lake do složek rozdělených podle data. (Výkon najdete v Data Lake Store Azure. Tato struktura ale není optimální pro hledání jednotlivých záznamů podle ID. Pokud časové razítko také nevíte, vyhledávání podle ID vyžaduje kontrolu celé kolekce. Proto služba Historie doručení také ukládá podmnožinu historických dat ve službě Cosmos DB pro rychlejší vyhledávání. Záznamy nemusí zůstat ve Cosmos DB. Starší dodávky je možné archivovat — například po měsíci. Můžete to provést spuštěním občasného dávkového procesu.

Balicí služba

Služba Package ukládá informace o všech balíčcích. Požadavky na úložiště balíčku:

• Dlouhodobé úložiště.
• Dokáže zpracovat velké množství balíčků, což vyžaduje vysokou propustnost zápisu.
• Podpora jednoduchých dotazů podle ID balíčku Žádná složitá spojení ani požadavky na referenční integritu.

Vzhledem k tomu, že data balíčku nejsou relační, je vhodná databáze orientovaná na dokumenty a Cosmos DB může dosáhnout vysoké propustnosti pomocí shardovaných kolekcí. Tým, který pracuje ve službě Package, zná zásobník MEAN (MongoDB, Express.js, AngularJS a Node.js), takže si vybere rozhraní MongoDB API pro Cosmos DB. Díky tomu mohou využít své stávající zkušenosti s MongoDB a současně získat výhody služby Cosmos DB, což je spravovaná služba Azure.

Další kroky

Seznamte se se vzory návrhu, které můžou pomoct zmírnit některé běžné problémy v architektuře mikroslužeb.