Identifikace hranic mikroslužeb

Azure DevOps

Architekti a vývojáři se snaží definovat správnou velikost mikroslužby. Pokyny často zdůrazňuje, že se vyhněte extrémním konfliktům příliš velké nebo příliš malé, ale tato rada může být v praxi vágní. Pokud ale začnete od pečlivě navrženého doménového modelu, můžete snadněji definovat správnou velikost a rozsah jednotlivých mikroslužeb.

Diagram má dvě klíčové části. Jeden oddíl označený obsahem s vazbou na expedici a obsahuje následující termíny: Scheduler, Package, Delivery a Delivery history. Pět šipek ukazuje z Plánovače na následující termíny: Účty, doprava třetích stran, správa dronů, balíček a doručování. Šipka ukazuje z doručení do historie doručení.

Tento článek používá jako spuštěný příklad službu doručování pomocí dronů. Další informace o scénáři a odpovídající referenční implementaci najdete tady.

Z doménového modelu do mikroslužeb

V předchozím článku jsme definovali sadu ohraničených kontextů pro aplikaci pro doručování pomocí dronů. Pak jsme se podrobněji podívali na jeden z těchto ohraničených kontextů, expediční ohraničený kontext a identifikovali sadu entit, agregací a doménových služeb pro tento ohraničený kontext.

Teď jsme připraveni přejít z doménového modelu na návrh aplikace. Tady je přístup, který můžete použít k odvození mikroslužeb z doménového modelu.

1. Začněte ohraničeným kontextem. Obecně platí, že funkce v mikroslužbě by neměla zahrnovat více než jeden ohraničený kontext. Podle definice označuje ohraničený kontext hranici konkrétního doménového modelu. Pokud zjistíte, že mikroslužba kombinuje různé doménové modely dohromady, budete se možná muset vrátit a upřesnit analýzu domény.

2. Dále se podívejte na agregace ve vašem doménovém modelu. Agregace jsou často vhodnými kandidáty pro mikroslužby. Dobře navržená agregace vykazuje řadu charakteristik dobře navržené mikroslužby:

   • Agregace se odvozuje z obchodních požadavků, nikoli technických aspektů, jako je přístup k datům nebo zasílání zpráv.
   • Agregát by měl mít vysokou funkční soudržnost.
   • Agregace je hranice trvalosti.
   • Agregace by měly být volně svázány.

3. Doménové služby jsou také vhodnými kandidáty pro mikroslužby. Doménové služby jsou bezstavové operace napříč několika agregacemi. Typickým příkladem je pracovní postup, který zahrnuje několik mikroslužeb. Aplikace pro doručování pomocí dronů ukazuje příklad.

4. Zvažte nefunkční požadavky. Podívejte se na faktory, jako jsou velikost týmu, datové typy, technologie, požadavky na škálovatelnost, požadavky na dostupnost a požadavky na zabezpečení. Tyto faktory můžou způsobit, že mikroslužbu rozdělíte do několika menších služeb. V jiných případech můžou způsobit sloučení několika mikroslužeb do jedné mikroslužby.

Jakmile v aplikaci identifikujete mikroslužby, ověřte návrh podle následujících kritérií:

• Každá služba má jednu zodpovědnost.

• Mezi službami nejsou žádná chatty volání. Pokud rozdělení funkčnosti na dvě služby způsobí, že jsou příliš chatované, může to být příznak, že tyto funkce patří do stejné služby.

• Každá služba je dostatečně malá, aby ji mohl vytvořit malý tým, který pracuje nezávisle.

• Neexistují žádné vzájemné závislosti, které vyžadují, aby byly nasazeny dvě nebo více služeb. Každá služba by měla být nasaditelná nezávisle, aniž by bylo nutné znovu nasazovat ostatní.

• Služby nejsou úzce propojené a mohou se vyvíjet nezávisle.

• Hranice služeb jsou navržené tak, aby se vyhnuly problémům s konzistencí nebo integritou dat. V některých případech údržba konzistence dat znamená seskupení souvisejících funkcí do jedné mikroslužby. Silná konzistence ale není vždy nutná. Distribuované systémy poskytují strategie pro zpracování konečné konzistence a výhody rozkladu služeb často převáží nad složitostí správy.

