Architektúra mikroslužieb - učte sa, zostavujte a nasadzujte mikroslužby

Architektúra mikroslužieb:

Z môjho , musíte mať základné znalosti o architektúre Microservice Architecture.Ale byť profesionálom s bude vyžadovať nielen základné informácie. V tomto blogu sa dostanete do hĺbky architektonických konceptov a implementujete ich pomocou prípadovej štúdie UBER.

V tomto blogu sa dozviete o nasledujúcich témach:

• Definícia architektúry mikroslužieb
• Kľúčové koncepty architektúry mikroslužieb
• Výhody a nevýhody architektúry mikroslužieb
• UBER - prípadová štúdia

Môžete sa obrátiť na , aby sme pochopili základné princípy a výhody Microservices.

Bude to spravodlivé, iba ak vám poskytnem definíciu mikroslužieb.

Definícia mikroslužieb

Preto neexistuje správna definícia Microservices aka Microservice Architecture, ale môžete povedať, že ide o rámec, ktorý sa skladá z malých, jednotlivo nasaditeľných služieb vykonávajúcich rôzne operácie.

Mikroslužby sa zameriavajú na jednu obchodnú doménu, ktorú je možné implementovať ako úplne nezávislé nasaditeľné služby a implementovať ich do rôznych technologických balíkov.

Postava 1: Rozdiel medzi monolitickou a mikroslužobnou architektúrou - architektúra mikroslužieb

Podľa vyššie uvedeného diagramu pochopíte rozdiel medzi monolitickou a mikroslužobnou architektúrou.Pre lepšie pochopenie rozdielov medzi oboma architektúrami si môžete pozrieť môj predchádzajúci blog

Aby ste lepšie porozumeli, poviem vám niektoré kľúčové koncepty architektúry mikroslužieb.

previesť desatinné číslo na binárne v pythone

Kľúčové koncepty architektúry mikroslužieb

Predtým, ako začnete vytvárať svoje vlastné aplikácie pomocou mikroslužieb, musíte si uvedomiť rozsah a funkcie vašej aplikácie.

Nasleduje niekoľko pokynov, ktoré treba dodržiavať pri diskusii o mikroslužbách.

Pokyny pri navrhovaní mikroslužieb

• Ako vývojár, keď sa rozhodnete zostaviť aplikáciu, oddeľte domény a buďte jasní v tom, ako fungujú.
• Každá mikroslužba, ktorú navrhnete, sa sústredí iba na jednu službu aplikácie.
• Uistite sa, že ste aplikáciu navrhli tak, aby bolo možné nasadiť každú službu individuálne.
• Zaistite, aby sa komunikácia medzi mikroslužbami uskutočňovala prostredníctvom servera bez štátnej príslušnosti.
• Každú službu je možné ďalej prepracovať na menšie služby s vlastnými mikroslužbami.

Teraz, keď ste si pri navrhovaní mikroslužieb prečítali základné pokyny, pochopme architektúru mikroslužieb.

Ako funguje architektúra mikroslužieb?

Typická architektúra microservice (MSA) by mala pozostávať z nasledujúcich komponentov:

1. Klienti
2. Poskytovatelia identity
3. Gateway API
4. Formáty správ
5. Databázy
6. Statický obsah
7. Zvládanie
8. Zistenie služby

Pozrite si nasledujúcu schému.

Obrázok 2: Architecture Of Microservices - Microservice Architecture

Viem, že architektúra vyzerá trochu zložito, ale nechJazjednodušte to za vás.

1. Klienti

Architektúra začína u rôznych typov klientov, od rôznych zariadení, ktoré sa snažia vykonávať rôzne možnosti správy, ako je vyhľadávanie, zostavovanie, konfigurácia atď.

2. Poskytovatelia identity

Tieto požiadavky od klientov sa potom odovzdajú poskytovateľom identity, ktorí autentifikujú požiadavky klientov a komunikujú ich s API Gateway. Požiadavky sa potom komunikujú s internými službami prostredníctvom presne definovanej brány API.

3. Brána API

