Mikroszolgáltatások architektúrája - Tanulja meg, állítsa össze és telepítse a mikroszolgáltatásokat

Microservice architektúra:

Tőlem , akkor biztosan megértette a Microservice Architecture alapismereteit.De, ha profi vagyok nem csak az alapokra lesz szükség. Ebben a blogban megismerheti az építészeti koncepciók mélységét és megvalósítja azokat egy UBER-esettanulmány segítségével.

Ebben a blogban a következőket ismerheti meg:

• A Microservice Architecture meghatározása
• A mikroszolgáltatás építészetének legfontosabb fogalmai
• A mikroszolgáltatás építészetének előnyei és hátrányai
• UBER - Esettanulmány

Hivatkozhat a , megérteni a Microservices alapjait és előnyeit.

Csak akkor lesz igazságos, ha megadom neked a mikroszolgáltatások definícióját.

A mikroszolgáltatások meghatározása

Mint ilyen, nincs megfelelő meghatározása a Microservices, más néven Microservice Architecture, de elmondhatja, hogy ez egy keretrendszer, amely kicsi, egyedileg telepíthető szolgáltatásokból áll, amelyek különböző műveleteket hajtanak végre.

hogyan használjuk a szemaforokat a java-ban

A mikroszolgáltatások egyetlen üzleti területre összpontosítanak, amelyet teljesen független telepíthető szolgáltatásként lehet megvalósítani, és amelyek különböző technológiai halmazokon valósíthatók meg.

1.ábra: Különbség a monolit és a mikroszolgáltatási architektúra között - a mikroszolgáltatási architektúra között

A monolit és a mikroszolgáltatási architektúra közötti különbség megértéséhez lásd a fenti diagramot.A két architektúra közötti különbségek jobb megértése érdekében hivatkozhat az előző blogomra

A jobb megértés érdekében hadd mondjak el néhány alapvető fogalmat a mikroszolgáltatás architektúrájáról.

A mikroszolgáltatás építészetének legfontosabb fogalmai

Mielőtt saját szolgáltatásokat kezdene mikroszolgáltatások használatával felépíteni, tisztában kell lennie az alkalmazás hatókörével és funkcióival.

Az alábbiakban néhány irányelvet kell követni a mikroszolgáltatások megvitatása során.

Útmutatók a mikroszolgáltatások tervezése közben

• Fejlesztőként, amikor úgy dönt, hogy egy alkalmazást készít, válassza szét a tartományokat, és tisztázza a funkciókat.
• Minden általad tervezett mikroszolgáltatás csak az alkalmazás egyetlen szolgáltatására koncentrálhat.
• Győződjön meg arról, hogy az alkalmazást úgy tervezte meg, hogy minden szolgáltatás külön telepíthető legyen.
• Győződjön meg arról, hogy a mikroszolgáltatások közötti kommunikáció hontalan szerveren keresztül zajlik.
• Minden szolgáltatás továbbépíthető kisebb szolgáltatásokká, saját mikroszolgáltatásokkal.

Most, hogy elolvasta az alapvető irányelveket a mikroszolgáltatások tervezése közben, értsük meg a mikroszolgáltatások felépítését.

Hogyan működik a Microservice architektúra?

A tipikus Microservice Architecture (MSA) a következő összetevőkből áll:

1. Ügyfelek
2. Személyazonosság-szolgáltatók
3. Gateway API
4. Üzenetformátumok
5. Adatbázisok
6. Statikus tartalom
7. Menedzsment
8. Szolgáltatás felfedezése

Lásd az alábbi ábrát.

2. ábra: Mikroszolgáltatások architektúrája - Mikroszolgáltatások architektúrája

Tudom, hogy az architektúra kissé összetettnek tűnik, de hagyjukénegyszerűsítse az Ön számára.

1. Ügyfelek

Az architektúra különféle típusú kliensekkel kezdődik, különböző eszközöktől kezdve, különféle kezelési képességek, például keresés, összeállítás, konfigurálás stb. Végrehajtásával.

2. Azonosító szolgáltatók

hogyan kell tesztelni egy adatbázist

