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. Při vytváření aplikací založených na mikroslužbách nebo transformaci existujících aplikací na architekturu mikroslužeb je potřeba 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 posoudit vyspělost vaší aplikace, infrastruktury, DevOps, vývojového modelu a dalších možností.

Vysvětlení obchodních priorit

Abyste mohli začít vyhodnocovat architekturu mikroslužeb, musíte nejprve porozumět základním prioritám vaší firmy. Hlavní priority můžou souviset například s flexibilitou, přechodem na změny nebo rychlým vývojem. Je potřeba analyzovat, jestli je vaše architektura vhodná pro vaše základní 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 jsou některé priority, 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 k vašemu posouzení.

Zaznamenávání rozhodnutí o architektuře

Architektura mikroslužeb pomáhá týmům stát se autonomní. Týmy mohou například rozhodovat o technologiích, metodologiích a komponentách infrastruktury. Tyto volby by však měly respektovat formálně schválené zásady, které se označují 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

Abyste se vyhnuli zbytečné komunikaci mezi týmy, musíte mít správnou strukturu týmu. Architektura mikroslužeb podporuje tvorbu malých, zaměřených, křížový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 napříč funkčními, s dostatečnou kapacitou pro nezávislé sestavování a provoz souvisejících mikroslužeb?
  • Kolik času se stráví 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 Twelve-Factor

Základním cílem výběru architektury mikroslužeb je rychlejší poskytování hodnoty a adaptivní změna pomocí agilníchpostupůch 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é použití, 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. Hraniční služby 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 monolitická aplikace zůstala v pracovním stavu, dokud nebudou všechny služby rozloženy do samostatných mikroslužeb. Během oddělení můžou principy DDD pomoct 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 pomocí modulu 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 určité změny, abyste mohli volat novou službu oznámení. V dalším kroku se rozhodnete modul generování faktur transformovat. Tento modul se volá po vygenerování objednávky. K podpoře této transformace můžete použít vzory jako 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ížit 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 těchto 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 své schopnosti 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 pravomoc dosáhli.

Při vyhodnocování schopností 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 pro správu 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í implementováno?
    • Je průběžné nasazování implementováno?
    • Implementuje se průběžné monitorování?
    • Je infrastruktura jako kód (IaC) zavedená ?
  • Používáte správné nástroje pro podporu CI/CD?
  • Jak se pro aplikaci spravuje konfigurace přípravný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 hodnocení můžete v organizaci diskutovat, abyste zjistili, které oblasti 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 modelu skříně mikroslužeb?

Posouzení připravenosti infrastruktury

Při přechodu na architekturu mikroslužeb je připravenost na infrastrukturu kritickým bodem, který je potřeba zvážit. Výkon, dostupnost a škálovatelnost aplikace se projeví, 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 (DR) a rutinní plány podrobného postupu?
  • 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ů vydávání verzí

