Share via

Posouzení a připravenost mikroslužeb

  • Článek

Architektura mikroslužeb může poskytovat mnoho výhod pro vaše aplikace, včetně flexibility, škálovatelnosti a vysoké dostupnosti. Spolu s těmito výhodami představuje tato architektura výzvy. Když vytváříte aplikace založené na mikroslužbách nebo transformujete existující aplikace na architekturu mikroslužeb, musíte analyzovat a posoudit aktuální situaci a identifikovat oblasti, které potřebují zlepšení.

Tato příručka vám pomůže pochopit některé aspekty, které je potřeba vzít v úvahu při přechodu na architekturu mikroslužeb. Pomocí tohoto průvodce můžete vyhodnotit vyspělost vaší aplikace, infrastruktury, DevOps, vývojového modelu a dalších možností.

Vysvětlení obchodních priorit

Pokud chcete začít vyhodnocovat architekturu mikroslužeb, musíte nejprve porozumět základním prioritám vaší firmy. Základní priority můžou souviset například s flexibilitou, přechodem na změny nebo rychlým vývojem. Potřebujete analyzovat, jestli je vaše architektura vhodná pro vaše hlavní priority. Mějte na paměti, že obchodní priority se můžou v průběhu času měnit. Inovace jsou například pro startupy nejvyšší prioritou, ale po několika letech můžou být hlavní priority spolehlivost a efektivita.

Tady je několik priorit, které je potřeba vzít v úvahu:

  • Inovace
  • Spolehlivost
  • Efektivita

Zdokumentujte smlouvy SLA, které jsou v souladu s různými částmi vaší aplikace, abyste zajistili organizační závazek, který může sloužit jako vodítko pro vaše posouzení.

Záznam rozhodnutí o architektuře

Architektura mikroslužeb pomáhá týmům stát se autonomní. Týmy můžou například rozhodovat o technologiích, metodologiích a komponentách infrastruktury. Tyto volby by však měly respektovat formálně odsouhlasené zásady označované jako sdílené zásady správného řízení, které vyjadřují dohodu mezi týmy o tom, jak řešit širší strategii pro mikroslužby.

Zvažte tyto faktory:

  • Používá se sdílené zásady správného řízení?
  • Sledujete rozhodnutí a jejich kompromisy v deníku architektury?
  • Může váš tým snadno získat přístup k vašemu deníku architektury?
  • Máte proces vyhodnocení nástrojů, technologií a architektur?

Posouzení složení týmu

Potřebujete mít správnou strukturu týmu, abyste se vyhnuli zbytečné komunikaci mezi týmy. Architektura mikroslužeb podporuje tvorbu malých, zaměřených, multifunkčních týmů a vyžaduje změnu myšlení, která musí předcházet restrukturalizaci týmu.

Zvažte tyto faktory:

  • Rozdělují se vaše týmy na základě subdomén podle principů návrhu řízeného doménou (DDD)?
  • Jsou vaše týmy vzájemně funkční s dostatečnou kapacitou pro nezávislé sestavování a provoz souvisejících mikroslužeb?
  • Kolik času strávíte v ad hoc aktivitách a úkolech, které nesouvisí s projekty?
  • Kolik času strávíte při spolupráci mezi týmy?
  • Máte proces identifikace a minimalizace technického dluhu?
  • Jak se učí lekce a zkušenosti komunikují napříč týmy?

Použití metodologie dvanáctifaktorového faktoru

Základním cílem výběru architektury mikroslužeb je zajistit hodnotu rychleji a přizpůsobit se změnám pomocí agilních postupů. Metodologie dvanáctifaktorové aplikace poskytuje pokyny pro vytváření udržovatelných a škálovatelných aplikací. Tyto pokyny podporují atributy, jako je neměnnost, dočasné fungování, deklarativní konfigurace a automatizace. Začleněním těchto pokynů a zabráněním běžným nástrahám můžete vytvářet volně svázané mikroslužby s vlastním obsahem.

Vysvětlení přístupu k rozkladu