Především je důležité být pragmatičtější a pamatovat si, že návrh řízený doménou je iterativní proces. V případě pochybností začněte s mikroslužbami s hrubším zrnem. Rozdělení mikroslužby na dvě menší služby je jednodušší než refaktoring funkcí napříč několika existujícími mikroslužbami.

Příklad: Definování mikroslužeb pro aplikaci pro doručování pomocí dronů

Vývojový tým dříve identifikoval čtyři agregace, doručování, balíček, drony a účet a dvě doménové služby, Plánovač a Supervisor.

Doručování a balení jsou zřejmé kandidáty pro mikroslužby. Plánovač a správce koordinuje aktivity prováděné jinými mikroslužbami, takže je vhodné tyto doménové služby implementovat jako mikroslužby.

Drony a účet jsou zajímavé, protože patří do jiných ohraničených kontextů. Jednou z možností je, aby plánovač volal kontexty vázané na drony a účet přímo. Další možností je vytvořit mikroslužby dronů a účtů v kontextu vázaném na expedici. Tyto mikroslužby by zprostředkovaly mezi ohraničenými kontexty tím, že zveřejňují rozhraní API nebo schémata dat, která jsou vhodnější pro kontext Expedice.

Podrobnosti o kontextech ohraničených dronem a účtem jsou nad rámec těchto pokynů, takže jsme pro ně vytvořili napodobené služby v naší referenční implementaci. Tady jsou ale některé faktory, které je potřeba vzít v úvahu v této situaci:

• Jaká je režijní náklady na síť volání přímo do druhého vázaného kontextu?

• Je schéma dat pro druhý ohraničený kontext vhodné pro tento kontext, nebo je lepší mít schéma přizpůsobené tomuto vázanému kontextu?

• Je druhý ohraničený kontext starší verzí systému? Pokud ano, můžete vytvořit službu, která funguje jako vrstva proti poškození , která se přeloží mezi starší verzí systému a moderní aplikací.

• Jaká je struktura týmu? Je snadné komunikovat s týmem zodpovědným za druhý ohraničený kontext? Pokud ne, vytvoření služby, která zprostředkuje mezi těmito dvěma kontexty, může pomoct zmírnit náklady na komunikaci mezi týmy.

Zatím tým nepovažoval za žádné nefunkční požadavky. Po vyhodnocení potřeb aplikace pro propustnost vytvoří vývojový tým samostatnou mikroslužbu pro příjem dat, která bude zpracovávat požadavky klientů. Tato mikroslužba implementuje vyrovnávání zatížení umístěním příchozích požadavků do vyrovnávací paměti pro zpracování. Plánovač pak načte požadavky z vyrovnávací paměti a implementuje pracovní postup.

Nefunkční požadavky také vedou tým k vytvoření jedné další služby. Stávající služby se zaměřují na plánování a doručování balíčků v reálném čase. Systém ale musí také uchovávat historii doručení v dlouhodobém úložišti pro analýzu dat. Na začátku tým považoval tuto úlohu za součást služby doručování. Požadavky na úložiště dat pro historickou analýzu se ale liší od požadavků na provoz v letu. Další informace najdete v tématu Důležité informace o datech. V důsledku toho tým vytvořil samostatnou službu Historie doručení. Tato služba naslouchá událostem DeliveryTracking ze služby Delivery Service a zapisuje je do dlouhodobého úložiště.

Následující diagram znázorňuje návrh v tomto okamžiku:

Diagram obsahuje pět klíčových oddílů. Tečkovaná šipka označená jako body fronty zpráv ze služby Příjem dat do služby Scheduler. Tečkovaná šipka ukazuje ze služby Supervisor do služby Scheduler. Pět šipek ukazuje ze služby Scheduler na následující části: Služba uživatelských účtů, doprava třetích stran, služba plánování dronů, služba balení a služba doručování. Tečkované šipkové body ze služby doručování do služby historie doručení.

Stáhněte si soubor Visio této architektury.

Další kroky

V tomto okamžiku byste měli mít jasný přehled o účelu a funkčnosti každé mikroslužby ve vašem návrhu. Teď můžete systém navrhovat.

Návrh architektury mikroslužeb

Související prostředky

• Návrh architektury mikroslužeb
• Návrh mikroslužeb pomocí taktického DDD
• použití analýzy domény k modelování mikroslužeb
• Volba výpočetní možnosti Azure pro mikroslužby