Mikroslužby jsou adaptivní ke změnám a využívají agilní vývoj ke zkrácení cyklů vydávání verzí a k vyšší hodnotě 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émantickou správu verzí?
  • Udržujete různá prostředí a šíříte stejnou verzi v sekvenci (např. do přípravného prostředí 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 ke zpracování správy verzí rozhraní API?
    • Správa verzí cesty identifikátoru URI
    • Správa verzí parametrů dotazu
    • Správa verzí typu obsahu
    • Správa verzí vlastních hlaviček
  • Máte zavedený postup pro správu verzí událostí?

Posouzení komunikace napříč službami

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

Vezměte v úvahu tyto faktory:

  • Sledujete první přístup 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 prostřednictvím synchronního komunikačního protokolu?
  • Zvažovali 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 k řešení chování mikroslužeb model Materializované zobrazení ?
  • Implementovali jste opakování, jistič, exponenciální zpoždnění a jitter pro spolehlivou komunikaci? Běžným způsobem, jak to zvládnout, je použít vzor ambasadora.
  • Definovali jste události domény, které usnadňují komunikaci 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 bez jakýchkoli změn 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, napodobující odpovědi a filtrování IP adres?
  • Používáte více bran rozhraní API k řešení potřeb různých typů klientů, jako jsou mobilní aplikace, webové aplikace a partneři?
  • Poskytuje vaše brána rozhraní API portál, kde můžou klienti zjišťovat služby a odebírat je, jako je portál pro vývojáře v Azure API Management?
  • Poskytuje vaše řešení možnosti vyrovnávání zatížení L7 nebo Web Application Firewall (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ží na řadu služeb. Jeden případ obchodního použití řeší několik mikroslužeb jako součást 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 jiný příkaz, který pak může aktivovat jinou událost a tak dále, 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í aspekty:

  • 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 transakční model ACID nebo BASE, abyste dosáhli konzistence a integrity dat?
  • Používáte dlouhotrvající operace ř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 stávají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í nového vývoje služeb?
  • Postupujete podle metodologie Twelve-Factor aplikací a používáte pro mikroslužby jediný základ kódu, izolujete závislosti a externalizujete konfiguraci?
  • Udržujete 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ž můžete s tradičními aplikacemi.

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

  • Máte strategii nasazení služeb?
  • Používáte k nasazení služeb moderní nástroje a technologie?
  • Jaký druh spolupráce se vyžaduje mezi týmy 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 Twelve-Factor aplikací?

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. To vede k výpadkům, riziku nasazení a údržbě. Monolitická aplikace může být dobře navržená s komponentami, které řeší jednotlivé obchodní domény. Ale kvůli nedostatku procesních hranic se potenciál 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í, která podporuje potřeby jejich škálovatelnosti. K dispozici jsou různé hostitelské platformy, které tyto výzvy řeší tím, že poskytují možnosti, 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é)?
  • Je hostující 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 hostingová 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 problém. Pokud ke sledování služeb používáte správnou sémantiku, můžou vaše 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 ukazatele?
  • Maskujete citlivá data během protokolování?

Posouzení přiřazení tokenu korelace

V architektuře mikroslužeb se aplikace skládá z různých mikroslužeb hostovaných nezávisle a vzájemně komunikují, aby sloužily různým případům obchodního použití. Když aplikace pracuje 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í tokenů korelace můžete načíst záznam požadavku tak, že určíte, které služby obsahují korelační token a které ne. Služby, které nemají token korelace pro tento požadavek, selhaly. Pokud dojde k selhání, můžete transakci později zopakovat. Pokud chcete vynutit idempotenci, budou požadavek obsluhovat pouze služby, které nemají token korelace.

Pokud máte například dlouhý řetězec operací, které zahrnují 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 ignorují služby, které mají v databázích tento konkrétní token korelace. 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řadí token korelace?
  • Ukládáte v databázi služby tokeny korelace?
  • Jaký je formát tokenů korelace?
  • Protokolujete tokeny korelace a další informace o požadavcích?

Vyhodnocení potřeby architektury šasi mikroslužeb

Architektura skříně mikroslužeb je základní architektura, která poskytuje možnosti pro křížové aspekty, jako je protokolování, zpracování výjimek, distribuované trasování, zabezpečení a komunikace. Když používáte architekturu skříně, zaměříte se více na implementaci hranice služby, než na interakci s funkcemi infrastruktury.

Řekněme například, že vytváříte službu správy košíků. 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 křížových obav.

Zvažte tyto faktory:

  • Používáte architekturu skříně mikroslužeb?
  • Používáte Dapr k interakci s křížový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í testování přijetí uživatelů (UAT) a produkčních prostředí. V současné době je v tomto přístupu posun, který v životním cyklu vývoje aplikací přesouvá testování brzy (vlevo). Testování zleva shift zvyšuje kvalitu aplikací, protože testování probíhá v jednotlivých fázích životního cyklu vývoje aplikací, včetně návrhu, vývoje a po vývojových fází.

Když například sestavíte aplikaci, začnete návrhem architektury. Když použijete přístup zleva posunu, otestujete návrh ohrožení zabezpečení pomocí nástrojů, jako je Microsoft Threat Modeling. Když začnete s vývojem, můžete zdrojový kód zkontrolovat spuštěním nástrojů, jako jsou statické testování zabezpečení aplikací (SAST) a pomocí dalších analyzátorů k odhalení 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é. K funkčnímu testování, chaosu, penetračnímu testování a dalším druhům testování dochází 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ý testem nebo návrh řízený chováním?
  • Testujete uživatelské scénáře? Zahrnete do uživatelských scénářů kritéria přijetí?
  • Otestujete svůj návrh pomocí nástrojů, jako je Modelování hrozeb 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 automatizované nástroje k testování aplikací?
  • Implementujete postupy Secure 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í přijatelné řešení. Tento systém by ovlivnil flexibilitu celkového systému a potenciál zavedení posunu implementace napříč službami.

Obavy týkající se zabezpečení se obvykle zpracovávají bránou API a bránou application 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 zásad OWASP Top 10 pro zachycení provozu. Nakonec odešle 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 křížové obavy zabezpečení.

Zvažte tyto faktory:

  • Vyžaduje se ověřování a autorizace pro službu?
  • 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?
  • Máte 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ě ji napsali následující přispěvatelé.

Hlavní autoři:

Pokud chcete zobrazit nepřístupné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky