Výukový program mikroslužeb: Co je, Architektura a příklad

Termín „mikro“ se týká velikosti mikroslužby, kterou musí zvládnout jediný vývojový tým (5 až 10 vývojářů). V této metodice jsou velké aplikace rozděleny do nejmenších nezávislých jednotek.

Co je monolitický Architecture?

Laicky lze říci, že Monolithic architektura je jako velký kontejner, ve kterém jsou všechny softwarové komponenty aplikace sloučeny do jediného balíčku.

Pojďme diskutovat o příkladu eCommerce obchodu v kontextu monolitické architektury.

V každé aplikaci elektronického obchodu existují některé standardní funkce, jako je vyhledávání, Revzobrazení a hodnocení a platby. Tyto funkce jsou dostupné zákazníkům pomocí jejich prohlížeče nebo aplikací. Když vývojář webu eCommerce nasadí aplikaci, je to jedna monolitická jednotka. Kód pro různé funkce, jako je Vyhledávání, Revew & Ratings a Payments jsou na stejném serveru. Chcete-li škálovat aplikaci, musíte spustit více instancí (serverů) těchto aplikací.

V Monolitu ArchiVšechny komponenty se spojí do jediného modulu. Ale v Microservices Archijsou rozděleny do jednotlivých modulů (mikroservis), které spolu komunikují, jak je znázorněno na příkladu Microservices výše.

Komunikace mezi mikroslužbami je bezstavová komunikace, kde je každý pár požadavku a odpovědi nezávislý. Microservices tak mohou komunikovat bez námahy. V mikroservisu Architecture, Data jsou federovaná. Každá mikroslužba má vlastní úložiště dat. Další v tomto Java Tutoriál Microservices, seznámíme se s rozdílem mezi Microservices a Monolithic architekturou.

Mikroslužby vs. Monolitické Architecture

Mikroslužby	jednolitý Architecture
Každá jednotka celé aplikace by měla být nejmenší a měla by být schopna zajistit jeden konkrétní obchodní cíl.	Jediná kódová základna pro všechny obchodní cíle
Spuštění služby je relativně rychlé	Spuštění služby trvá déle
Izolace chyb je snadná. I když jedna služba vypadne, jiná může nadále fungovat.	Izolace chyb je obtížná. Pokud některá konkrétní funkce nefunguje, celý systém se zhroutí. Aby bylo možné tento problém vyřešit, je třeba aplikaci znovu sestavit, znovu otestovat a také znovu nasadit.
Všechny mikroslužby by měly být volně propojeny, aby změny provedené v jedné neovlivnily druhou.	Monolitická architektura je pevně spojena. Změny v jednom modulu kódu ovlivňují druhý
Podniky mohou nasadit více zdrojů do služeb, které generují vyšší návratnost investic	Vzhledem k tomu, že služby nejsou izolované, individuální přidělování zdrojů není možné
Službě, která se často používá, by mohlo být přiděleno více hardwarových prostředků. Ve výše uvedeném příkladu elektronického obchodu více uživatelů kontroluje záznam a vyhledávání produktů než platby. Více zdrojů by tedy mohlo být přiděleno mikroslužbě vyhledávání a výpisu produktů.	Škálování aplikací je náročné a také plýtvání.
Mikroslužby zůstávají vždy konzistentní a nepřetržitě dostupné.	Vývojové nástroje jsou přetěžovány, protože proces musí začít od nuly.
Data jsou federovaná. To umožňuje jednotlivé Microservice přijmout datový model, který nejlépe vyhovuje jejím potřebám.	Data jsou centralizovaná.
Malé soustředěné týmy. Paralelní a rychlejší vývoj	Vyžaduje se velký tým a značné úsilí vedení týmu
Změna datového modelu jedné Mikroslužby nemá vliv na ostatní Mikroslužby.	Změna datového modelu ovlivňuje celou databázi
Interaguje s ostatními mikroslužbami pomocí dobře definovaných rozhraní	Nehodí
Mikroslužby fungují na principu, který se zaměřuje na produkty, nikoli projekty	Důraz na celý projekt
Žádné vzájemné závislosti mezi bázemi kódu. Pro různé mikroslužby můžete používat různé technologie.	Jedna funkce nebo program závisí na ostatních.

Výzvy mikroslužeb

• MicroServices se na sebe navzájem spoléhají a budou spolu muset komunikovat.
• Ve srovnání s monolitickými systémy existuje více služeb ke sledování, které jsou vyvíjeny pomocí různých programovací jazyky.
• Jelikož se jedná o distribuovaný systém, jedná se o inherentně složitý model.
• Různé služby budou mít svůj samostatný mechanismus, což povede k velkému množství paměti pro nestrukturovaná data.
• Aby se předešlo kaskádovým problémům, je zapotřebí efektivní řízení a týmová práce
• Reprodukce problému bude obtížný úkol, když v jedné verzi zmizí a vrátí se v nejnovější verzi.
• Nezávislé nasazení je u Microservices komplikované.
• Architektura mikroslužeb přináší spoustu provozních režií.

• Je obtížné spravovat aplikaci, když jsou do systému přidávány nové služby
• K podpoře heterogenně distribuovaných mikroslužeb je zapotřebí široká škála kvalifikovaných odborníků
• Mikroslužba je nákladná, protože pro různé obchodní úkoly potřebujete udržovat různý serverový prostor.