Transformace monolitické aplikace na architekturu mikroslužeb nějakou dobu trvá. Začněte s hraničními službami. Služby Edge mají méně závislostí na jiných službách a dají se snadno rozložit ze systému jako nezávislé služby. Důrazně doporučujeme vzory, jako je Strangler Fig a Anti-corruption Layer , aby se monolitická aplikace zachovala v pracovním stavu, dokud se všechny služby nerozloží do samostatných mikroslužeb. Během oddělení můžou principy DDD pomoci týmům zvolit komponenty nebo služby z monolitické aplikace založené na subdoménách.

Například v systému elektronického obchodování můžete mít tyto moduly: košík, správa produktů, správa objednávek, ceny, generování faktur a oznámení. Rozhodnete se spustit transformaci aplikace s modulem oznámení, protože nemá závislosti na jiných modulech. Jiné moduly ale můžou záviset na tomto modulu, aby odesílaly oznámení. Modul oznámení se dá snadno rozdělit do samostatné mikroslužby, ale budete muset v monolitické aplikaci provést nějaké změny, abyste mohli volat novou službu oznámení. V dalším kroku se rozhodnete transformovat modul generování faktur. Tento modul se volá po vygenerování objednávky. K podpoře této transformace můžete použít vzory, jako je Strangler a Anti-corruption.

Synchronizace dat, více zápisů do monolitických rozhraní i rozhraní mikroslužeb, vlastnictví dat, rozklad schématu, spojení, objem dat a integrita dat můžou ztěžovat rozpis a migraci dat. Existuje několik technik, které můžete použít, jako je zachování sdílené databáze mezi mikroslužbami, oddělení databází od skupiny služeb na základě obchodních schopností nebo domény a izolace databází ze služeb. Doporučeným řešením je dekompilovat každou databázi s každou službou. Za mnoha okolností to není praktické. V takových případech můžete použít vzory, jako je model Zobrazení databáze a model služby Database Wrapping Service.

Posouzení připravenosti DevOps

Když přejdete na architekturu mikroslužeb, je důležité posoudit svou kompetenci DevOps. Architektura mikroslužeb je určená k usnadnění agilního vývoje v aplikacích, aby se zvýšila flexibilita organizace. DevOps je jedním z klíčových postupů, které byste měli implementovat, abyste tuto kompetenci dosáhli.

Při vyhodnocování schopnosti DevOps pro architekturu mikroslužeb mějte na paměti tyto body:

  • Vědí lidé ve vaší organizaci základní postupy a principy DevOps?
  • Rozumí týmy nástrojům správy zdrojového kódu a jejich integraci s kanály CI/CD?
  • Implementujete správně postupy DevOps?
    • Dodržujete agilní postupy?
    • Implementuje se kontinuální integrace?
    • Je průběžné doručování implementované?
    • Je průběžné nasazování implementované?
    • Je průběžné monitorování implementované?
    • Používá se infrastruktura jako kód (IaC) ?
  • Používáte správné nástroje pro podporu CI/CD?
  • Jak se pro aplikaci spravuje konfigurace pracovních a produkčních prostředí?
  • Má řetězec nástrojů podporu komunity a model podpory a poskytuje správné kanály a dokumentaci?

Identifikace obchodních oblastí, které se často mění

Architektura mikroslužeb je flexibilní a přizpůsobitelná. Během posuzování můžete v organizaci diskutovat, abyste zjistili, které oblasti se budou vaši kolegové často měnit. Vytváření mikroslužeb umožňuje týmům rychle reagovat na změny, které zákazníci požadují, a minimalizovat úsilí o regresní testování. V monolitické aplikaci vyžaduje změna v jednom modulu řadu úrovní regresního testování a snižuje flexibilitu při vydávání nových verzí.

Zvažte tyto faktory:

  • Je služba nezávisle nasaditelná?
  • Dodržuje služba zásady DDD?
  • Dodržuje služba principy SOLID?
  • Je databáze pro službu soukromá?
  • Vytvořili jste službu pomocí podporovaného vzoru skříně mikroslužeb?

Posouzení připravenosti infrastruktury

Při přechodu na architekturu mikroslužeb je připravenost infrastruktury kritickým bodem, který je potřeba zvážit. Výkon, dostupnost a škálovatelnost aplikace budou ovlivněny, pokud není infrastruktura správně nastavená nebo pokud se nepoužívají správné služby nebo komponenty. Někdy se aplikace vytvoří se všemi navrhovanými metodologiemi a postupy, ale infrastruktura je nedostatečná. Výsledkem je nízký výkon a údržba.