Architekti a vývojáři se snaží definovat správnou velikost mikroslužby. Pokyny často zdůrazňuje, že se vyhněte extrémním konfliktům příliš velké nebo příliš malé, ale tato rada může být v praxi vágní. Pokud ale začnete od pečlivě navrženého doménového modelu, můžete snadněji definovat správnou velikost a rozsah jednotlivých mikroslužeb.

Diagram má dvě klíčové části. Jeden oddíl označený obsahem s vazbou na expedici a obsahuje následující termíny: Scheduler, Package, Delivery a Delivery history. Pět šipek ukazuje z Plánovače na následující termíny: Účty, doprava třetích stran, správa dronů, balíček a doručování. Šipka ukazuje z doručení do historie doručení.

Tento článek používá jako spuštěný příklad službu doručování pomocí dronů. Další informace o scénáři a odpovídající referenční implementaci najdete tady.

Z doménového modelu do mikroslužeb

V předchozím článku jsme definovali sadu ohraničených kontextů pro aplikaci pro doručování pomocí dronů. Pak jsme se podrobněji podívali na jeden z těchto ohraničených kontextů, expediční ohraničený kontext a identifikovali sadu entit, agregací a doménových služeb pro tento ohraničený kontext.

Teď jsme připraveni přejít z doménového modelu na návrh aplikace. Tady je přístup, který můžete použít k odvození mikroslužeb z doménového modelu.

1. Začněte ohraničeným kontextem. Obecně platí, že funkce v mikroslužbě by neměla zahrnovat více než jeden ohraničený kontext. Podle definice označuje ohraničený kontext hranici konkrétního doménového modelu. Pokud zjistíte, že mikroslužba kombinuje různé doménové modely dohromady, budete se možná muset vrátit a upřesnit analýzu domény.

2. Dále se podívejte na agregace ve vašem doménovém modelu. Agregace jsou často vhodnými kandidáty pro mikroslužby. Dobře navržená agregace vykazuje řadu charakteristik dobře navržené mikroslužby:

   • Agregace se odvozuje z obchodních požadavků, nikoli technických aspektů, jako je přístup k datům nebo zasílání zpráv.
   • Agregát by měl mít vysokou funkční soudržnost.
   • Agregace je hranice trvalosti.
   • Agregace by měly být volně svázány.

3. Doménové služby jsou také vhodnými kandidáty pro mikroslužby. Doménové služby jsou bezstavové operace napříč několika agregacemi. Typickým příkladem je pracovní postup, který zahrnuje několik mikroslužeb. Aplikace pro doručování pomocí dronů ukazuje příklad.

4. Zvažte nefunkční požadavky. Podívejte se na faktory, jako jsou velikost týmu, datové typy, technologie, požadavky na škálovatelnost, požadavky na dostupnost a požadavky na zabezpečení. Tyto faktory můžou způsobit, že mikroslužbu rozdělíte do několika menších služeb. V jiných případech můžou způsobit sloučení několika mikroslužeb do jedné mikroslužby.

Jakmile v aplikaci identifikujete mikroslužby, ověřte návrh podle následujících kritérií:

• Každá služba má jednu zodpovědnost.

• Mezi službami nejsou žádná chatty volání. Pokud rozdělení funkčnosti na dvě služby způsobí, že jsou příliš chatované, může to být příznak, že tyto funkce patří do stejné služby.

• Každá služba je dostatečně malá, aby ji mohl vytvořit malý tým, který pracuje nezávisle.

• Neexistují žádné vzájemné závislosti, které vyžadují, aby byly nasazeny dvě nebo více služeb. Každá služba by měla být nasaditelná nezávisle, aniž by bylo nutné znovu nasazovat ostatní.

• Služby nejsou úzce propojené a mohou se vyvíjet nezávisle.

• Hranice služeb jsou navržené tak, aby se vyhnuly problémům s konzistencí nebo integritou dat. V některých případech údržba konzistence dat znamená seskupení souvisejících funkcí do jedné mikroslužby. Silná konzistence ale není vždy nutná. Distribuované systémy poskytují strategie pro zpracování konečné konzistence a výhody rozkladu služeb často převáží nad složitostí správy.

