kontextus

Kiszolgálóoldali vállalati alkalmazást fejleszt. Ennek különféle klienseket kell támogatnia, beleértve asztali böngészőket, mobil böngészőket és natív mobilalkalmazások. Az alkalmazás egy API-t is felfedhet harmadik felek fogyasztására. Integrálódhat más alkalmazásokkal akár webszolgáltatásokon, akár üzenetközvetítőkön keresztül. Az alkalmazás üzleti logika végrehajtásával kezeli a kéréseket (HTTP kéréseket és üzeneteket); hozzáférés egy adatbázishoz; üzenetek cseréje más rendszerekkel; és HTML / JSON / XML válasz küldése. Vannak logikai összetevők, amelyek megfelelnek az alkalmazás különböző funkcionális területeinek.

Probléma

Mi az alkalmazás telepítési architektúrája?

Erők

• Az alkalmazáson dolgozik egy fejlesztői csapat
• Az új csapattagoknak gyorsan produktívvá kell válniuk
• Az alkalmazásnak könnyen érthetőnek kell lennie és módosítsa
• Az alkalmazás folyamatos telepítését szeretné gyakorolni
• Az alkalmazás több példányát több gépen kell futtatnia a skálázhatósági és rendelkezésre állási követelmények teljesítése érdekében
• Ki akarja használni a feltörekvő technológiák (keretrendszerek, programozási nyelvek stb.) Előnyeit.

Megoldás

Adjon meg egy architektúrát, amely lazán összekapcsolt halmazként strukturálja az alkalmazást, együttműködő szolgáltatások. Ez a megközelítés megfelel a Scale Cube Y tengelyének. Minden szolgáltatás a következő:

• Könnyen karbantartható és tesztelhető – lehetővé teszi a ra tartós és gyakori fejlesztés és telepítés
• lazán más szolgáltatásokkal párosítva – lehetővé teszi a csapat számára, hogy a legtöbb idő alatt önállóan dolgozzon a szolgáltatásain (szolgáltatásain), anélkül, hogy más szolgáltatások változásai hatással lennének rá, és nem érintenék az egyéb szolgáltatásokat
• Függetlenül telepíthető – lehetővé teszi egy csapat számára, hogy a szolgáltatását más csapatokkal való koordináció nélkül telepítse
• Képes egy kis csapat fejlesztésére – elengedhetetlen a magas termelékenységhez, elkerülve a nagy kommunikációs vezetőket csapatok

A szolgáltatások szinkron protokollok (például HTTP / REST) vagy aszinkron protokollok, például AMQP segítségével kommunikálnak. A szolgáltatások egymástól függetlenül fejleszthetők és telepíthetők. Minden szolgáltatás saját adatbázissal rendelkezik annak érdekében, hogy leválasztható a többi szolgáltatásról. A szolgáltatások közötti adatkonzisztencia a Saga minta használatával fennmarad.

Ha többet szeretne megtudni a szolgáltatás természetéről, olvassa el ezt a cikket.

Példák

Fiktív e-kereskedelmi alkalmazások on

Képzeljük el, hogy olyan e-kereskedelmi alkalmazást épít, amely megrendeléseket fogad el az ügyfelektől, ellenőrzi a készletet és a rendelkezésre álló hitelt, és szállítja azokat. Az alkalmazás több összetevőből áll, beleértve a StoreFrontUI-t, amely a felhasználói felületet valósítja meg , néhány háttérszolgáltatással együtt a hitel ellenőrzésére, a készlet és a szállítási rendelések karbantartására. Az alkalmazás egy sor szolgáltatásból áll.

Mutasd meg a kódot

Kérjük, olvassa el a Chris Richardson által kifejlesztett példaalkalmazásokat. A Github ezen példái a mikroszolgáltatás architektúrájának különböző aspektusait mutatják be.

Eredményes kontextus

Előnyök

Ennek a megoldásnak számos előnye van:

• Lehetővé teszi nagy, összetett alkalmazások folyamatos kézbesítését és telepítését.
  • Javított karbantarthatóság – minden szolgáltatás viszonylag kicsi, így könnyebben érthető és változtatható
  • Jobb tesztelhetőség – a szolgáltatások kisebbek és gyorsabban tesztelhetők
  • Jobb telepíthetőség – szolgáltatások önállóan telepíthető
  • Lehetővé teszi a fejlesztési erőfeszítések megszervezését több, autonóm csapat köré. Mindegyik (úgynevezett két pizza) csapat tulajdonosa és felelős egy vagy több szolgáltatásért. Minden csapat az összes többi csapattól függetlenül fejlesztheti, tesztelheti, telepítheti és méretezheti szolgáltatásait.