Pretože klienti nevolajú priamo na tieto služby, API Gateway slúži ako vstupný bod pre klientov na preposielanie požiadaviek príslušným mikroslužbám.

Medzi výhody používania brány API patria:

• Všetky služby je možné aktualizovať bez toho, aby o tom klienti vedeli.
• Služby môžu tiež používať protokoly správ, ktoré nie sú vhodné pre web.
• Brána API môže vykonávať prierezové funkcie, ako napríklad zabezpečenie, vyrovnávanie zaťaženia atď.

Po prijatí požiadaviek klientov sa vnútorná architektúra skladá z mikroslužieb, ktoré navzájom komunikujú prostredníctvom správ na spracovanie požiadaviek klientov.

4. Formáty správ

Existujú dva typy správ, prostredníctvom ktorých komunikujú:

• Synchrónne správy: V situácii, keď klienti čakajú na odpovede od služby, majú zvyčajne tendenciu používať Microservices REST (prevod reprezentatívneho štátu) pretože sa spolieha na bez štátnej príslušnosti, klient-server a HTTP protokol . Tento protokol sa používa, pretože ide o distribuované prostredie, pričom každá funkčnosť je predstavovaná prostriedkom na vykonávanie operácií
• Asynchrónne správy: V situácii, keď klienti nečakajú na odpovede od služby, majú Microservices zvyčajne tendenciu používať protokoly ako napr. AMQP, STOMP, MQTT . Tieto protokoly sa používajú v tomto type komunikácie, pretože je definovaná podstata správ a tieto správy musia byť interoperabilné medzi implementáciami.

Ďalšia otázka, ktorá by vás mohla napadnúť, je, ako narábajú s dátami aplikácie využívajúce Microservices?

5. Spracovanie údajov

Každá spoločnosť Microservice vlastní súkromnú databázu na zaznamenávanie svojich údajov a implementáciu príslušných obchodných funkcií. Databázy spoločnosti Microservices sa tiež aktualizujú iba prostredníctvom ich servisného rozhrania API. Pozrite si nasledujúci diagram:

je-má a má-vzťah v jave

Obrázok 3: Zastúpenie mikroslužieb manipulujúcich s dátami - architektúra mikroslužieb

Služby poskytované spoločnosťou Microservices sa prenášajú do akejkoľvek vzdialenej služby, ktorá podporuje medziprocesovú komunikáciu pre rôzne technologické komíny.

6. Statický obsah

Keď Microservices v sebe komunikujú, nasadia statický obsah do cloudovej úložnej služby, ktorá ich môže doručiť priamo klientom prostredníctvom Siete na doručovanie obsahu (CDN) .

Okrem vyššie uvedených komponentov existujú v typickej architektúre Microservices Architecture aj niektoré ďalšie komponenty:

7. Manažment

Táto súčasť je zodpovedná za vyvažovanie služieb na uzloch a identifikáciu zlyhaní.

8. Zistenie služby

Pôsobí ako sprievodca pre mikroslužby pri hľadaní cesty komunikácie medzi nimi, pretože vedie zoznam služieb, na ktorých sa nachádzajú uzly.

Prihláste sa na odber nášho kanála na YouTube a získajte nové aktualizácie ..!

Teraz sa pozrime na výhody a nevýhody tejto architektúry, aby sme lepšie pochopili, kedy je potrebné túto architektúru použiť.

Výhody a nevýhody architektúry mikroslužieb

Pozrite si nasledujúcu tabuľku.

Poďme pochopiť viac o Microservices porovnaním predchádzajúcej architektúry UBER so súčasnou.

PRÍPADOVÁ ŠTÚDIA UBER

Predchádzajúca architektúra spoločnosti UBER

aktívna a pasívna transformácia v informatike

Rovnako ako mnoho začínajúcich podnikateľov, aj spoločnosť UBER začala svoju cestu s monolitickou architektúrou postavenou pre jednu ponuku v jednom meste. V tom čase sa zdalo, že mať jednu základňu kódov bolo vyčistené, a vyriešili sa tak hlavné obchodné problémy spoločnosti UBER. Keď sa však spoločnosť UBER začala rozširovať do celého sveta, dôsledne čelila rôznym problémom v súvislosti so škálovateľnosťou a nepretržitou integráciou.