Především je důležité být pragmatičtější a pamatovat si, že návrh řízený doménou je iterativní proces. V případě pochybností začněte s mikroslužbami s hrubším zrnem. Rozdělení mikroslužby na dvě menší služby je jednodušší než refaktoring funkcí napříč několika existujícími mikroslužbami.

Příklad: Definování mikroslužeb pro aplikaci pro doručování pomocí dronů

Vývojový tým dříve identifikoval čtyři agregace, doručování, balíček, drony a účet a dvě doménové služby, Plánovač a Supervisor.

Doručování a balení jsou zřejmé kandidáty pro mikroslužby. Plánovač a správce koordinuje aktivity prováděné jinými mikroslužbami, takže je vhodné tyto doménové služby implementovat jako mikroslužby.

Drony a účet jsou zajímavé, protože patří do jiných ohraničených kontextů. Jednou z možností je, aby plánovač volal kontexty vázané na drony a účet přímo. Další možností je vytvořit mikroslužby dronů a účtů v kontextu vázaném na expedici. Tyto mikroslužby by zprostředkovaly mezi ohraničenými kontexty tím, že zveřejňují rozhraní API nebo schémata dat, která jsou vhodnější pro kontext Expedice.

Podrobnosti o kontextech ohraničených dronem a účtem jsou nad rámec těchto pokynů, takže jsme pro ně vytvořili napodobené služby v naší referenční implementaci. Tady jsou ale některé faktory, které je potřeba vzít v úvahu v této situaci:

• Jaká je režijní náklady na síť volání přímo do druhého vázaného kontextu?

• Je schéma dat pro druhý ohraničený kontext vhodné pro tento kontext, nebo je lepší mít schéma přizpůsobené tomuto vázanému kontextu?

• Je druhý ohraničený kontext starší verzí systému? Pokud ano, můžete vytvořit službu, která funguje jako vrstva proti poškození , která se přeloží mezi starší verzí systému a moderní aplikací.

• Jaká je struktura týmu? Je snadné komunikovat s týmem zodpovědným za druhý ohraničený kontext? Pokud ne, vytvoření služby, která zprostředkuje mezi těmito dvěma kontexty, může pomoct zmírnit náklady na komunikaci mezi týmy.

Zatím tým nepovažoval za žádné nefunkční požadavky. Po vyhodnocení potřeb aplikace pro propustnost vytvoří vývojový tým samostatnou mikroslužbu pro příjem dat, která bude zpracovávat požadavky klientů. Tato mikroslužba implementuje vyrovnávání zatížení umístěním příchozích požadavků do vyrovnávací paměti pro zpracování. Plánovač pak načte požadavky z vyrovnávací paměti a implementuje pracovní postup.

Nefunkční požadavky také vedou tým k vytvoření jedné další služby. Stávající služby se zaměřují na plánování a doručování balíčků v reálném čase. Systém ale musí také uchovávat historii doručení v dlouhodobém úložišti pro analýzu dat. Na začátku tým považoval tuto úlohu za součást služby doručování. Požadavky na úložiště dat pro historickou analýzu se ale liší od požadavků na provoz v letu. Další informace najdete v tématu Důležité informace o datech. V důsledku toho tým vytvořil samostatnou službu Historie doručení. Tato služba naslouchá událostem DeliveryTracking ze služby Delivery Service a zapisuje je do dlouhodobého úložiště.

Následující diagram znázorňuje návrh v tomto okamžiku:

Diagram obsahuje pět klíčových oddílů. Tečkovaná šipka označená jako body fronty zpráv ze služby Příjem dat do služby Scheduler. Tečkovaná šipka ukazuje ze služby Supervisor do služby Scheduler. Pět šipek ukazuje ze služby Scheduler na následující části: Služba uživatelských účtů, doprava třetích stran, služba plánování dronů, služba balení a služba doručování. Tečkované šipkové body ze služby doručování do služby historie doručení.

Stáhněte si soubor Visio této architektury.

Další kroky

V tomto okamžiku byste měli mít jasný přehled o účelu a funkčnosti každé mikroslužby ve vašem návrhu. Teď můžete systém navrhovat.

Návrh architektury mikroslužeb

Související prostředky

• Návrh architektury mikroslužeb
• Návrh mikroslužeb pomocí taktického DDD
• použití analýzy domény k modelování mikroslužeb
• Volba výpočetní možnosti Azure pro mikroslužby