Ezeket az ügyfelek kéréseit továbbítják az identitásszolgáltatóknak, akik hitelesítik az ügyfelek kéréseit és kommunikálják a kéréseket az API Gateway-hez. A kéréseket ezután jól definiált API-átjárón keresztül közlik a belső szolgáltatásokkal.

3. API Gateway

Mivel az ügyfelek nem hívják közvetlenül a szolgáltatásokat, az API-átjáró belépési pontként működik az ügyfelek számára, hogy továbbítsák a kéréseket a megfelelő mikroszolgáltatásokhoz.

Az API-átjáró használatának előnyei a következők:

• Minden szolgáltatás frissíthető anélkül, hogy az ügyfelek tudnák.
• A szolgáltatások használhatnak nem webbarát üzenetkezelési protokollokat is.
• Az API Gateway képes átfogó funkciókat végrehajtani, például biztonságot, terheléselosztást stb.

Miután megkapta az ügyfelek kéréseit, a belső architektúra mikroszolgáltatásokból áll, amelyek üzenetek útján kommunikálnak egymással az ügyfélkérések kezelésére.

4. Üzenetformátumok

Kétféle üzenet van, amelyeken keresztül kommunikálnak:

• Szinkron üzenetek: Abban a helyzetben, amikor az ügyfelek egy szolgáltatás válaszait várják, a Microservices általában hajlamos használni REST (reprezentatív államtranszfer) mivel egy hontalan, kliens-szerverre és a HTTP protokoll . Ezt a protokollt használják, mivel ez egy elosztott környezet, és minden funkció egy erőforrással van ábrázolva a műveletek végrehajtásához
• Aszinkron üzenetek: Abban a helyzetben, amikor az ügyfelek nem várják meg a szolgáltatás válaszait, a Microservices általában olyan protokollokat használ, mint pl AMQP, STOMP, MQTT . Ezeket a protokollokat használják az ilyen típusú kommunikációban, mivel az üzenetek jellege meg van határozva, és ezeknek az üzeneteknek átjárhatónak kell lenniük a megvalósítások között.

A következő kérdés, ami eszedbe juthat, az, hogy miként kezelik az adataikat a Microservice szolgáltatást használó alkalmazások?

5. Adatkezelés

Nos, mindegyik Microservice saját adatbázissal rendelkezik, hogy összegyűjtse adatait és megvalósítsa a megfelelő üzleti funkcionalitást. A Microservices adatbázisai is csak a szolgáltatás API-ján keresztül frissülnek. Lásd az alábbi ábrát:

3. ábra: Mikroszolgáltatások adatkezelésének ábrázolása - Microservice architektúra

A Microservices által nyújtott szolgáltatásokat továbbítják minden olyan távoli szolgáltatásba, amely támogatja a folyamatok közötti kommunikációt a különböző technológiai halmazok számára.

6. Statikus tartalom

Miután a Microservices kommunikált önmagában, a statikus tartalmat felhőalapú tárolási szolgáltatásba telepíti, amely közvetlenül az ügyfelek felé tudja eljuttatni őket Tartalomátviteli hálózatok (CDN) .

A fenti összetevőkön kívül van néhány más összetevő is egy tipikus Microservices architektúrában:

7. Menedzsment

Ez az összetevő felelős a szolgáltatások csomópontokon történő kiegyensúlyozásáért és a hibák azonosításáért.

8. Szolgáltatás felfedezése

Útmutatóként szolgál a Microservices számára, hogy megtalálja a közöttük lévő kommunikáció útvonalát, mivel karbantartja a csomópontok található szolgáltatásainak listáját.

Iratkozzon fel youtube csatornánkra, hogy új frissítéseket kapjon ..!

Most vizsgáljuk meg ennek az architektúrának az előnyeit és hátrányait, hogy jobban megértsük, mikor kell ezt az architektúrát használni.

A Microservice Architecture előnyei és hátrányai

Lásd az alábbi táblázatot.

Ismerjünk meg többet a Microservices szolgáltatásról, összehasonlítva az UBER korábbi architektúráját a mostanival.

UBER-ESETTANULMÁNY

Az UBER előző építészete

mi a névtelen osztály a java-ban

