Jaká je správná velikost mikroslužby? Často uslyšíte něco, co má za následek " není příliš velký a ne příliš malý" – a i když je to určitě správně, není to v praxi příliš užitečné. Pokud ale začnete od pečlivě navrženého doménového modelu, je mnohem jednodušší uvažovat o mikroslužbách.
V tomto článku se jako příklad používá služba doručování pomocí dronů. Další informace o scénáři a odpovídající referenční implementaci si můžete přečíst tady.
Od doménového modelu k mikroslužbám
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ů, kontext s ohraničeným odesláním, a identifikovali jsme sadu entit, agregací a doménových služeb pro tento ohraničený kontext.
Nyní jsme připraveni k přechodu od doménového modelu k návrhu aplikace. Tady je postup, který můžete použít k odvození mikroslužeb z doménového modelu.
Začněte ohraničeným kontextem. Obecně platí, že funkčnost v mikroslužbě by neměla zahrnovat více než jeden ohraničený kontext. Podle definice ohraničený kontext označuje hranici konkrétního doménového modelu. Když zjistíte, že mikroslužba kombinuje dohromady různé doménové modely, je to znamení, že může být potřeba vrátit se zpět a zpřesnit analýzu domény.
Dále se podívejte na agregáty v doménovém modelu. Agregáty jsou často vhodnými kandidáty pro mikroslužby. Dobře navržený agregát vykazuje řadu charakteristik dobře navržené mikroslužby, například:
- Agregát se odvozuje z obchodních požadavků, nikoli z technických aspektů, jako je třeba přístup k datům nebo zasílání zpráv.
- Agregát by měl mít vysokou funkční soudržnost.
- Agregát je hranicí trvalosti.
- Agregáty by měly být volně propojené.
Doménové služby jsou také vhodnými kandidáty pro mikroslužby. Doménové služby jsou bezstavové operace napříč více agregáty. Typickým příkladem je pracovní postup, který zahrnuje několik mikroslužeb. Jejich příklad uvidíme v aplikaci pro doručování pomocí dronů.
Nakonec zvažte požadavky, které se netýkají funkcí. Podívejte se na faktory, jako jsou například velikost týmu, datové typy, technologie, požadavky na škálovatelnost, požadavky na dostupnost a požadavky na zabezpečení. Tyto faktory vás můžou přivést k dalšímu rozložení mikroslužby na dvě nebo více menších služeb nebo naopak ke sloučení několika mikroslužeb do jedné.
Po identifikaci mikroslužeb ve vaší aplikaci ověřte návrh podle následujících kritérií:
- Každá služba má jednu odpovědnost.
- Mezi službami nejsou žádná hovorná volání. Pokud rozdělení funkcí na dvě služby způsobuje přílišnou konverzaci, může to být příznakem toho, že tyto funkce patří do stejné služby.
- Každá služba je dostatečně malá, aby ji mohl vytvořit malý tým pracující nezávisle na sobě.
- Neexistují žádné vzájemné závislosti, které by vyžadovaly nasazení dvou nebo více služeb v kroku uzamčení. Vždy by mělo být možné nasadit službu bez opětovného nasazení jiných služeb.
- Služby nejsou úzce propojené a mohou se vyvíjet nezávisle.
- Hranice služeb nebudou vytvářet problémy s konzistencí nebo integritou dat. Někdy je důležité zachovat konzistenci dat vložením funkcí do jedné mikroslužby. Přesto zvažte, jestli skutečně potřebujete silnou konzistenci. Existují strategie pro řešení konečné konzistence v distribuovaném systému a výhody rozkladových služeb často převáží výzvy spojené se správou konečné konzistence.
Důležitá je především účelnost. A nezapomínejte na to, že návrh řízený doménou je iterativní proces. V případě pochybností začněte s hruběji rozdělenými mikroslužbami. Rozdělení mikroslužby na dvě menší služby je snadnější než refaktoring funkčnosti napříč několika existujícími mikroslužbami.
Příklad: Definování mikroslužeb pro aplikaci pro doručování pomocí dronů
Vzpomeňte si, že vývojový tým identifikoval čtyři agregace – Delivery (Doručování), Package (Balíček), Drone (Dron) a Account (Účet) a dvě doménové služby – Scheduler a Supervisor.
Doručení a balíček jsou očividnými kandidáty pro mikroslužby. Plánovač a správce koordinují aktivity prováděné jinými mikroslužbami, takže je vhodné implementovat tyto doménové služby jako mikroslužby.
Dron a Účet jsou zajímavé, protože patří do jiných ohraničených kontextů. Jednou z možností je, že Plánovač může přímo volat kontexty ohraničené dronem a účtem. Další možností je vytvořit mikroslužby dronů a účtů v kontextu ohraničeného odesláním. Tyto mikroslužby se zprostředkovávají mezi ohraničenými kontexty tím, že by se zobrazila 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ů, proto jsme pro ně v referenční implementaci vytvořili napodobenou službu. V této situaci byste ale měli zvážit některé faktory:
Jaká je síťová režie při volání přímo do druhého ohraničené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 ohraničení kontextu?
Je druhý ohraničený kontext starší verzí systému? Pokud ano, můžete vytvořit službu, která funguje jako vrstva odolná proti poškození , která překládá mezi starší verzí systému a moderní aplikací.
Jaká je struktura týmu? Je snadné komunikovat s týmem, který zodpovídá za druhý ohraničený kontext? Pokud ne, vytvoření služby, která zprostředkuje mezi těmito dvěma kontexty, může pomoct snížit náklady na komunikaci mezi týmy.
Zatím jsme nemysleli na žádné požadavky, které nejsou funkční. Vývojový tým přemýšlel o požadavcích aplikace na propustnost a rozhodl se vytvořit samostatnou mikroslužbu pro příjem dat, která je zodpovědná za příjem požadavků klientů. Tato mikroslužba implementuje vyrovnávání zatížení vložením příchozích požadavků do vyrovnávací paměti ke zpracování. Plánovač načte požadavky z vyrovnávací paměti a spustí pracovní postup.
Požadavky na nefunkční funkce vedly tým k vytvoření jedné další služby. Všechny služby se zatím chytly o plánování a doručování balíčků v reálném čase. Systém ale také potřebuje uchovávat historii každého doručení v dlouhodobém úložišti pro účely analýzy dat. Tým to považoval za zodpovědnost doručovací služby. Požadavky na úložiště dat se ale pro historickou analýzu a provoz za letu zcela liší (viz Aspekty dat). Proto se tým rozhodl vytvořit samostatnou službu Historie doručení, která bude naslouchat událostem DeliveryTracking ze služby Delivery Service a zapisovat události do dlouhodobého úložiště.
Následující diagram znázorňuje návrh v tomto bodě:
Stáhněte si soubor aplikace Visio s touto architekturou.
Další kroky
V tuto chvíli byste měli mít jasnou představu o účelu a funkčnosti jednotlivých mikroslužeb v návrhu. Teď můžete systém navrhovat.