• Minden mikroszolgáltatás viszonylag kicsi:
  • Egy felhasználó számára könnyebb a fejlesztő számára, hogy megértse
  • Az IDE gyorsabban teszi a fejlesztőket produktívabbá
  • Az alkalmazás gyorsabban indul, ezáltal a fejlesztők produktívabbak és felgyorsulnak a telepítések li>
  • Javított hibaszigetelés. Például, ha egy szolgáltatásban van memóriaszivárgás, akkor csak az a szolgáltatás lesz érintett. A többi szolgáltatás továbbra is kezelni fogja a kéréseket. Ehhez képest a monolit architektúra egyik rosszul viselkedő összetevője lebonthatja az egész rendszert.
  • Megszünteti a technológiai verem iránti hosszú távú elkötelezettséget. Új szolgáltatás kifejlesztésekor kiválaszthat egy új technológiai halmot. Hasonlóképpen, ha egy meglévő szolgáltatást jelentősen megváltoztat, új technológiával is átírhatja.

  hátrányok

  Ennek a megoldásnak számos hátránya van:

  • A fejlesztőknek foglalkozniuk kell az elosztott rendszer létrehozásának további összetettségével:
    • A fejlesztőknek be kell vezetniük a szolgálatok közötti kommunikációs mechanizmust, és meg kell küzdeniük a részleges meghibásodásokkal.
    • A több szolgáltatást átfogó kérelmek végrehajtása bonyolultabb.
    • A szolgáltatások közötti interakciók tesztelése sokkal nehezebb. bonyolult
    • A több szolgáltatást átfogó kérelmek végrehajtása gondos koordinációt igényel a csapatok között.
    • A fejlesztői eszközök / IDE-k a monolitikus alkalmazások építésére irányulnak, és nem nyújtanak kifejezett támogatást az elosztott alkalmazások fejlesztéséhez.
  • A telepítés összetettsége. A termelésben a különféle szolgáltatásokból álló rendszer telepítése és kezelése is bonyolult.
  • Megnövekedett memóriafelhasználás. A mikroszolgáltatási architektúra N monolit alkalmazáspéldányt NxM szolgáltatáspéldányokkal helyettesít. Ha minden szolgáltatás a saját JVM-jében (vagy azzal egyenértékű) fut, ami általában szükséges a példányok elkülönítéséhez, akkor M-szer annyi JVM futásideje van. Sőt, ha minden szolgáltatás a saját virtuális gépén fut (pl. EC2 példány), mint a Netflix esetében, akkor a rezsi még magasabb.

  Problémák

  Vannak sok kérdés, amellyel foglalkoznia kell.

  Mikor kell használni a mikroszolgáltatás architektúráját?

  Ennek a megközelítésnek az egyik kihívása annak eldöntése, hogy mikor van értelme használni. A egy alkalmazás, gyakran nincsenek problémái, amelyeket ez a megközelítés megold. Ezenkívül egy bonyolult, elosztott architektúra használata lelassítja a fejlődést. Ez komoly problémát jelenthet azoknak az induló vállalkozásoknak, akiknek legnagyobb kihívása gyakran az üzleti modell és az azt kísérő modell gyors fejlesztése. alkalmazás. Az Y-tengelyes hasítások használata megnehezítheti a gyors iterációt. Később azonban, amikor a méretezés módja a kihívás, és funkcionális bontást kell használnia, a kusza függőségek megnehezítik monolitikus alkalmazásának lebontását szolgáltatások sora.

  Hogyan bontsuk le az applikát A szolgáltatások kihívása?

  Egy másik kihívás annak eldöntése, hogy miként lehet felosztani a rendszert mikroszolgáltatásokba. Ez nagyon is művészet, de számos stratégia segíthet:

  • Bontani üzleti képességek szerint és meghatározni az üzleti képességeknek megfelelő szolgáltatásokat.
  • Bomlás tartományvezérelt tervezési aldomain alapján.
  • Bontani ige vagy felhasználási eset alapján, és meghatározni azokat a szolgáltatásokat, amelyek felelősek bizonyos műveletekért. . például. egy Shipping Service, amely a teljes megrendelések szállításáért felelős.
  • Felsős névvel vagy erőforrásokkal lebontva meghatározhat egy szolgáltatást, amely az adott entitások / erőforrások minden műveletéért felelős. típus. például. egy Account Service, amely felelős a felhasználói fiókok kezeléséért.

  Ideális esetben minden szolgáltatásnak csak kis feladatokkal kell rendelkeznie. (Bob bácsi) az osztályok tervezéséről az Egységes Felelősség Elve (SRP) használatával foglalkozik. Az SRP az osztály felelősségét meghatározza a változás okaként, és kijelenti, hogy egy osztálynak csak egy oka lehet a változtatásra. Értelemszerű az SRP-t alkalmazni a szolgáltatás tervezésére

  Egy másik analógia, amely segíti a szolgáltatás tervezését, a Unix segédprogramok megtervezése. Az Unix nagyszámú segédprogramot biztosít, mint például a grep, a cat és a find. Minden segédprogram pontosan egy dolgot végez, gyakran kivételesen jól, és komplex feladatok végrehajtásához shell-szkriptet használó más segédprogramokkal kívánja kombinálni.

  Hogyan lehet fenntartani az adatok konzisztenciáját?

  A laza összekapcsolás biztosítása érdekében minden szolgáltatásnak megvan a sajátja adatbázis. A szolgáltatások közötti adatkonzisztencia fenntartása kihívást jelent, mert 2 fázis-elkötelezett / elosztott tranzakció nem opció sok alkalmazáshoz. Az alkalmazásnak ehelyett a Saga mintát kell használnia. A szolgáltatás eseményeket tesz közzé, amikor az adatai megváltoznak. Más szolgáltatások elfogyasztják az eseményt, és frissítik az adataikat. Az adatok megbízható frissítésének és az események közzétételének számos módja van, beleértve az Események beszerzését Tranzakciós napló szabása.

  Hogyan valósítsuk meg a lekérdezéseket?

  Egy másik kihívás olyan lekérdezések végrehajtása, amelyeknek több szolgáltatás tulajdonában lévő adatok beolvasására van szükségük.

  • Az API Összetétel és parancsparancslekérdezés-felelősség szegregáció (CQRS) minták.

  A mikroszolgáltatások mintájához sokféle minta kapcsolódik. A monolit architektúra a mikroszolgáltatás architektúrájának alternatívája. A többi minta megoldja azokat a problémákat, amelyekkel a mikroszolgáltatás architektúrájának alkalmazása során találkozhat.

  

  • Bomlási minták
    • Bontás üzleti képességek szerint
    • Bontás aldomainek szerint
  • Az adatbázis szolgáltatásonként leírja, hogy mindegyik szolgáltatás saját adatbázissal rendelkezik a laza összekapcsolás biztosítása érdekében. rendelkezésre álló szolgáltatáspéldány egy mikroszolgáltatási architektúrában.
  • Az üzenetküldési és a távoli eljárásmeghívási minták kétféle módon kommunikálhatnak a szolgáltatások.
  • Az Egységes szolgáltatás hosztonként és Több szolgáltatás hosztonként minták: két különböző telepítési stratégia.
  • Átfogó aggodalmi minták: Microservice alvázminta és külső konfiguráció
  • Tesztelési minták: Szolgáltatás-összetevő teszt és Szolgáltatás-integrációs szerződés teszt
  • Áramkör Megszakító
  • Hozzáférési token
  • Megfigyelhetőségi minták:
    • Napló összesítése
    • Alkalmazási mutatók
    • Naplózás naplózása
    • Elosztott nyomkövetés
    • Kivételkövetés
    • Állapotellenőrzési API
    • Naplófájlok telepítése és módosításai
  • Felhasználói felület mintái:
    • Szerveroldali oldaltöredék-összeállítás
    • Kliensoldali felhasználói felület-összeállítás

  Ismert felhasználások

  A legtöbb nagyméretű webhely, köztük a Netflix, az Amazon és az eBay monolit architektúrából mikroszolgáltatási architektúrává fejlődött.

  A Netflix, amely egy nagyon népszerű video streaming szolgáltatás, amely felelős az internetes forgalom akár 30% -ához is kiterjedt, szolgáltatás-orientált architektúrával rendelkezik. Naponta több mint egymilliárd hívást kezelnek video streaming API-jukra több mint 800 különféle eszközről. Minden API átlagosan hatnak hívja a rajongókat. hívások háttérszolgáltatásokra.

  Az Amazon.com eredetileg kétszintű architektúrával rendelkezett. A méretezés érdekében áttértek egy szolgáltatásorientált architektúrára, amely több száz háttérszolgáltatásból áll. Több alkalmazás hívja ezeket a szolgáltatásokat, beleértve az alkalmazásokat is. amelyek megvalósítják az Amazon.com webhelyet és a webszolgáltatás API-t. Az Amazon.com webhelyalkalmazás 100-150 szolgáltatást hív meg a Weboldal készítéséhez használt adatok.

  Az ebay.com aukciós webhely szintén monolit architektúrából szolgáltatásorientált architektúrává fejlődött. Az alkalmazásszint több független alkalmazásból áll. Mindegyik alkalmazás megvalósítja az üzleti logikát. egy adott funkcióterületen, például vásárlás vagy eladás esetén. Minden alkalmazás X tengelyes felosztásokat használ, egyes alkalmazások, például a keresés, a Z tengely felosztását használják. Az Ebay.com X-, Y- és Z-stílusú méretezés kombinációját is alkalmazza adatbázis-szint.

  Számos más példa van arra, hogy a vállalatok mikroszolgáltatás-architektúrát használnak.

  Chris Richardsonnak vannak példái mikroszolgáltatás-alapú alkalmazásokra.

  Lásd még

  Lásd a Code Freeze 2018 kulcstartómat, amely jól bemutatja a mikroszolgáltatás architektúráját.