Architektura mikroslužeb:
Z mého , musíte mít základní znalosti o architektuře Microservice Architecture.Ale být profesionálem bude vyžadovat více než jen základy. V tomto blogu se dostanete do hloubky architektonických konceptů a implementujete je pomocí případové studie UBER.
V tomto blogu se dozvíte o následujících tématech:
- Definice architektury mikroslužeb
- Klíčové koncepty architektury mikroslužeb
- Klady a zápory architektury mikroslužeb
- UBER - případová studie
Můžete se obrátit na , porozumět základům a výhodám Microservices.
Bude to spravedlivé, pouze pokud vám poskytnu definici Microservices.
Definice mikroslužeb
Neexistuje tedy žádná správná definice Microservices aka Microservice Architecture, ale můžete říci, že se jedná o rámec, který se skládá z malých, jednotlivě nasaditelných služeb provádějících různé operace.
Mikroslužby se zaměřují na jednu obchodní doménu, kterou lze implementovat jako plně nezávislé nasaditelné služby a implementovat je na různých technologických zásobnících.
Obrázek 1: Rozdíl mezi monolitickou architekturou a architekturou mikroslužeb - architektura mikroslužeb
Viz výše uvedený diagram, abyste pochopili rozdíl mezi monolitickou a mikroslužbou.Pro lepší pochopení rozdílů mezi oběma architekturami se můžete podívat na můj předchozí blog
Abychom vám lépe porozuměli, řeknu vám několik klíčových konceptů architektury mikroslužeb.
jak používat funkci split v pythonu
Klíčové koncepty architektury mikroslužeb
Než začnete vytvářet vlastní aplikace pomocí mikroslužeb, musíte mít jasno v rozsahu a funkcích vaší aplikace.
Následuje několik pokynů, které je třeba dodržovat při projednávání mikroslužeb.
Pokyny při navrhování mikroslužeb
- Jako vývojář, když se rozhodnete vytvořit aplikaci, oddělte domény a buďte jasní s funkcemi.
- Každá mikroslužba, kterou navrhnete, se soustředí pouze na jednu službu aplikace.
- Ujistěte se, že jste aplikaci navrhli takovým způsobem, že každá služba je jednotlivě nasaditelná.
- Ujistěte se, že komunikace mezi mikroslužbami probíhá prostřednictvím serveru bez státní příslušnosti.
- Každá služba může být dále refaktorována do menších služeb, které mají své vlastní mikroslužby.
Nyní, když jste si při navrhování mikroslužeb přečetli základní pokyny, pojďme pochopit architekturu mikroslužeb.
Jak funguje architektura mikroslužeb?
Typická architektura mikroslužeb (MSA) by měla sestávat z následujících komponent:
- Klienti
- Poskytovatelé identity
- Gateway API
- Formáty zpráv
- Databáze
- Statický obsah
- Řízení
- Vyhledání služby
Viz níže uvedený diagram.
Obrázek 2: Architecture Of Microservices - Microservice Architecture
Vím, že architektura vypadá trochu složitě, ale dovolteJázjednodušit to pro vás.
1. Klienti
Architektura začíná u různých typů klientů, od různých zařízení, která se snaží provádět různé možnosti správy, jako je vyhledávání, sestavování, konfigurace atd.
2. Poskytovatelé identity
Tyto požadavky od klientů jsou poté předány poskytovatelům identity, kteří ověřují požadavky klientů a komunikují je s API Gateway. Požadavky jsou poté sděleny interním službám prostřednictvím dobře definované brány API.
3. Brána API
Vzhledem k tomu, že klienti nevolají služby přímo, funguje API Gateway jako vstupní bod pro klienty k předávání požadavků příslušným mikroslužbám.
Mezi výhody používání brány API patří:
- Všechny služby lze aktualizovat, aniž by o tom klienti věděli.
- Služby také mohou používat protokoly zasílání zpráv, které nejsou vhodné pro web.
- Brána API může provádět průřezové funkce, jako je poskytování zabezpečení, vyvažování zátěže atd.
Po obdržení požadavků klientů se vnitřní architektura skládá z mikroslužeb, které spolu komunikují prostřednictvím zpráv za účelem zpracování požadavků klientů.
4. Formáty zpráv
Existují dva typy zpráv, jejichž prostřednictvím komunikují:
- Synchronní zprávy: V situaci, kdy klienti čekají na odpovědi od služby, mají Microservices obvykle tendenci používat REST (Reprezentativní státní převod) protože spoléhá na bez státní příslušnosti, klient-server a HTTP protokol . Tento protokol se používá, protože se jedná o distribuované prostředí, přičemž každá funkce je představována prostředkem k provádění operací
- Asynchronní zprávy: V situaci, kdy klienti nečekají na odpovědi od služby, mají Microservices obvykle tendenci používat protokoly jako např. AMQP, STOMP, MQTT . Tyto protokoly se v tomto typu komunikace používají, protože je definována povaha zpráv a tyto zprávy musí být interoperabilní mezi implementacemi.
Další otázka, která vás možná napadne, je, jak aplikace s Microservices zpracovávají svá data?
5. Zpracování dat
Každá společnost Microservice vlastní soukromou databázi, která shromažďuje svá data a implementuje příslušné obchodní funkce. Databáze společnosti Microservices se také aktualizují pouze prostřednictvím jejich API služby. Viz následující diagram:
správce hadoop vs vývojář hadoop
Obrázek 3: Zastoupení mikroslužeb zpracovávajících data - architektura mikroslužeb
Služby poskytované společností Microservices jsou přenášeny do jakékoli vzdálené služby, která podporuje komunikaci mezi procesy pro různé technologické komíny.
6. Statický obsah
Poté, co Microservices v sobě komunikují, nasadí statický obsah do cloudové služby úložiště, která je může doručit přímo klientům prostřednictvím Sítě pro doručování obsahu (CDN) .
Kromě výše uvedených komponent se v typické architektuře Microservices Architecture objevují některé další komponenty:
7. Řízení
Tato součást je zodpovědná za vyvažování služeb na uzlech a identifikaci poruch.
8. Vyhledání služby
Působí jako průvodce Microservices k nalezení cesty komunikace mezi nimi, protože udržuje seznam služeb, na kterých jsou uzly umístěny.
Přihlaste se k odběru našeho kanálu na YouTube a získejte nové aktualizace ..!
Nyní se podívejme na výhody a nevýhody této architektury, abychom lépe porozuměli, kdy tuto architekturu použít.
Výhody a nevýhody architektury mikroslužeb
Viz tabulka níže.
| Pros architektury mikroslužeb | Nevýhody Microservice Architektura |
| Svoboda používat různé technologie | Zvyšuje problémy při řešení potíží |
| Každá mikroslužba se zaměřuje na možnosti jednotlivých podniků | Zvyšuje zpoždění kvůli vzdáleným hovorům |
| Podporuje jednotlivé nasaditelné jednotky | Zvýšené úsilí o konfiguraci a další operace |
| Umožňuje časté vydání softwaru | Je obtížné udržovat bezpečnost transakcí |
| Zajišťuje zabezpečení každé služby | Těžké sledovat data přes různé hranice služeb |
| Paralelně je vyvíjeno a nasazováno několik služeb | Je obtížné přesouvat kód mezi službami |
Pojďme pochopit více o Microservices porovnáním předchozí architektury UBER se současnou.
PŘÍPADOVÁ STUDIE UBER
Předchozí architektura společnosti UBER
jak používat java iterátor
Stejně jako mnoho startupů, i UBER zahájil svoji cestu s monolitickou architekturou postavenou pro jedinou nabídku v jednom městě. Zdálo se, že v té době byla jedna základna kódu vyčištěna, a vyřešila hlavní obchodní problémy společnosti UBER. Jak se však UBER začal rozšiřovat po celém světě, důsledně čelil různým problémům, pokud jde o škálovatelnost a nepřetržitou integraci.
Obrázek 4: Monolitická architektura UBER - architektura mikroslužeb
Výše uvedený diagram znázorňuje předchozí architekturu UBER.
- Je k dispozici rozhraní REST API, se kterým se cestující a řidič spojují.
- S API v nich se používají tři různé adaptéry k provádění akcí, jako je fakturace, platby, odesílání e-mailů / zpráv, které vidíme při rezervaci taxíku.
- Databáze MySQL pro ukládání všech jejich dat.
Pokud si zde všimnete všech funkcí, jako je správa cestujících, fakturace, funkce oznámení, platby, správa cest a správa řidičů, byly složeny do jediného rámce.
Problémové prohlášení
Zatímco UBER začal expandovat po celém světě, tento druh rámce představoval různé výzvy. Následuje několik významných výzev
- Všechny funkce musely být znovu sestaveny, nasazeny a testovány znovu a znovu, aby se aktualizovala jedna funkce.
- Oprava chyb se v jednom úložišti stala extrémně obtížnou, protože vývojáři museli znovu a znovu měnit kód.
- Škálování funkcí současně se zaváděním nových funkcí po celém světě bylo celkem těžké zvládnout společně.
Řešení
Aby se těmto problémům předešlo, UBER se rozhodl změnit svou architekturu a sledovat další společnosti s rychlým růstem, jako jsou Amazon, Netflix, Twitter a mnoho dalších. UBER se tedy rozhodl rozdělit svou monolitickou architekturu na více kódových základen a vytvořit architekturu mikroslužeb.
V níže uvedeném diagramu najdete architekturu mikroslužeb společnosti UBER.
Obrázek 5: Microservice Architecture Of UBER - Microservice Architecture
- Hlavní změnou, kterou zde pozorujeme, je zavedení API Gateway, prostřednictvím kterého jsou všichni řidiči a cestující propojeni. Z brány API jsou propojeny všechny interní body, jako je správa cestujících, správa řidičů, správa výletů a další.
- Jednotky jsou jednotlivé samostatné nasazitelné jednotky provádějící samostatné funkce.
- Například: Pokud chcete něco změnit ve fakturačních Microservices, stačí nasadit pouze fakturační Microservices a nemusíte nasadit ostatní.
- Všechny funkce byly nyní škálovány jednotlivě, tj. Byla odstraněna vzájemná závislost mezi každou funkcí.
- Například všichni víme, že počet lidí, kteří hledají taxíky, je srovnatelně vyšší než počet lidí, kteří si skutečně rezervují taxík a provádějí platby. To nám dává závěr, že počet procesů pracujících na mikroslužbě správy cestujících je větší než počet procesů pracujících na platbách.
V tomhlezpůsobUBER měl prospěch z řazenísvéarchitektura od monolitické po mikroslužby.
Doufám, že jste si tento příspěvek na Microservice Architecture užili.Budu přicházet s dalšími blogy, které budou také obsahovat praktické informace.
Máte zájem dozvědět se více o mikroslužbách?
Pokud se chcete naučit Microservices a vytvářet si vlastní aplikace, podívejte se na naše který přichází s živým tréninkem vedeným instruktorem a zkušenostmi z reálného projektu. Toto školení vám pomůže porozumět mikroslužbám do hloubky a pomůže vám dosáhnout mistrovství v předmětu.
Máte na nás dotaz? Uveďte to prosím v sekci komentářů na stránce ” Architektura mikroslužeb „A ozvu se vám.