Při vyhodnocování připravenosti infrastruktury zvažte tyto faktory:

  • Zajišťuje infrastruktura škálovatelnost nasazených služeb?
  • Podporuje infrastruktura zřizování prostřednictvím skriptů, které je možné automatizovat prostřednictvím CI/CD?
  • Nabízí infrastruktura nasazení smlouvu SLA pro dostupnost?
  • Máte plán zotavení po havárii a plány rutinních postupů?
  • Replikují se data do různých oblastí zotavení po havárii?
  • Máte plán zálohování dat?
  • Jsou zdokumentované možnosti nasazení?
  • Monitoruje se infrastruktura nasazení?
  • Podporuje infrastruktura nasazení samoobslužné opravy služeb?

Vyhodnocení cyklů vydaných verzí

Mikroslužby jsou adaptivní na změnu a využívají agilní vývoj ke zkrácení cyklů vydávání verzí a vyšší hodnotu zákazníkům. Při vyhodnocování cyklů vydávání verzí zvažte tyto faktory:

  • Jak často vytváříte a vydáváte aplikace?
  • Jak často se vaše vydané verze po nasazení nezdaří?
  • Jak dlouho trvá zotavení nebo náprava problémů po výpadku?
  • Používáte pro své aplikace sémantické správy verzí?
  • Udržujete různá prostředí a šíříte stejnou verzi v sekvenci (např. nejprve do přípravy a potom do produkčního prostředí)?
  • Používáte správu verzí pro svá rozhraní API?
  • Dodržujete správné pokyny pro správu verzí pro rozhraní API?
  • Kdy změníte verzi rozhraní API?
  • Jaký je váš přístup pro zpracování verzí rozhraní API?
    • Správa verzí cesty URI
    • Správa verzí parametrů dotazu
    • Správa verzí typu obsahu
    • Správa verzí vlastní hlavičky
  • Máte zavedený postup pro správu verzí událostí?

Posouzení komunikace mezi službami

Mikroslužby jsou samostatné služby, které vzájemně komunikují napříč hranicemi procesů a řeší obchodní scénáře. Pokud chcete získat spolehlivou a spolehlivou komunikaci, musíte vybrat odpovídající komunikační protokol.

Vezměte v úvahu tyto faktory:

  • Sledujete přístup založený na rozhraní API, kde se rozhraní API považují za prvotřídní občany?
  • Máte dlouhotrvající operace, kdy více služeb komunikuje v posloupnosti přes synchronní komunikační protokol?
  • Zvážili jste asynchronní komunikaci kdekoli v systému?
  • Posoudili jste technologii zprostředkovatele zpráv a její schopnosti?
  • Rozumíte propustnosti zpráv, které služby přijímají a zpracovávají?
  • Používáte přímou komunikaci mezi klientem?
  • Potřebujete zachovat zprávy na úrovni zprostředkovatele zpráv?
  • Používáte model materializovaného zobrazení k řešení chatty chování mikroslužeb?
  • Implementovali jste opakování, jistič, exponenciální zpoždování a jitter pro spolehlivou komunikaci? Běžným způsobem, jak to vyřešit, je použít vzor ambasadora.
  • Definovali jste události domény pro usnadnění komunikace mezi mikroslužbami?

Vyhodnocení toho, jak jsou služby vystaveny klientům

Brána rozhraní API je jednou ze základních komponent v architektuře mikroslužeb. Přímé zveřejnění služeb klientům vytváří problémy z hlediska spravovatelnosti, řízení a spolehlivé komunikace. Brána rozhraní API slouží jako proxy server, zachycuje provoz a směruje ho do back-endových služeb. Pokud potřebujete filtrovat provoz podle IP adresy, autorizace, napodobení odpovědí atd., můžete to udělat na úrovni brány rozhraní API, aniž byste museli provádět změny služeb.