Mint sok induló vállalkozás, az UBER is monolit építészettel kezdte útját, egyetlen ajánlatért, egyetlen városban. Úgy tűnt, hogy egy kódalap megtisztult abban az időben, és megoldotta az UBER alapvető üzleti problémáit. Amikor azonban az UBER világszerte terjeszkedni kezdett, szigorúan szembesültek a skálázhatóság és a folyamatos integráció különböző problémáival.

4. ábra: Az UBER monolit építészete - Microservice architektúra

A fenti ábra az UBER korábbi architektúráját ábrázolja.

• Jelen van egy REST API, amellyel az utas és a sofőr csatlakozik.
• Három különböző adaptert használnak az API-n belül, olyan műveletek végrehajtására, mint a számlázás, a fizetések, az e-mailek / üzenetek küldése, amelyeket akkor látunk, amikor taxit foglalunk.
• MySQL adatbázis minden adatuk tárolására.

Tehát, ha itt észreveszi az összes olyan funkciót, mint az utaskezelés, a számlázás, az értesítési funkciók, a fizetések, az utazáskezelés és a sofőrkezelés, egyetlen keretben álltak össze.

Probléma nyilatkozat

Míg az UBER világszerte terjeszkedni kezdett, ez a fajta keretrendszer különféle kihívásokat jelentett. Az alábbiakban bemutatjuk a kiemelkedő kihívásokat

• Valamennyi funkciót újra kellett építeni, telepíteni és újra és újra tesztelni kellett egyetlen szolgáltatás frissítéséhez.
• A hibák kijavítása rendkívül nehézzé vált egyetlen adattárban, mivel a fejlesztőknek újra és újra meg kellett változtatniuk a kódot.
• A funkciók skálázása az új funkciók világszerte történő bevezetésével egyidejűleg meglehetősen nehéz volt.

Megoldás

Az ilyen problémák elkerülése érdekében az UBER úgy döntött, hogy megváltoztatja az architektúráját, és követi a többi olyan hiper-növekedési vállalatot, mint az Amazon, a Netflix, a Twitter és még sokan mások. Így az UBER úgy döntött, hogy monolit architektúráját több kódbázisra bontja, hogy mikroszolgáltatási architektúrát képezzen.

Az alábbi ábrán tekintheti meg az UBER mikroszolgáltatási architektúráját.

5. ábra: Az UBER Microservice architektúrája - Microservice Architecture

• A legfontosabb változás, amelyet itt megfigyelünk, az API Gateway bevezetése, amelyen keresztül az összes vezető és utas összekapcsolódik. Az API Gateway-től az összes belső pont összekapcsolódik, mint például az utasok kezelése, a járművezetők kezelése, az utazáskezelés és mások.
• Az egységek különálló, külön funkciókat ellátó, bevethető egységek.
  • Például: Ha bármit meg akar változtatni a számlázó mikroszolgáltatásokban, akkor csak a számlázó mikroszolgáltatásokat kell telepítenie, a többit pedig nem kell telepítenie.
• Az összes funkciót mostantól egyedileg méretezték, vagyis megszüntették az egyes jellemzők közötti kölcsönös függőséget.
  • Például mindannyian tudjuk, hogy a fülkéket keresők száma összehasonlítva több, mint azok, akik valóban taxit foglalnak és fizetnek. Ebből arra következtethetünk, hogy az utaskezelő mikroszolgáltatáson dolgozó folyamatok száma meghaladja a fizetésekkel kapcsolatos folyamatok számát.

Ebbenút, Az UBER javára váltottannaképítészet a monolitistól a mikroszolgáltatásokig.

Remélem, hogy élvezettel olvasta ezt a bejegyzést a Microservice Architecture webhelyen.További blogokkal fogok előállni, amelyek praktikus információkat is tartalmaznak.
Szeretne többet megtudni a mikroszolgáltatásokról?

Ha meg szeretné tanulni a Mikroszolgáltatásokat, és saját alkalmazásokat szeretne létrehozni, akkor nézze meg a mi oldalunkat amely oktató által vezetett élő képzéssel és valós projekt-tapasztalattal jár. Ez a képzés segít megérteni a mikroszolgáltatásokat mélyebben, és elsajátítja a témát.

Van egy kérdésünk? Kérjük, említse meg a megjegyzések részben. ” Microservice architektúra ”És visszatérek hozzád.