Hónapokat töltött azzal, hogy monolitját mikroszolgáltatásokká alakítsa át, és végre mindenki összefogott, hogy átváltson. Megy az első weboldalra... és nem történik semmi. Újratöltöd - és megint semmi jó, az oldal olyan lassú, hogy néhány percig nem válaszol. Mi történt?
Előadásában Jimmy Bogard egy valós mikroszolgáltatási katasztrófáról készít „post mortem”-et. Bemutatja az általa felfedezett modellezési, fejlesztési és gyártási problémákat, és azt, hogy csapata hogyan alakította át lassan az új elosztott monolitot a józanság végső képévé. Bár lehetetlen teljesen megakadályozni a tervezési hibákat, legalább a tervezési folyamat korai szakaszában azonosíthatja a problémákat, hogy a végtermék megbízható elosztott rendszerré váljon.
Üdvözlök mindenkit, Jimmy vagyok, és ma hallani fogod, hogyan kerülheted el a nagy katasztrófákat a mikroszolgáltatások építése során. Ez egy cég története, amelynek körülbelül másfél évig dolgoztam, hogy megakadályozzam a hajójuk jéghegynek való ütközését. Ahhoz, hogy megfelelően elmondhassuk ezt a történetet, vissza kell mennünk az időben, és beszélnünk kell arról, honnan indult ez a cég, és hogyan fejlődött az idők során az IT-infrastruktúrája. A katasztrófában ártatlanok nevének védelme érdekében ennek a cégnek a nevét Bell Computersre változtattam. A következő dia bemutatja, hogyan nézett ki az ilyen cégek informatikai infrastruktúrája a 90-es évek közepén. Ez egy tipikus architektúra egy nagy, univerzális hibatűrő HP Tandem Mainframe szerverhez, amely számítógépes hardverboltot működtet.
Ki kellett építeniük egy rendszert az összes rendelés, értékesítés, visszaküldés, termékkatalógus és vevőkör kezelésére, ezért az akkoriban legelterjedtebb nagyszámítógépes megoldást választották. Ez az óriási rendszer minden információt tartalmazott a cégről, minden lehetségest, és minden tranzakció ezen a mainframe-en keresztül történt. Az összes tojást egy kosárban tartották, és azt gondolták, hogy ez normális. Itt csak a csomagküldő katalógusok és a telefonos rendelések nem szerepelnek.
Idővel a rendszer egyre nagyobb lett, és hatalmas mennyiségű szemét halmozódott fel benne. Ezenkívül a COBOL nem a világ legkifejezőbb nyelve, így a rendszer végül egy nagy, monolitikus szemét lett. 2000-re észrevették, hogy sok cégnek van olyan webhelye, amelyen keresztül teljes egészében üzleti tevékenységüket folytatja, és úgy döntöttek, hogy elkészítik első kereskedelmi dot-com webhelyét.
A kezdeti kialakítás nagyon szépnek tűnt, és egy felső szintű bell.com webhelyből és számos aldomainből állt az egyes alkalmazásokhoz: catalog.bell.com, accounts.bell.com, orders.bell.com, termékkereső search.bell. com. Mindegyik aldomain az ASP.Net 1.0 keretrendszert és a saját adatbázisait használta, és mindegyik a rendszer háttérrendszerével beszélt. Az összes megrendelés feldolgozása és végrehajtása azonban továbbra is egyetlen hatalmas mainframe-en belül zajlott, amelyben minden szemét maradt, de a front end külön weboldalak voltak, egyedi alkalmazásokkal és külön adatbázisokkal.
Tehát a rendszer kialakítása rendezettnek és logikusnak tűnt, de a tényleges rendszer olyan volt, mint a következő dián.
Minden elem egymás hívását, API-k elérését, harmadik féltől származó beágyazott dll-ek és hasonlók címét szolgálta. Gyakran előfordult, hogy a verziókezelő rendszerek megragadják valaki más kódját, betolják a projektbe, és akkor minden elromlott. Az MS SQL Server 2005 a linkszerverek fogalmát használta, és bár a dián nem mutattam a nyilakat, az adatbázisok mindegyike beszélt is egymással, mert nincs semmi baj azzal, ha több adatbázisból nyert adatok alapján táblákat készítünk.
Mivel most már elkülönültek a rendszer különböző logikai területei között, ez elosztott szennyeződésekké vált, és a legnagyobb szemétdarab még mindig a mainframe háttérben maradt.
A vicces az volt, hogy ezt a nagyszámítógépet a Bell Computers versenytársai építették, és továbbra is műszaki tanácsadóik tartották karban. Alkalmazásai nem kielégítő teljesítményéről meggyőződve a vállalat úgy döntött, hogy megszabadul tőlük, és újratervezi a rendszert.
A meglévő alkalmazás 15 évig volt gyártásban, ami rekordnak számít az ASP.Net alapú alkalmazásoknál. A szolgáltatás a világ minden tájáról fogadott megrendeléseket, és az egyetlen alkalmazásból származó éves bevétel elérte a milliárd dollárt. A profit jelentős részét a bell.com weboldal generálta. Fekete pénteken az oldalon keresztül leadott rendelések száma elérte a több milliót. A meglévő architektúra azonban nem tett lehetővé fejlesztést, mivel a rendszerelemek merev összekapcsolása gyakorlatilag nem tette lehetővé a szolgáltatás módosítását.
A legsúlyosabb probléma az volt, hogy az egyik országból nem lehetett megrendelést leadni, egy másikban kifizetni és egy harmadikba elküldeni, annak ellenére, hogy egy ilyen kereskedelmi rendszer nagyon elterjedt a globális vállalatoknál. A meglévő weboldal ilyesmit nem tett lehetővé, így ezeket a megrendeléseket telefonon kellett elfogadniuk és leadniuk. Ez oda vezetett, hogy a vállalat egyre inkább az architektúra megváltoztatásán gondolkodott, különös tekintettel a mikroszolgáltatásokra való átállásra.
Okosan cselekedtek azzal, hogy megnéztek más cégeket, hogy lássák, hogyan oldottak meg egy hasonló problémát. Az egyik ilyen megoldás a Netflix szolgáltatásarchitektúra volt, amely API-n keresztül összekapcsolt mikroszolgáltatásokból és egy külső adatbázisból áll.
A Bell Computers vezetése úgy döntött, hogy bizonyos alapelveket betartva éppen ilyen architektúrát épít fel. Először is, megosztott adatbázis-megközelítés alkalmazásával kiküszöbölték az adatok megkettőzését. Nem küldtek adatokat, ellenkezőleg, mindenkinek, akinek szüksége volt rá, központi forráshoz kellett mennie. Ezt követte az elszigeteltség és az autonómia – minden szolgáltatás független volt a többitől. Úgy döntöttek, hogy abszolút mindenre a Web API-t használják – ha adatokat akart szerezni vagy módosítani akart egy másik rendszeren, mindezt a Web API-n keresztül tette meg. Az utolsó nagy dolog a "Bell on Bell" nevű új mainframe volt, szemben a versenytársak hardverén alapuló "Bell" nagyszámítógéppel.
Így 18 hónap leforgása alatt ezekre az alapelvek köré építették fel a rendszert, és elhozták a gyártás előtt. A hétvége után munkába állva a fejlesztők összefogtak és bekapcsolták az összes szervert, amelyre az új rendszer csatlakozott. 18 hónap munka, több száz fejlesztő, a legmodernebb Bell hardver – és semmi pozitív eredmény! Ez sok embernek csalódást okozott, mert sokszor futtatták ezt a rendszert a laptopjukon, és minden rendben volt.
Okosan tettek minden pénzüket a probléma megoldására. Felszerelték a legmodernebb szerverállványokat kapcsolókkal, gigabites optikai szálat használtak, a legerősebb szerverhardvert őrülten sok RAM-mal, mindezt összekötötték, konfigurálták – és megint semmi! Aztán gyanakodni kezdtek, hogy az ok az időtúllépések lehet, ezért bementek az összes webbeállításba, minden API beállításba, és frissítették a teljes időtúllépési konfigurációt a maximális értékekre, így csak ülni tudtak és várni, hogy történjen valami. az oldalra. Vártak és vártak és vártak 9 és fél percig, amíg a weboldal végre betöltődött.
Ezek után feltűnt nekik, hogy a jelenlegi helyzet alapos elemzést igényel, és meghívtak minket. Az első dolog, amit megtudtunk, az volt, hogy a fejlesztés mind a 18 hónapja alatt egyetlen igazi „mikro” sem született – minden csak nagyobb lett. Ezt követően elkezdtünk írni egy post mortem, más néven „regretrospektíva”, vagy „szomorú retrospektív”, más néven „hibás vihar”, hasonló az „agyviharhoz”, hogy megértsük a katasztrófa okát.
Számos nyomunk volt, amelyek közül az egyik a teljes forgalomtelítettség volt az API-hívás idején. Ha monolitikus szolgáltatásarchitektúrát használ, azonnal megértheti, hogy pontosan mi hibázott, mert egyetlen verem nyomkövetése van, amely mindent jelent, ami a hibát okozhatta. Abban az esetben, ha egy csomó szolgáltatás egyszerre éri el ugyanazt az API-t, a nyomkövetés nyomon követésére nincs mód, kivéve további hálózati megfigyelő eszközök, például a WireShark használata, amelyeknek köszönhetően egyetlen kérést megvizsgálhat, és megtudhatja, mi történt a megvalósítás során. Ezért vettünk egy weboldalt, és majdnem 2 hetet töltöttünk a puzzle darabjainak összerakásával, különféle felhívásokkal, és elemeztük, hogy mindegyik mire vezet.
Nézd meg ezt a képet. Azt mutatja, hogy egy külső kérés arra készteti a szolgáltatást, hogy több belső hívást indítson, amelyek visszatérnek. Kiderült, hogy minden belső hívás további ugrásokat hajt végre, hogy önállóan ki tudja szolgálni ezt a kérést, mert nem tud máshová fordulni a szükséges információk megszerzéséért. Ez a kép a hívások értelmetlen kaszkádjának tűnik, mivel a külső kérés többletszolgáltatást hív meg, amely más kiegészítő szolgáltatásokat hív meg, és így tovább, szinte a végtelenségig.
A zöld szín ezen az ábrán egy félkört mutat, amelyben a szolgáltatások hívják egymást - az A szolgáltatás hívja a B szolgáltatást, a B szolgáltatás hívja a C szolgáltatást, és újra hívja az A szolgáltatást. Ennek eredményeként „elosztott holtpontot” kapunk. Egyetlen kérés ezer hálózati API-hívást hozott létre, és mivel a rendszer nem rendelkezik beépített hibatűréssel és hurokvédelemmel, a kérés sikertelen lesz, ha ezen API-hívások közül akár egy is meghiúsul.
Kicsit számoltunk. Az egyes API-hívások SLA-ja nem haladta meg a 150 ms-ot és 99,9%-os rendelkezésre állást. Egy kérés 200 különböző hívást okozott, és a legjobb esetben az oldal 200 x 150 ms = 30 másodperc alatt jelenhetett meg. Ez természetesen nem volt jó. A 99,9%-os rendelkezésre állást 200-zal megszorozva 0%-os rendelkezésre állást kaptunk. Kiderült, hogy ez az architektúra kezdettől fogva kudarcra volt ítélve.
Megkérdeztük a fejlesztőket, hogy 18 hónapos munka után miért nem vették észre ezt a problémát? Kiderült, hogy csak az általuk futtatott kódra számolták az SLA-t, de ha a szolgáltatásuk másik szolgáltatást hívott, azt az időt nem számolták bele az SLA-ba. Minden, ami egy folyamaton belül elindult, betartotta a 150 ms-os értéket, de a többi szolgáltatási folyamathoz való hozzáférés többszörösére növelte a teljes késleltetést. Az első tanulság a következő volt: „Ön irányítja az SLA-t, vagy az SLA irányítja Önt?” Esetünkben ez utóbbi volt.
A következő dolog, amit felfedeztünk, az volt, hogy tudtak a Peter Deitch és James Gosling által megfogalmazott elosztott számítási tévhitek fogalmáról, de figyelmen kívül hagyták annak első részét. Azt állítja, hogy a „hálózat megbízható”, „nulla késleltetés” és „végtelen átviteli sebesség” állítások tévhitek. További tévhitek közé tartoznak a „hálózat biztonságos”, „a topológia soha nem változik”, „mindig csak egy rendszergazda van”, „az adatátvitel költsége nulla” és „a hálózat homogén” kijelentések.
Hibát követtek el, mert helyi gépeken tesztelték szolgáltatásukat, és soha nem csatlakoztak külső szolgáltatásokhoz. Helyi fejlesztéskor és helyi gyorsítótár használatakor soha nem találkoztak hálózati ugrással. A fejlesztés mind a 18 hónapja során egyszer sem gondolkodtak el azon, hogy mi történhetne, ha a külső szolgáltatásokat érintené.
Ha megnézi az előző képen látható szolgáltatási határokat, láthatja, hogy mindegyik helytelen. Rengeteg forrás van, amely tanácsot ad a szolgáltatási határok meghatározásához, és a legtöbb rosszul csinálja, például a következő dián a Microsoft.
Ez a kép az MS blogról származik, „Hogyan építsünk mikroszolgáltatásokat” témában. Ez egy egyszerű webalkalmazást, egy üzleti logikai blokkot és egy adatbázist mutat. A kérés közvetlenül érkezik, valószínűleg van egy szerver a webhez, egy szerver a vállalkozáshoz és egy az adatbázishoz. Ha növeli a forgalmat, a kép kissé megváltozik.
Itt jön egy terheléselosztó a forgalom elosztására két webszerver között, egy gyorsítótár a webszolgáltatás és az üzleti logika között, valamint egy másik gyorsítótár az üzleti logika és az adatbázis között. A Bell pontosan ezt az architektúrát használta a terheléselosztáshoz és a kék/zöld telepítési alkalmazáshoz a 2000-es évek közepén. Egy ideig minden jól működött, mivel ezt a sémát monolitikus szerkezetre tervezték.
A következő képen látható, hogy az MS hogyan javasolja a monolitról a mikroszolgáltatásokra való átállást – egyszerűen az egyes fő szolgáltatásokat külön mikroszolgáltatásokra osztva. Bell ennek a rendszernek a végrehajtása során követett el hibát.
Minden szolgáltatásukat különböző szintekre osztották, amelyek mindegyike számos egyedi szolgáltatásból állt. Például a webszolgáltatás tartalmazott mikroszolgáltatásokat a tartalom megjelenítéséhez és hitelesítéséhez, az üzleti logikai szolgáltatás a rendelések és a számlainformációk feldolgozására szolgáló mikroszolgáltatásokból állt, az adatbázis egy csomó mikroszolgáltatásra volt felosztva speciális adatokkal. Mind a web, mind az üzleti logika, mind az adatbázis állapot nélküli szolgáltatás volt.
Ez a kép azonban teljesen téves volt, mert nem térképezett fel egyetlen üzleti egységet sem a cég informatikai klaszterén kívül. Ez a séma nem vett figyelembe semmilyen kapcsolatot a külvilággal, így nem volt világos, hogyan lehet például harmadik féltől származó üzleti elemzéseket szerezni. Megjegyzem, több olyan szolgáltatást is kitaláltak, amelyek egyszerűen az egyes alkalmazottak karrierjének fejlesztését szolgálták, akik igyekeztek minél több embert irányítani, hogy több pénzt kapjanak érte.
Úgy gondolták, hogy a mikroszolgáltatásokra való áttérés olyan egyszerű, mint a belső, N-szintű fizikai rétegbeli infrastruktúrájuk használata, és ráragasztani a Dockert. Nézzük meg, hogyan néz ki a hagyományos N-szintű architektúra.
4 szintből áll: az UI felhasználói felület szintje, az üzleti logikai szint, az adathozzáférési szint és az adatbázis. Progresszívebb a DDD (Domain-Driven Design) vagy szoftver-orientált architektúra, ahol a két középső szint a tartományobjektumok és a tároló.
Megpróbáltam ebben az architektúrában különböző változási területeket, különböző felelősségi területeket szemlélni. Egy tipikus N-szintű alkalmazásban a változás különböző területeit osztályozzák, amelyek függőlegesen felülről lefelé haladnak át a szerkezeten. Ezek a katalógus, az egyes számítógépeken végrehajtott konfigurációs beállítások és a Checkout ellenőrzések, amelyeket a csapatom kezelt.
Ennek a sémának az a sajátossága, hogy ezen változási területek határai nem csak az üzleti logikai szintet érintik, hanem az adatbázisra is kiterjednek.
Nézzük meg, mit jelent szolgáltatásnak lenni. A szolgáltatásdefiníciónak 6 jellemző tulajdonsága van – ez egy szoftver, amely:
- egy adott szervezet által létrehozott és használt;
- felelős bizonyos típusú információk tartalmáért, feldolgozásáért és/vagy szolgáltatásáért a rendszeren belül;
- önállóan megépíthető, telepíthető és működtethető, hogy megfeleljen a konkrét működési igényeknek;
- kommunikál a fogyasztókkal és egyéb szolgáltatásokkal, megállapodások vagy szerződéses garanciák alapján tájékoztatást nyújt;
- megvédi magát a jogosulatlan hozzáféréstől, információit pedig az elvesztéstől;
- a hibákat úgy kezeli, hogy azok ne vezessenek információkárosodáshoz.
Mindezek a tulajdonságok egy szóval „autonómia” fejezhetők ki. A szolgáltatások egymástól függetlenül működnek, eleget tesznek bizonyos korlátozásoknak, és olyan szerződéseket határoznak meg, amelyek alapján az emberek megkaphatják a számukra szükséges információkat. Konkrét technológiákat nem említettem, amelyek használata magától értetődő.
Most nézzük a mikroszolgáltatások definícióját:
- a mikroszolgáltatás kis méretű, és egy adott probléma megoldására szolgál;
- A mikroszolgáltatás autonóm;
- A mikroszolgáltatási architektúra létrehozásakor a várostervezési metafora használatos. Ez a meghatározás Sam Newman Building Microservices című könyvéből.
A Bounded Context meghatározása Eric Evans Domain-Driven Design című könyvéből származik. Ez egy alapvető minta a DDD-ben, egy építészeti tervezőközpontban, amely volumetrikus építészeti modellekkel dolgozik, felosztja azokat különböző határos kontextusokra, és kifejezetten meghatározza a köztük lévő kölcsönhatásokat.
Egyszerűen fogalmazva, a határos kontextus azt a hatókört jelöli, amelyben egy adott modul használható. Ebben az összefüggésben egy logikailag egységes modell található, amely például az Ön üzleti tartományában látható. Ha azt kérdezed a megrendelésekben részt vevő személyzettől, hogy „ki az ügyfél”, akkor egy definíciót kapsz, ha az értékesítésben érintetteket kérdezed, akkor egy másikat, az előadók pedig egy harmadikat.
Tehát a Bounded Context azt mondja, hogy ha nem tudjuk egyértelműen meghatározni, hogy mi a szolgáltatásaink fogyasztója, határozzuk meg azokat a határokat, amelyeken belül beszélhetünk ennek a kifejezésnek a jelentéséről, majd határozzuk meg a különböző definíciók közötti átmeneti pontokat. Vagyis ha rendelés feladási oldalról beszélünk ügyfélről, akkor ez ezt-azt jelenti, ha pedig értékesítés szempontjából, akkor ez ezt-azt.
A mikroszolgáltatás következő definíciója mindenféle belső művelet beágyazása, megakadályozva a munkafolyamat összetevőinek „kiszivárgását” a környezetbe. Következik a „explicit szerződések külső interakciókra vagy külső kommunikációra” meghatározása, amelyet az SLA-kból visszatérő szerződések gondolata képvisel. Az utolsó definíció a sejt vagy sejt metaforája, amely egy mikroszolgáltatáson belüli műveletek teljes beágyazását és a külvilággal való kommunikációt szolgáló receptorok jelenlétét jelenti benne.
Így hát azt mondtuk a Bell Computers srácainak: „Nem tudjuk megjavítani az általatok teremtett káoszt, mert nincs rá pénzetek, de csak egy szolgáltatást fogunk javítani, hogy az egész létrejöjjön. érzék." Ezen a ponton azzal kezdem, hogy elmondom, hogyan javítottuk ki egyetlen szolgáltatásunkat, hogy az 9 és fél percnél gyorsabban válaszoljon a kérésekre.
22:30 perc
Folytatás hamarosan...
Némi reklám
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com