Vezměte v úvahu tyto faktory:

  • Využívají služby přímo klienti?
  • Je brána rozhraní API, která funguje jako fasáda pro všechny služby?
  • Může brána rozhraní API nastavit zásady, jako jsou limity kvót, napodobování odpovědí a filtrování IP adres?
  • Používáte k řešení potřeb různých typů klientů, jako jsou mobilní aplikace, webové aplikace a partneři více bran rozhraní API?
  • Poskytuje vaše brána rozhraní API portál, kde můžou klienti zjišťovat a odebírat služby, jako je portál pro vývojáře ve službě Azure API Management?
  • Poskytuje vaše řešení funkce vyrovnávání zatížení L7 nebo firewall webových aplikací (WAF) společně s bránou rozhraní API?

Vyhodnocení zpracování transakcí

Distribuované transakce usnadňují provádění více operací jako jednu jednotku práce. V architektuře mikroslužeb se systém rozloží do mnoha služeb. Jeden případ obchodního použití řeší několik mikroslužeb v rámci jedné distribuované transakce. V distribuované transakci je příkaz operací, která se spustí při výskytu události. Událost aktivuje operaci v systému. Pokud je operace úspěšná, může aktivovat další příkaz, který pak může aktivovat jinou událost atd., dokud nebudou všechny transakce dokončeny nebo vráceny zpět v závislosti na tom, zda transakce proběhne úspěšně.

Vezměte v úvahu následující skutečnosti:

  • Kolik distribuovaných transakcí je v systému?
  • Jaký je váš přístup ke zpracování distribuovaných transakcí? Vyhodnoťte použití vzoru Saga s orchestrací nebo hierarchií.
  • Kolik transakcí zahrnuje více služeb?
  • Sledujete model transakce ACID nebo BASE, abyste dosáhli konzistence a integrity dat?
  • Používáte operace dlouhodobého řetězení pro transakce, které zahrnují více služeb?

Posouzení modelu vývoje služeb

Jednou z největších výhod architektury mikroslužeb je technologická rozmanitost. Systémy založené na mikroslužbách umožňují týmům vyvíjet služby pomocí technologií, které si zvolí. V tradičním vývoji aplikací můžete při sestavování nových komponent znovu použít existující kód nebo vytvořit interní vývojovou architekturu, která snižuje úsilí o vývoj. Použití více technologií může zabránit opakovanému použití kódu.

Zvažte tyto faktory:

  • Používáte šablonu služby k zahájení vývoje nových služeb?
  • Postupujete podle metodologie aplikace Twelve-Factor a používáte jeden základ kódu pro mikroslužby, izolujete závislosti a externalizujete konfiguraci?
  • Uchováváte citlivou konfiguraci v trezorech klíčů?
  • Kontejnerizujete své služby?
  • Znáte požadavky na konzistenci dat?

Posouzení přístupu k nasazení

Váš přístup k nasazení je metoda vydávání verzí aplikace v různých prostředích nasazení. Systémy založené na mikroslužbách poskytují flexibilitu vydávání verzí rychleji, než je možné s tradičními aplikacemi.

Při posuzování plánu nasazení zvažte tyto faktory:

  • Máte strategii pro nasazení služeb?
  • Používáte k nasazení služeb moderní nástroje a technologie?
  • Jaký druh spolupráce se mezi týmy vyžaduje při nasazování služeb?
  • Zřizujete infrastrukturu pomocí infrastruktury jako kódu (IaC)?
  • Používáte možnosti DevOps k automatizaci nasazení?
  • Rozšíříte stejné buildy do více prostředí, jak navrhuje metodologie aplikace Twelve-Factor?

Posouzení hostitelské platformy

Škálovatelnost je jednou z klíčových výhod architektury mikroslužeb. Je to proto, že mikroslužby se mapují na obchodní domény, takže každou službu je možné škálovat nezávisle. Monolitická aplikace se nasadí jako jedna jednotka na hostitelské platformě a musí se škálovat holisticky. Výsledkem je výpadek, riziko nasazení a údržba. Monolitická aplikace může být dobře navržená s komponentami, které řeší jednotlivé obchodní domény. Ale kvůli nedostatku hranic procesu se potenciál pro porušení zásad jedné odpovědnosti stává obtížnější. Výsledkem je nakonec špagetový kód. Vzhledem k tomu, že se aplikace skládá a nasazuje jako jeden proces hostování, je škálovatelnost obtížná.

