Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento článek popisuje aspekty správy dat v architektuře mikroslužeb. Každá mikroslužba spravuje svá vlastní data, takže integrita dat a konzistence dat představují kritické výzvy.
Dvě služby by neměly sdílet úložiště dat. Každá služba spravuje vlastní privátní úložiště dat a jiné služby k němu nemají přímý přístup. Toto pravidlo zabraňuje neúmyslnému párování mezi službami, ke kterým dochází, když služby sdílejí stejná podkladová schémata dat. Pokud se schéma dat změní, musí být změna koordinovaná napříč všemi službami, které na této databázi spoléhají. Izolace úložiště dat jednotlivých služeb omezuje rozsah změn a zachovává flexibilitu nezávislých nasazení. Každá mikroslužba může mít také jedinečné datové modely, dotazy nebo vzory čtení a zápisu. Sdílené úložiště dat omezuje schopnost jednotlivých týmů optimalizovat úložiště dat pro konkrétní službu.
Diagram znázorňuje službu A a databázi v části vlevo. Šipka označená jako body zápisu ze služby A do databáze. Služba B se nachází napravo mimo tuto konkrétní část. Šipka označená jako přečtená odkazuje na databázi. Přes tuto šipku jde červená X.
Tento přístup přirozeně vede k polyglotní trvalosti, což znamená použití více technologií úložiště dat v rámci jedné aplikace. Jedna služba může potřebovat funkce schématu při čtení databáze dokumentů. Jiná služba může potřebovat referenční integritu, kterou poskytuje systém pro správu relačních databází (RDBMS). Každý tým si může vybrat nejlepší možnost pro svou službu.
Poznámka:
Služby můžou bezpečně sdílet stejný fyzický databázový server. K problémům dochází, když služby sdílejí stejné schéma nebo čtou a zapisují do stejné sady databázových tabulek.
Výzvy
Distribuovaný přístup ke správě dat přináší několik výzev. Za prvé může dojít k redundanci napříč úložišti dat. Stejná datová položka se může objevit 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, tradiční techniky správy dat tyto relace nemůžou vynutit.
Tradiční modelování dat se řídí pravidlem jedné skutečnosti na jednom místě. Každá entita se ve schématu zobrazuje přesně jednou. Jiné entity ho můžou odkazovat, ale ne duplikovat. Hlavní výhodou tradičního přístupu je, že aktualizace probíhají na jednom místě, což brání 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
Pro všechny případy nefunguje žádný jediný přístup. Zvažte následující obecné pokyny ke správě dat v architektuře mikroslužeb:
Definujte požadovanou úroveň konzistence pro každou komponentu a pokud je to možné, upřednostněte konečnou konzistenci. Identifikujte oblasti v systému, ve kterých potřebujete silnou konzistenci nebo ACID transakce: atomicitu, konzistenci, izolaci a trvanlivost. A identifikujte oblasti, kde je konečná konzistence přijatelná. Další informace najdete v tématu Použití taktického návrhu řízeného doménou (DDD) pro mikroslužby.
Pokud potřebujete silnou konzistenci, použijte jeden zdroj pravdy. Jedna služba může představovat zdroj pravdy pro danou entitu a zveřejnit ji prostřednictvím rozhraní API. Jiné služby můžou uchovávat vlastní kopii dat nebo podmnožinu dat, která jsou nakonec konzistentní s primárními daty, ale nepovažují se za zdroj pravdy. Například v systému elektronického obchodování, který má službu objednávek zákazníků a službu doporučení, může služba doporučení naslouchat událostem ze služby objednávek. Pokud ale zákazník požádá o refundaci, služba objednávek, nikoli služba doporučení, má úplnou historii transakcí.
Použití vzorů transakcí za účelem zachování konzistence napříč službami Používejte vzory, jako je Scheduler Agent Supervisor a kompenzační transakce, abyste udržovali konzistentní data napříč různými službami. Abyste se vyhnuli částečnému selhání mezi více službami, budete možná muset uložit další část dat, která zachycuje stav jednotky práce, která zahrnuje více služeb. 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řebujete vědět, který zákazník je přidružený ke konkrétnímu doručení. Fakturační adresu zákazníka ale nepotřebujete, protože tyto informace spravuje kontext ohraničený účty. Tento princip mohou podpořit pečlivá analýza doménové problematiky a přístup Doménově řízeného designu.
Zvažte, jestli jsou vaše služby koherentní a volně svázané. Pokud dvě služby vzájemně vzájemně vyměňují informace a vytvářejí rozhraní API pro chatování, budete možná muset překreslit hranice služeb. Sloučte dvě služby nebo refaktorujte jejich funkci.
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. Ostatní služby se můžou přihlásit k odběru těchto událostí. Například jiná služba může pomocí událostí vytvořit materializované zobrazení dat, která jsou vhodnější pro dotazování.
Publikování schématu pro události Služba, která vlastní události, by měla publikovat schéma pro automatizaci serializace a deserializace událostí. Tento přístup zabraňuje úzkému párování mezi vydavateli a odběrateli. Zvažte schéma JSON nebo architekturu, jako je Protobuf nebo Avro.
Snižte kritické body událostí ve velkém měřítku. Ve velkém měřítku se události můžou stát kritickým bodem v systému. Pokud chcete snížit celkové zatížení, zvažte použití agregace nebo dávkování.
Příklad: Volba ú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 běžný příklad. Další informace o scénáři a odpovídající architektuře najdete v tématu Návrh architektury mikroslužeb.
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 je vyzvednutí a umístění pro odvoz, a o balíčku, například velikost a váha. Tyto informace definují jednotku práce.
Různé back-endové služby používají různé části informací v požadavku a mají různé profily pro čtení a zápis.
Služba doručování
Služba doručování 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í.
Uživatelé často kontrolují 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í neprovádí složité dotazy ani analýzu. Načte pouze nejnovější stav konkrétního doručení. Tým služby doručování zvolil Azure Managed Redis pro vysoký výkon čtení a zápisu. Informace uložené ve službě Azure Managed Redis jsou krátkodobé. Po dokončení doručení se služba historie doručení stane systémem záznamu.
Služba historie doručení
Služba historie doručení monitoruje události o stavu doručení z doručovací služby. Tato data se ukládají do dlouhodobého úložiště. Tato historická data podporují dva scénáře, z nichž každý má různé požadavky na úložiště.
První scénář agreguje data pro analýzu dat za účelem optimalizace podnikání nebo zlepšení kvality služeb. Služba historie doručení neprovádí skutečnou analýzu dat. Pouze ingestuje a ukládá data. V tomto scénáři musí být úložiště optimalizováno pro analýzu dat nad velkými datovými sadami a použít přístup schéma-při-čtení, který umožňuje práci s různými zdroji dat. Azure Data Lake Storage je pro tento scénář vhodný, protože je systém souborů Apache Hadoop kompatibilní se systémem souborů HDFS (Hadoop Distributed File System). Je také vyladěný pro výkon pro scénáře analýzy dat.
Druhý scénář umožňuje uživatelům vyhledat historii doručení po dokončení doručení. Data Lake Storage tento scénář nepodporuje. Pokud chcete dosáhnout optimálního výkonu, uložte data časových řad ve službě Data Lake Storage do složek rozdělených podle data. Tato struktura ale dělá jednotlivá vyhledávání založená na ID neefektivní. Pokud také neznáte časové razítko, vyhledávání ID vyžaduje, abyste prohledali celou kolekci. Kvůli vyřešení tohoto problému ukládá služba historie doručení také 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. Spuštěním občasného dávkového zpracování můžete archivovat starší dodávky po určitém časovém období, například měsíci. Archivace dat může snížit náklady na Azure Cosmos DB a zároveň zachovat dostupnost dat pro historické sestavy ze služby Data Lake Storage.
Další informace najdete v tématu Ladění služby Data Lake Storage pro výkon.
Služba balíčků
Služba balíčků ukládá informace o všech balíčcích. Úložiště dat pro službu balíčků musí splňovat následující požadavky:
- Dlouhodobé ukládání
- Vysoká propustnost zápisu pro zpracování velkého objemu balíčků
- Jednoduché dotazy podle ID balíčku bez složitých spojení nebo omezení referenční integrity
Data balíčku nejsou relační, takže databáze zaměřená na dokument funguje dobře. Azure DocumentDB může dosáhnout vysoké propustnosti pomocí horizontálně dělených kolekcí. Tým balíčkových služeb je obeznámen se zásobníkem MongoDB, Express.js, AngularJS a Node.js (MEAN), proto se rozhodli implementovat Azure DocumentDB. Tato volba jim umožní využívat své stávající prostředí MongoDB a současně získat výhody plně spravované vysoce výkonné služby Azure.