SOA vs. mikroslužby

Služby SOA jsou v organizaci udržovány registrem, který funguje jako výpis adresářů. Aplikace musí vyhledat služby v registru a vyvolat službu.

V jiném světě, SOA je jako orchestr, kde každý umělec vystupuje se svým nástrojem, zatímco hudební ředitel dává pokyny všem.

Na druhém konci jsou Microservices formou stylu architektury orientované na služby, kde jsou aplikace sestaveny jako kolekce různých menších služeb namísto jednoho softwaru nebo aplikace.

Microservices je jako skupina, kde je každý tanečník nezávislý a ví, co má dělat. Pokud tedy vynechají některé kroky, vědí, jak se dostat zpět na správnou sekvenci. Nyní se v tomto kurzu architektury Microservices seznámíme s rozdílem mezi SOA a Microservices.

Zde je podrobné srovnání mezi SOA a Microservices

Parametr	SOA	Mikroslužby
Typ konstrukce	V SOA jsou softwarové komponenty vystaveny vnějšímu světu pro použití ve formě služeb.	Micro Service je součástí SOA. Jedná se o implementaci SOA.
Závislost	Obchodní jednotky jsou závislé.	Jsou na sobě nezávislé.
Velikost Softwaru	Velikost softwaru je větší než u jakéhokoli běžného softwaru	Velikost Softwaru je v Microservices vždy malá
Zásobník technologií	Zásobník technologií je ve srovnání s Microservice nižší.	Zásobník technologií mikroslužeb může být velmi velký
Povaha aplikace	Monolitické povahy	Plný zásobník v přírodě
Nezávislé a soustředěné	Aplikace SOA jsou navrženy tak, aby prováděly více obchodních úkolů.	Jsou navrženy tak, aby vykonávaly jeden obchodní úkol.
Rozvinutí	Proces nasazení je časově náročný.	Nasazení je jednoduché a časově méně náročné.
Efektivita nákladů	Cenově výhodnější.	Less nákladově efektivní.
Škálovatelnost	Less ve srovnání s Microservices.	Vysoce škálovatelné.
Obchodní logika	Komponenty obchodní logiky jsou uloženy v jediné doméně služby Jednoduché drátové protokoly (HTTP s XML JSON) API je řízeno sadami SDK/klienty	Obchodní logika může žít napříč doménami, jako je podniková sběrnice služeb, jako vrstvy mezi middlewarem služeb

Nástroje mikroslužeb

1) Wiremock: Testování mikroslužeb

WireMock je flexibilní knihovna pro stubování a zesměšňování webových služeb. Může nakonfigurovat odpověď vrácenou HTTP API, když obdrží konkrétní požadavek. Používá se také pro testování mikroslužeb.

Download link:http://wiremock.org/

2) Docker

Docker je open source projekt, který nám umožňuje vytvářet, nasazovat a spouštět aplikace pomocí kontejnerů. Pomocí těchto kontejnerů mohou vývojáři spustit aplikaci jako jeden balíček. Umožňuje vám posílat knihovny a další závislosti v jednom balíčku.

Download link:https://www.docker.com/

3) Hystrix

Hystrix je knihovna Java s odolností proti chybám. Tento nástroj je navržen k oddělení bodů přístupu ke vzdáleným službám, systémům a knihovnám třetích stran v distribuovaném prostředí, jako je Microservices. Zlepšuje celkový systém izolováním selhávajících služeb a předcházením kaskádového efektu selhání.

Odkaz ke stažení:https://github.com/Netflix/Hystrix

Best Practices of Microservices Architecture

• Samostatné úložiště dat pro každou Microservice
• Udržujte kód podobné úrovně vyspělosti.
• Samostatné sestavení pro každou službu Micro.
• Vždy zacházet – závažné jako bez státní příslušnosti.

Shrnutí

• Microservices je architektura orientovaná na služby, kde jsou aplikace sestavovány jako kolekce různých nejmenších nezávislých servisních jednotek.
• Mikroservis Architecture je architektonický vývojový styl, který umožňuje vytvořit aplikaci jako kolekci malých autonomních služeb vyvinutých pro obchodní doménu.
• Monolitická architektura je jako velký kontejner, ve kterém jsou všechny softwarové komponenty aplikace spojeny do jediného balíčku
• V mikroslužbě by měla být každá jednotka celé aplikace nejmenší a měla by být schopna zajistit jeden konkrétní obchodní cíl
• V Monolithic architektuře může velká kódová základna zpomalit celý vývojový proces. Nové verze mohou trvat měsíce. Údržba kódu je náročná
• Dva typy mikroslužeb jsou 1) Bezstavové 2) Stavové
• Mikroslužby v Java spoléhat jeden na druhého a budou spolu muset komunikovat. Pomáhá vám klást důraz na konkrétní funkci a obchodní potřeby
• Architektura orientovaná na služby, krátce známá jako SOA, je evolucí distribuovaných výpočtů založených na modelu návrhu požadavku nebo odpovědi pro synchronní a asynchronní aplikace.
• V SOA jsou softwarové komponenty vystaveny vnějšímu světu pro použití ve formě služeb, zatímco Micro Service je součástí SOA. Jedná se o implementaci SOA
• Wiremock, Docker a Hystrix jsou některé oblíbené nástroje Microservices