Mikroslužby umožňují týmům zvolit správnou platformu pro hostování, aby podporovaly potřeby škálovatelnosti. K dispozici jsou různé hostitelské platformy, které tyto problémy řeší tím, že poskytují funkce, jako je automatické škálování, elastické zřizování, vyšší dostupnost, rychlejší nasazení a snadné monitorování.

Zvažte tyto faktory:

  • Jakou hostingovou platformu používáte k nasazení služeb (virtuální počítače, kontejnery, bezserverové prostředí)?
  • Je hostitelská platforma škálovatelná? Podporuje automatické škálování?
  • Jak dlouho trvá škálování hostitelské platformy?
  • Rozumíte smlouvám SLA, které poskytují různé hostitelské platformy?
  • Podporuje vaše hostitelská platforma zotavení po havárii?

Posouzení monitorování služeb

Monitorování je důležitým prvkem aplikace založené na mikroslužbách. Vzhledem k tomu, že je aplikace rozdělená na řadu služeb, které běží nezávisle, může být odstraňování chyb nepříjemné. Pokud ke sledování služeb používáte správnou sémantiku, můžou týmy snadno monitorovat, zkoumat a reagovat na chyby.

Zvažte tyto faktory:

  • Monitorujete nasazené služby?
  • Máte mechanismus protokolování? Jaké nástroje používáte?
  • Máte distribuovanou infrastrukturu trasování?
  • Zaznamenáváte výjimky?
  • Udržujete kódy obchodních chyb pro rychlou identifikaci problémů?
  • Používáte sondy stavu pro služby?
  • Používáte sémantické protokolování? Implementovali jste klíčové metriky, prahové hodnoty a indikátory?
  • Maskujete citlivá data během protokolování?

Posouzení přiřazení korelačního tokenu

V architektuře mikroslužeb se aplikace skládá z různých mikroslužeb, které jsou hostované nezávisle a vzájemně spolupracují, aby sloužily různým případům obchodního použití. Když aplikace komunikuje s back-endovými službami k provedení operace, můžete k požadavku přiřadit jedinečné číslo označované jako korelační token. Doporučujeme zvážit použití korelačních tokenů, protože vám můžou pomoct s řešením chyb. Pomáhají vám určit původní příčinu problému, posoudit dopad a určit přístup k nápravě problému.

Pomocí korelačních tokenů můžete načíst záznam požadavku tak, že zjistíte, které služby obsahují token korelace a které ne. Služby, které nemají token korelace pro tento požadavek, selhaly. Pokud dojde k selhání, můžete později zkusit transakci zopakovat. Pokud chcete vynutit idempotenci, budou požadavek poskytovat jenom služby, které nemají token korelace.

Pokud máte například dlouhý řetěz operací, který zahrnuje mnoho služeb, předání korelačního tokenu službám vám může pomoct snadno prozkoumat problémy, pokud některá ze služeb selže během transakce. Každá služba má obvykle vlastní databázi. Token korelace se uchovává v záznamu databáze. V případě přehrání transakce služby, které mají v databázích konkrétní korelační token, požadavek ignorují. Požadavek obsluhuje jenom služby, které token nemají.

Zvažte tyto faktory:

  • V jaké fázi přiřadíte token korelace?
  • Která komponenta přiřazuje korelační token?
  • Ukládáte tokeny korelace do databáze služby?
  • Jaký je formát korelačních tokenů?
  • Protokolujete korelační tokeny a další informace o požadavcích?

Vyhodnocení potřeby architektury skříně mikroslužeb

Architektura skříně mikroslužeb je základní architektura, která poskytuje možnosti pro průřezové aspekty, jako je protokolování, zpracování výjimek, distribuované trasování, zabezpečení a komunikace. Při použití architektury skříně se zaměříte spíše na implementaci hranice služby než na interakci s funkcemi infrastruktury.

Řekněme například, že vytváříte službu správy košíku. Chcete ověřit příchozí token, zapisovat protokoly do databáze protokolování a komunikovat s jinou službou vyvoláním koncového bodu této služby. Pokud používáte architekturu skříně mikroslužeb, můžete snížit úsilí o vývoj. Dapr je jeden systém, který poskytuje různé stavební bloky pro implementaci napříč aspekty.