Obrázok 4: Monolitická architektúra UBER - architektúra mikroslužieb

Vyššie uvedený diagram zobrazuje predchádzajúcu architektúru spoločnosti UBER.

• K dispozícii je REST API, s ktorým sa spájajú cestujúci a vodič.
• S API v nich sa používajú tri rôzne adaptéry na vykonávanie akcií, ako sú fakturácia, platby, odosielanie e-mailov / správ, ktoré vidíme pri rezervácii taxíka.
• Databáza MySQL na ukladanie všetkých ich údajov.

Takže ak si tu všimnete všetky funkcie, ako napríklad správa cestujúcich, fakturácia, funkcie oznámení, platby, správa cesty a správa vodiča, boli zložené do jedného rámca.

Vyhlásenie o probléme

Zatiaľ čo sa UBER začal rozširovať do celého sveta, tento druh rámca priniesol rôzne výzvy. Nasleduje niekoľko významných výziev

• Všetky funkcie bolo treba znovu zostaviť, nasadiť a opakovane testovať, aby sa aktualizovala jedna vlastnosť.
• Oprava chýb sa v jednom úložisku stala nesmierne náročnou, pretože vývojári museli znova a znova meniť kód.
• Škálovanie funkcií súčasne so zavedením nových funkcií do celého sveta bolo náročné zvládnuť spoločne.

Riešenie

Aby sa predišlo takýmto problémom, spoločnosť UBER sa rozhodla zmeniť svoju architektúru a nasledovať ďalšie spoločnosti s rýchlym rastom, ako sú Amazon, Netflix, Twitter a mnohé ďalšie. Preto sa UBER rozhodol rozdeliť svoju monolitickú architektúru na viac kódových báz a vytvoriť tak mikroslužobnú architektúru.

V nasledujúcej schéme sa dozviete o architektúre mikroslužieb spoločnosti UBER.

Obrázok 5: Microservice Architecture of UBER - Microservice Architecture

• Hlavnou zmenou, ktorú tu sledujeme, je zavedenie brány API, cez ktorú sú spojení všetci vodiči a cestujúci. Z brány API Gateway sú spojené všetky interné body, ako napríklad správa cestujúcich, správa vodičov, správa ciest a ďalšie.
• Jednotky sú jednotlivé samostatné nasaditeľné jednotky vykonávajúce samostatné funkcie.
  • Napríklad: Ak chcete niečo zmeniť vo fakturačných mikroslužbách, stačí nasadiť iba fakturačné mikroslužby a nemusíte nasadiť ostatné.
• Všetky funkcie boli teraz zmenšené individuálne, t. J. Vzájomná závislosť medzi každou a každou funkciou bola odstránená.
  • Napríklad všetci vieme, že počet ľudí, ktorí hľadajú taxíky, je porovnateľne vyšší ako počet ľudí, ktorí si skutočne rezervujú taxík a platia. Získame z toho záver, že počet procesov pracujúcich na mikroslužbe správy cestujúcich je väčší ako počet procesov pracujúcich na platbách.

V tomtospôsobom, UBER mal z radenia prospechjehoarchitektúra od monolitickej po mikroslužby.

Dúfam, že sa vám páčilo čítanie tohto príspevku o architektúre Microservice Architecture.Vymyslím ďalšie blogy, ktoré budú obsahovať aj hands-on.
Máte záujem dozvedieť sa viac o mikroslužbách?

Ak sa chcete naučiť mikroslužby a budovať svoje vlastné aplikácie, pozrite si naše ktorá prináša živé školenie vedené inštruktorom a skúsenosti s projektmi v reálnom živote. Toto školenie vám pomôže pochopiť Microservices do hĺbky a pomôže vám dosiahnuť osvojenie si predmetu.

Máte na nás otázku? Uveďte to v sekcii komentárov stránky ” Architektúra mikroslužieb “A ozvem sa ti.