Josh Evans a Netflix mikroszolgáltatásainak kaotikus és színes világáról beszél, kezdve az alapokkal – a mikroszolgáltatások anatómiájával, az elosztott rendszerekkel kapcsolatos kihívásokkal és előnyeivel. Erre az alapra építve feltárja azokat a kulturális, építészeti és működési gyakorlatokat, amelyek a mikroszolgáltatások elsajátításához vezetnek.
Az operatív sodródástól eltérően az új nyelvek bevezetése a szolgáltatások nemzetközivé tételéhez és az olyan új technológiák, mint a konténerek, tudatos döntések, amelyek új komplexitást adnak a környezetnek. Műveleti csapatom a Netflix legjobb technológiai ütemtervét szabványosította, amely előre meghatározott, Java és EC2 alapú bevált gyakorlatokba épült be, de az üzlet növekedésével a fejlesztők új összetevőket kezdtek hozzáadni, például Python, Ruby, Node-JS és Docker.
Nagyon büszke vagyok arra, hogy mi voltunk az elsők, akik kiálltunk amellett, hogy termékünk kiválóan működjön anélkül, hogy megvárnánk a vásárlói panaszokat. Az egész elég egyszerűnek indult – működési programjaink voltak Pythonban és néhány háttéralkalmazásunk Rubyban, de a dolgok sokkal érdekesebbé váltak, amikor webfejlesztőink bejelentették, hogy lemondanak a JVM-ről, és áthelyezik az internetet. alkalmazás a Node szoftverplatformhoz. A Docker bevezetése után a dolgok sokkal összetettebbé váltak. Logikát követtünk, és az általunk kidolgozott technológiák valósággá váltak, amikor bevezettük őket az ügyfelek számára, mert sok értelme volt. Elmondom, miért van ez így.
Az API Gateway valóban képes olyan nagyszerű szkriptek integrálására, amelyek végpontként működhetnek a felhasználói felület fejlesztői számára. Ezeket a szkripteket úgy alakították át, hogy a változtatások elvégzése után üzembe helyezhessék őket az éles, majd a felhasználói eszközökön, és mindezeket a változtatásokat szinkronizálták az API-átjáróban futó végpontokkal.
Ez azonban megismételte az új monolit létrehozásának problémáját, ahol az API-szolgáltatás túlterhelt kóddal oly módon, hogy különféle meghibásodási forgatókönyvek fordultak elő. Például egyes végpontokat eltávolítottak, vagy a parancsfájlok véletlenszerűen olyan sok verziót hoztak létre valaminek, hogy a verziók elfoglalták az API-szolgáltatás összes rendelkezésre álló memóriáját.
Logikus volt ezeket a végpontokat kivenni az API szolgáltatásból. Ennek érdekében Node.js összetevőket hoztunk létre, amelyek kis alkalmazásokként futottak Docker-tárolókban. Ez lehetővé tette számunkra, hogy elkülönítsük az ezen csomópontalkalmazások által okozott problémákat és összeomlásokat.
E változtatások költsége meglehetősen nagy, és a következő tényezőkből áll:
- Termelékenységi eszközök. Az új technológiák menedzseléséhez új eszközökre volt szükség, mert a felhasználói felület csapatának nagyon jó szkripteket használva egy hatékony modell létrehozásához nem kellett sok időt töltenie az infrastruktúra menedzselésével, csak szkripteket kellett írni és ellenőrizni a működőképességüket.
Opportunity Insight and Sorting – A kulcsfontosságú példa a teljesítmény-illesztőprogram-információk feltárásához szükséges új eszközök. Tudni kellett, hogy mennyit foglalt a processzor, hogyan használja a memóriát, és ezeknek az információknak az összegyűjtése különböző eszközöket igényel. - Az alapképek töredezettsége – az egyszerű alap AMI töredezettebbé és speciálisabbá vált.
- Csomópontkezelés. Nem áll rendelkezésre olyan készen álló architektúra vagy technológia, amely lehetővé tenné a csomópontok kezelését a felhőben, ezért megépítettük a Titust, egy konténerkezelő platformot, amely méretezhető és megbízható konténertelepítést és felhőintegrációt biztosít az Amazon AWS-szel.
- Egy könyvtár vagy platform megkettőzése. A platform azonos alapvető funkcióival rendelkező új technológiák biztosításához szükség volt a felhőalapú Node.js fejlesztői eszközökbe történő lemásolására.
- Tanulási görbe és ipari tapasztalat. Az új technológiák bevezetése elkerülhetetlenül új kihívásokat jelent, amelyeket le kell győzni, és tanulni kell belőlük.
Így nem korlátozódhattunk egyetlen „kövezett útra”, és folyamatosan új utakat kellett kiépíteni technológiáink fejlesztésére. A költségek csökkentése érdekében korlátoztuk a központosított támogatást, és a JVM-re, az új csomópontokra és a Dockerre összpontosítottunk. Előnyben részesítettük a hatékony hatást, tájékoztattuk a csapatokat döntéseik költségeiről, és arra ösztönöztük őket, hogy keressenek módokat a már kifejlesztett nagy hatású megoldások újrahasznosítására. Ezt a megközelítést alkalmaztuk a szolgáltatás idegen nyelvekre történő lefordításakor, hogy a terméket nemzetközi ügyfelekhez eljuttassuk. A példák közé tartoznak a viszonylag egyszerű klienskönyvtárak, amelyek automatikusan generálhatók, így meglehetősen könnyű létrehozni Python verziót, Ruby verziót, Java verziót stb.
Folyamatosan kerestük a lehetőségeket olyan bevált technológiák alkalmazására, amelyek egy helyen és más hasonló helyzetekben is beváltak.
Beszéljünk az utolsó elemről - a változtatásokról vagy változatokról. Nézd meg, hogy termékünk fogyasztása a hét napjánként és a nap folyamán óránként egyenetlenül változik. Mondhatni, reggel 9 óra a legnehezebb időszak a Netflix számára, amikor a rendszer terhelése eléri a maximumot.
Hogyan érhetjük el a szoftveres újítások gyors megvalósítását, azaz a rendszer folyamatos újítását anélkül, hogy a szolgáltatásnyújtás fennakadása és az ügyfeleink számára kellemetlenség okozna? A Netflix ezt a Spinnaker, egy új globális felhőalapú felügyeleti és folyamatos szállítási (CD) platform használatával érte el.
Lényeges, hogy a Spinnakert úgy tervezték, hogy integrálja a legjobb gyakorlatainkat, hogy az összetevők gyártásba történő bevezetésekor a kimenetet közvetlenül a médiatovábbítási technológiánkba integrálhassuk.
Két olyan technológiát tudtunk beépíteni a szállítási folyamatunkba, amelyeket nagyra értékelünk: az automatizált kanári elemzést és a szakaszos telepítést. A Canary-elemzés azt jelenti, hogy a forgalom egy szivárgó részét a kód új verziójára irányítjuk, a többi éles forgalmat pedig a régi verzión keresztül továbbítjuk. Ezután ellenőrizzük, hogy az új kód hogyan birkózik meg a feladattal - jobban vagy rosszabbul, mint a meglévő.
A lépcsőzetes közzététel azt jelenti, hogy ha az egyik régióban történő közzétételnél problémák vannak, akkor áttérünk egy másik régióban történő közzétételre. Ebben az esetben a fent említett ellenőrző listát szerepeltetni kell a gyártási folyamatban. Megspórolok Önnek egy kis időt, és azt javaslom, hogy tekintse meg korábbi, Globális Netflix-műveletek tervezése a felhőben című előadásomat, ha szeretne mélyebben elmerülni ebben a témában. A beszédről készült videofelvétel a dia alján található linken tekinthető meg.
Az előadás végén röviden szólok a Netflix szervezetéről és felépítéséről. Kezdetben volt egy Electronic Delivery nevű sémánk, amely az NVT 1.x média streaming első verziója volt. A "backstream" kifejezés azért használható itt, mert kezdetben a felhasználó csak tartalmat tudott letölteni későbbi lejátszáshoz az eszközön. A Netflix legelső digitális szállítási platformja, még 2009-ben, valahogy így nézett ki.
A felhasználói eszköz tartalmazta a Netflix alkalmazást, amely egy UI felületből, biztonsági modulokból, szolgáltatásaktiválásból és lejátszásból állt, az NRDP platformon – Netflix Ready Device Platform – alapulva.
Abban az időben a felhasználói felület nagyon egyszerű volt. Tartalmaz egy úgynevezett Queque Readert, és a felhasználó felkereste a webhelyet, hogy hozzáadjon valamit a Queque-hez, majd megtekintse a hozzáadott tartalmat az eszközén. Pozitívum volt, hogy a front end csapat és a hátsó csapat ugyanahhoz az Electronic Delivery szervezethez tartozott, és szoros munkakapcsolatban állt. A rakomány XML alapján készült. Ezzel egy időben létrejött a DVD-üzletág Netflix API-ja, amely arra ösztönözte a harmadik féltől származó alkalmazásokat, hogy a forgalmat a szolgáltatásunkra irányítsák.
A Netflix API azonban jól felkészült arra, hogy egy innovatív felhasználói felülettel segítsen bennünket, amely tartalmazza az összes tartalom metaadatait, információkat arról, hogy milyen filmek érhetők el, ami lehetővé tette a figyelési listák létrehozását. Volt egy általános REST API-ja, amely a JSON sémán alapult, a HTTP válaszkód, ugyanaz, amit a modern architektúrában használnak, és egy OAuth biztonsági modell, amely akkoriban szükséges volt egy front-end alkalmazáshoz. Ez lehetővé tette a streaming tartalomszolgáltatás nyilvános modelljéről a privát modellre való áttérést.
Az átállás problémája a széttagoltság volt, hiszen mostanra két teljesen eltérő működési elv alapján működő szolgáltatást üzemeltetett rendszerünk - az egyiket Rest, JSON és OAuth, a másik RPC, XML és egy NTBA token rendszerre épülő felhasználói biztonsági mechanizmus. Ez volt az első hibrid architektúra.
Lényegében tűzfal volt a két csapatunk között, mert az API kezdetben nem skálázódott túl jól az NCCP-vel, és ez súrlódásokhoz vezetett a csapatok között. A különbségek a szolgáltatásokban, protokollokban, áramkörökben, biztonsági modulokban voltak, és a fejlesztőknek gyakran teljesen más kontextusok között kellett váltaniuk.
Ezzel kapcsolatban beszélgettem a cég egyik vezető mérnökével, akinek feltettem a kérdést: „Mi legyen a megfelelő hosszú távú architektúra?”, ő pedig feltette az ellenkérdést: „Valószínűleg Ön jobban aggódik. a szervezeti következményekről - mi történik, ha ezeket a dolgokat integráljuk, és megtörik azt, amit megtanultunk jól csinálni? Ez a megközelítés nagyon releváns Conway törvénye szempontjából: "Azokat a szervezeteket, amelyek rendszereket terveznek, olyan tervezés korlátozza, amely megismétli az adott szervezet kommunikációs struktúráját." Ez egy nagyon elvont meghatározás, ezért inkább egy konkrétabbat választok: „Bármely szoftver azt a szervezeti struktúrát tükrözi, amely létrehozta.” Íme a kedvenc idézetem Eric Raymondtól: "Ha négy fejlesztőcsapat dolgozik egy fordítón, akkor a végén egy négymenetes fordítót kapsz." Nos, a Netflixnek van egy négymenetes fordítója, és mi így dolgozunk.
Azt mondhatjuk, hogy ebben az esetben a farok csóválja a kutyát. Elsődleges prioritásunk nem a megoldás, hanem a szervezet; a szervezet az, amely a meglévő architektúrát vezérli. Fokozatosan a szolgáltatások sokaságából áttértünk egy olyan architektúrára, amelyet Blade Runnernek hívtunk, mert itt az élszolgáltatásokról és az NCCP azon képességéről van szó, hogy elválasztható és közvetlenül integrálható a Zuul proxyba, API átjáróba és a megfelelő funkcióba. A „darabokból” új mikroszolgáltatások lettek, fejlettebb biztonsági, visszajátszási, adatrendezési stb. funkciókkal.
Így elmondható, hogy a szervezeti egységek struktúrái és a vállalati dinamika fontos szerepet játszanak a rendszertervezés alakításában, és változást elősegítő vagy akadályozó tényező. A mikroszolgáltatások architektúrája összetett és szerves, egészsége a fegyelemre és a bevezetett káoszra épül.
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