Zvažte tyto faktory:

  • Používáte architekturu skříně mikroslužeb?
  • Používáte Dapr k interakci s průřezovými obavami?
  • Je váš jazyk architektury skříně nezávislý?
  • Je architektura skříně obecná, takže podporuje všechny druhy aplikací? Architektura skříně by neměla obsahovat logiku specifickou pro aplikaci.
  • Poskytuje architektura skříně mechanismus pro použití vybraných komponent nebo služeb podle potřeby?

Posouzení přístupu k testování aplikací

Tradičně se testování provádí po dokončení vývoje a aplikace je připravená k zavedení do uživatelských akceptačních testů (UAT) a produkčních prostředí. V současné době dochází ke změně tohoto přístupu a přesouvání testování v životním cyklu vývoje aplikací na začátku (vlevo). Testování s posunem doleva zvyšuje kvalitu aplikací, protože testování se provádí během každé fáze životního cyklu vývoje aplikací, včetně fází návrhu, vývoje a následného vývoje.

Například při vytváření aplikace začnete návrhem architektury. Při použití přístupu posunu doleva otestujete návrh ohrožení zabezpečení pomocí nástrojů, jako je Modelování hrozeb Od Microsoftu. Když začnete s vývojem, můžete zdrojový kód zkontrolovat spuštěním nástrojů, jako je testování zabezpečení statických aplikací (SAST) a používáním dalších analyzátorů k odkrytí problémů. Po nasazení aplikace můžete k otestování použít nástroje, jako je dynamické testování zabezpečení aplikací (DAST), zatímco je hostované. Funkční testování, chaos testování, penetrační testování a další druhy testování probíhají později.

Zvažte tyto faktory:

  • Píšete testovací plány, které pokrývají celý životní cyklus vývoje?
  • Zahrnete testery do schůzek požadavků a do celého životního cyklu vývoje aplikací?
  • Používáte návrh řízený testy nebo návrh řízený chováním?
  • Testujete uživatelské scénáře? Zahrnete do uživatelských scénářů kritéria přijetí?
  • Testujete návrh pomocí nástrojů, jako je Modelování hrozeb Od Microsoftu?
  • Píšete testy jednotek?
  • Používáte k měření kvality kódu statické analyzátory kódu nebo jiné nástroje?
  • Používáte k testování aplikací automatizované nástroje?
  • Implementujete postupy zabezpečeného DevOps ?
  • Děláte integrační testování, kompletní testování aplikací, zátěžové a výkonové testování, penetrační testování a chaosové testování?

Posouzení zabezpečení mikroslužeb

Mezi nejdůležitější aspekty architektury mikroslužeb patří ochrana služeb, zabezpečený přístup a zabezpečená komunikace. Například systém založený na mikroslužbách, který zahrnuje více služeb a používá ověřování tokenů pro každou službu, není realizovatelné řešení. Tento systém by ovlivnil flexibilitu celkového systému a potenciál zavedení posunu implementace napříč službami.

Problémy se zabezpečením obvykle zpracovává brána rozhraní API a aplikační brána firewall. Brána a brána firewall provádějí příchozí požadavky, ověřují tokeny a používají různé filtry a zásady, jako je implementace principů OWASP Top 10 pro zachycení provozu. Nakonec odešlou požadavek do back-endových mikroslužeb. Tato konfigurace pomáhá vývojářům soustředit se spíše na obchodní potřeby než na průřezové obavy zabezpečení.

Zvažte tyto faktory:

  • Vyžaduje se pro službu ověřování a autorizace?
  • Používáte bránu rozhraní API k ověření tokenů a příchozích požadavků?
  • Používáte protokol SSL nebo mTLS k zajištění zabezpečení komunikace se službami?
  • Existují zásady zabezpečení sítě, které umožňují požadovanou komunikaci mezi službami?
  • Používáte brány firewall (L4, L7), pokud je to možné, abyste zajistili zabezpečení pro interní a externí komunikaci?
  • Používáte zásady zabezpečení ve službě API Gateway k řízení provozu?

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky