Tento článek popisuje aspekty správy dat v architektuře mikroslužeb. Vzhledem k tomu, že každá mikroslužba spravuje svá vlastní data, integrita dat a konzistence dat jsou kritické výzvy.
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. Místo toho každá služba zodpovídá za vlastní privátní úložiště dat, ke kterému ostatní služby nemají přímý přístup.
Důvodem tohoto pravidla je vyhnout se neúmyslné vazbě mezi službami, což může vést k tomu, že služby sdílejí stejná podkladová schémata dat. Pokud dojde ke změně schématu dat, musí být změna sladěná ve všech službách, které na této databázi spoléhají. 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, že každá mikroslužba může mít vlastní datové modely, dotazy nebo vzory pro čtení a zápis. Použití sdíleného úložiště dat omezuje schopnost každého týmu optimalizovat úložiště dat pro svoji 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 možnosti čtení databáze dokumentů ve schématu. Další může potřebovat referenční integritu poskytovanou rdBMS. Každý tým je volný, aby se nejlépe rozhodl pro svou službu.
Poznámka:
Je v pořádku, aby služby sdílely stejný fyzický databázový server. K tomuto problému dochází, když služby sdílejí stejné schéma nebo čtou a zapisuje do stejné sady databázových tabulek.
Problémy
Z tohoto distribuovaného přístupu ke správě dat vznikají některé problémy. Za prvé může existovat redundance napříč úložišti dat se stejnou položkou dat, která se zobrazují na více místech. Například data mohou být uložena jako součást transakce a následně uložena jinde pro analýzy, vytváření sestav nebo archivaci. Duplicitní nebo dělené data můžou vést k problémům s integritou a konzistencí dat. Pokud relace dat zahrnují více služeb, nemůžete k vynucení 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 zobrazuje přesně jednou. Jiné entity můžou obsahovat odkazy na ni, ale nemusí je duplikovat. Výhodou tradičního přístupu je, že aktualizace se provádějí 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 konečnou konzistenci, když se data zobrazují na více místech bez silné konzistence.
Přístupy ke správě dat
Ve všech případech neexistuje jediný přístup, který je 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. Seznamte se s místy v systému, kde potřebujete silnou konzistenci nebo transakce ACID, a místa, kde je přijatelná konečná konzistence.
Pokud potřebujete silné záruky konzistence, může jedna služba představovat zdroj pravdy pro danou entitu, která je vystavená prostřednictvím rozhraní API. Jiné služby můžou uchovávat vlastní kopii dat nebo podmnožinu dat, která jsou nakonec konzistentní s hlavními daty, ale nepovažují se za zdroj pravdy. 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 z objednávkové služby, ale pokud zákazník požádá o refundaci, jedná se o objednávkovou službu, nikoli službu doporučení, která má úplnou historii transakcí.
U transakcí používejte vzory, jako je správce agenta plánovače a kompenzační transakce , a udržujte tak konzistentní data napříč několika službami. Možná budete muset uložit další část dat, která zachycuje stav pracovní jednotky, která zahrnuje více služeb, aby nedocházelo k částečnému selhání mezi více službami. Pokud například probíhá vícekroková transakce, ponechte pracovní položku v trvalé frontě.
Ukládejte jenom data, která služba potřebuje. Služba může potřebovat jenom podmnožinu informací o entitě domény. Například v kontextu vázaném na expedici potřebujeme vědět, který zákazník je přidružený k určitému doručení. Nepotřebujeme ale fakturační adresu zákazníka , která je spravovaná kontextem vázaným na účty. Tady vám může pomoct pečlivé myšlení o doméně a použití přístupu DDD.
Zvažte, jestli jsou vaše služby koherentní a volně svázané. Pokud se dvě služby vzájemně vzájemně vyměňují informace, což vede k chatování rozhraní API, budete možná 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. Zájemci se mohou přihlásit k odběru těchto událostí. Jiná služba může například použít události k vytvoření materializovaného zobrazení dat, která jsou vhodnější pro dotazování.
Služba, která vlastní události, by měla publikovat schéma, které se dá použít k automatizaci serializace a deserializace událostí, aby nedocházelo k úzké vazbě mezi vydavateli a odběrateli. Zvažte schéma JSON nebo architekturu, jako je Microsoft Bond, Protobuf nebo Avro.
Ve velkém měřítku se události můžou stát kritickým bodem v systému, proto zvažte použití agregace nebo dávkování ke snížení celkového 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í službu doručování pomocí dronů jako spuštěný příklad. Další informace o scénáři a odpovídající referenční implementaci najdete tady. Tento příklad je ideální pro letecký a letecký průmysl.
Pro rekapitulace definuje tato aplikace několik mikroslužeb pro plánování dodávek pomocí dronů. Když uživatel naplánuje nové doručení, požadavek klienta obsahuje informace o doručení, jako jsou umístění vyzvednutí a odvoz, a o balíčku, jako je velikost a váha. Tyto informace definují jednotku práce.
Různé back-endové služby se zajímají o různé části informací v žádosti a také mají různé profily pro čtení a zápis.
Služba doručení
Služba delivery ukládá informace o všech aktuálně naplánovaných nebo probíhajících doručeních. 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 často kontrolovat stav doručení během čekání na balíček. Služba doručování proto vyžaduje úložiště dat, které zvýrazňuje propustnost (čtení a zápis) v dlouhodobém úložišti. Služba doručování také neprovádí žádné složité dotazy ani analýzu, jednoduše načte nejnovější stav pro dané doručení. Pro vysoký výkon čtení a zápisu si tým služby Delivery Service vybral Azure Cache for Redis. Informace uložené v Redisu jsou poměrně krátkodobé. Po dokončení doručení je služba Historie doručení systémem záznamu.
Služby historie doručení
Služba Historie doručení naslouchá událostem stavu doručení ze služby Doručení. Tato data se ukládají do dlouhodobého úložiště. 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, aby bylo možné optimalizovat firmu nebo zlepšit kvalitu služby. Všimněte si, že služba Historie doručení neprovádí 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 ve velké sadě dat pomocí přístupu schématu při čtení, aby vyhovovalo různým zdrojům dat. Azure Data Lake Store je vhodný pro tento scénář. Data Lake Store je systém souborů Apache Hadoop kompatibilní se systémem souborů HDFS (Hadoop Distributed File System) a je vyladěný pro výkon pro scénáře analýzy dat.
Dalším scénářem je umožnění uživatelům vyhledat 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 do Data Lake ve složkách rozdělených podle data. (Viz Ladění Služby Azure Data Lake Store z hlediska výkonu Tato struktura ale není optimální pro vyhledání jednotlivých záznamů podle ID. Pokud také neznáte časové razítko, vyhledávání podle ID vyžaduje skenování celé kolekce. Služba Historie doručení proto také ukládá podmnožinu historických dat ve službě Azure Cosmos DB pro rychlejší vyhledávání. Záznamy nemusí zůstat ve službě Azure Cosmos DB po neomezenou dobu. Starší dodávky je možné archivovat – řekněme po měsíci. Můžete to provést spuštěním občasné dávkového procesu. Archivace starších dat může snížit náklady na Službu Cosmos DB a přitom zachovat data dostupná pro historické generování sestav z Data Lake.
Balicí služba
Služba Package ukládá informace o všech balíčcích. Požadavky na úložiště pro balíček jsou:
- Dlouhodobé ukládání.
- Dokáže zpracovat velký objem 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 zaměřená na dokumenty a Azure Cosmos DB může dosáhnout vysoké propustnosti pomocí horizontálně dělených kolekcí. Tým, který funguje ve službě Package Service, je obeznámen se zásobníkem MEAN (MongoDB, Express.js, AngularJS a Node.js), takže vyberou rozhraní MongoDB API pro Azure Cosmos DB. Díky tomu mohou využívat své stávající prostředí s MongoDB a zároveň získat výhody služby Azure 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.