Josh Evans parolas pri la ĥaosa kaj bunta mondo de Netflix-mikroservoj, komencante per la bazaĵoj mem - la anatomio de mikroservoj, la defioj asociitaj kun distribuitaj sistemoj, kaj iliaj avantaĝoj. Konstruante sur ĉi tiu fundamento, li esploras la kulturajn, arkitekturajn kaj funkciajn praktikojn, kiuj kondukas al mikroserva majstrado.
Male al funkcia drivo, la enkonduko de novaj lingvoj por serva internaciigo kaj novaj teknologioj kiel ujoj estas konsciaj decidoj por aldoni novan kompleksecon al la medio. Mia operacia teamo normigis la plej bonan teknologian vojmapon por Netflix, kiu estis bakita en antaŭdifinitajn plej bonajn praktikojn bazitajn sur Java kaj EC2, sed dum la komerco kreskis, programistoj komencis aldoni novajn komponantojn kiel Python, Ruby, Node-JS kaj Docker.
Mi tre fieras, ke ni estis la unuaj, kiuj pledis, ke nia produkto bone funkciu sen atendi klientajn plendojn. Ĉio komenciĝis sufiĉe simple - ni havis operaciumajn programojn en Python kaj kelkajn administrajn aplikaĵojn en Ruby, sed aferoj fariĝis multe pli interesaj kiam niaj retaj programistoj anoncis, ke ili forĵetos la JVM kaj movos la reton. aplikaĵo al la platformo de programaro Node.js. Post la enkonduko de Docker, aferoj fariĝis multe pli kompleksaj. Ni sekvis logikon kaj la teknologioj, kiujn ni elpensis, realiĝis kiam ni efektivigis ilin por klientoj ĉar ili havis multe da senco. Mi diros al vi kial ĉi tio estas tiel.
API Gateway fakte havas la kapablon integri bonegajn skriptojn, kiuj povas funkcii kiel finpunktoj por UI-programistoj. Ili konvertis ĉiun el ĉi tiuj skriptoj tiel ke post fari ŝanĝojn ili povis deploji ilin al produktado kaj poste al uzantaj aparatoj, kaj ĉiuj ĉi tiuj ŝanĝoj estis sinkronigitaj kun finpunktoj kiuj funkciis en la API-enirejo.
Tamen, ĉi tio ripetis la problemon de kreado de nova monolito kie la API-servo estis troŝarĝita per kodo tiel ke diversaj malsukcesaj scenaroj okazis. Ekzemple, iuj finpunktoj estis forigitaj, aŭ skriptoj hazarde generis tiom da versioj de io, ke la versioj okupis la tutan disponeblan memoron de la API-servo.
Estis logike preni ĉi tiujn finpunktojn kaj eltiri ilin el la API-servo. Por fari tion, ni kreis Node.js-komponentojn, kiuj funkciis kiel malgrandaj aplikoj en Docker-ujoj. Ĉi tio permesis al ni izoli ajnajn problemojn kaj kraŝojn kaŭzitajn de ĉi tiuj nodaj aplikoj.
La kosto de ĉi tiuj ŝanĝoj estas sufiĉe granda kaj konsistas el la sekvaj faktoroj:
- Produktivecaj iloj. Administri novajn teknologiojn postulis novajn ilojn ĉar la UI-teamo, uzante tre bonajn skriptojn por krei efikan modelon, ne devis pasigi multe da tempo administrante la infrastrukturon, ili devis nur skribi skriptojn kaj kontroli sian funkciecon.
Ŝanco-Komprado kaj Ordigo - Ŝlosila ekzemplo estas la novaj iloj bezonataj por malkovri informojn pri agado de ŝoforoj. Necesis scii kiom multe la procesoro estas okupita, kiel memoro estas uzata, kaj kolekti ĉi tiujn informojn postulis malsamajn ilojn. - Fragmentado de bazaj bildoj - la simpla baza AMI fariĝis pli fragmenta kaj specialigita.
- Administrado de nodoj. Ne estas disponebla arkitekturo aŭ teknologio ne disponebla, kiu ebligas al vi administri nodojn en la nubo, do ni konstruis Titus, kontenera administradplatformo, kiu provizas skaleblan kaj fidindan kontendeplojon kaj nuban integriĝon kun Amazon AWS.
- Duobligo de biblioteko aŭ platformo. Provizi novajn teknologiojn per la sama kerna funkcieco de la platformo postulis duobligi ĝin en nub-bazitajn programilojn de Node.js.
- Lerna kurbo kaj industria sperto. La enkonduko de novaj teknologioj neeviteble kreas novajn defiojn, de kiuj oni devas venki kaj lerni.
Tiel, ni ne povis limigi nin al unu "pavimita vojo" kaj devis konstante konstrui novajn manierojn progresigi niajn teknologiojn. Por malpliigi kostojn, ni limigis centralizitan subtenon kaj koncentriĝis pri la JVM, novaj nodoj kaj Docker. Ni prioritatis efikan efikon, informis teamojn pri la kosto de iliaj decidoj kaj instigis ilin serĉi manierojn reuzi la alt-efikajn solvojn, kiujn ili jam evoluigis. Ni uzis ĉi tiun aliron kiam tradukis la servon al fremdaj lingvoj por liveri la produkton al internaciaj klientoj. Ekzemploj inkluzivas relative simplajn klientbibliotekojn kiuj povas esti generitaj aŭtomate, tiel ke estas sufiĉe facile krei Python-version, Ruby-version, Java-version, ktp.
Ni konstante serĉis ŝancojn uzi pruvitajn teknologiojn, kiuj pruvis sin en unu loko kaj en aliaj similaj situacioj.
Ni parolu pri la lasta elemento - ŝanĝoj, aŭ varioj. Rigardu kiel la konsumo de nia produkto varias malegale laŭ tago de la semajno kaj laŭ horo dum la tago. Vi povus diri, ke 9 a.m. estas la plej malfacila tempo por Netflix, kiam la ŝarĝo sur la sistemo atingas sian maksimumon.
Kiel ni povas atingi altan rapidecon de efektivigo de programaj novigoj, tio estas, konstante fari novajn ŝanĝojn al la sistemo, sen kaŭzi interrompojn en servo livero kaj sen krei ĝenon al niaj klientoj? Netflix atingis tion per la uzo de Spinnaker, nova tutmonda nub-bazita administrado kaj kontinua livero (KD) platformo.
Kritike, Spinnaker estis desegnita por integri niajn plej bonajn praktikojn por ke dum ni deplojas komponentojn en produktadon, ni povas integri la produktaĵon rekte en nian amaskomunikilaran liverteknologion.
Ni povis korpigi du teknologiojn en nian liveran dukton, kiujn ni alte taksas: aŭtomatigita kanaria analizo kaj surscenigita deplojo. Kanaria analizo signifas, ke ni direktas fluton de trafiko al la nova versio de la kodo, kaj pasas la reston de la produktada trafiko tra la malnova versio. Tiam ni kontrolas kiel la nova kodo traktas la taskon - pli bone aŭ pli malbona ol la ekzistanta.
Ŝancelita lanĉo signifas, ke se lanĉo en unu regiono havas problemojn, ni moviĝas al lanĉo en alia regiono. En ĉi tiu kazo, la supre menciita kontrola listo devas esti inkluzivita en la produktaddukto. Mi ŝparos al vi iom da tempo kaj rekomendos, ke vi rigardu mian antaŭan paroladon, Inĝenieristiko de Tutmondaj Netflix-Operacioj en la Nubo, se vi interesiĝas plonĝi pli profunde en ĉi tiun temon. La videoregistraĵo de la parolado povas esti spektita sekvante la ligilon ĉe la malsupro de la diapozitivo.
Fine de la parolado, mi mallonge parolos pri la organizo kaj arkitekturo de Netflix. Ĉe la komenco ni havis skemon nomitan Elektronika Livero, kiu estis la unua versio de NRDP 1.x amaskomunikila fluo. La esprimo "backstream" povas esti uzata ĉi tie ĉar komence la uzanto povis nur elŝuti enhavon por poste reludi sur la aparato. La unua cifereca liverplatformo de Netflix, reen en 2009, aspektis io tiel.
La uzant-aparato enhavis la Netflix-aplikaĵon, kiu konsistis el UI-interfaco, sekurecmoduloj, servo-aktivigo kaj reproduktado, bazita sur la NRDP-platformo - Netflix Ready Device Platform.
Tiutempe la uzantinterfaco estis tre simpla. Ĝi enhavis kio estis nomita Queque Reader, kaj la uzanto irus al la retejo por aldoni ion al Queque kaj tiam vidi la aldonitan enhavon sur sia aparato. La pozitivo estis ke la antaŭa finteamo kaj la malantaŭa finteamo apartenis al la sama Electronic Delivery-organizo kaj havis proksiman laborrilaton. La utila ŝarĝo estis kreita surbaze de XML. Samtempe, la Netflix API por la DVD-komerco estis kreita, kiu instigis al triapartaj aplikoj direkti trafikon al nia servo.
Tamen, la Netflix API estis bone preparita por helpi nin kun noviga uzantinterfaco, enhavanta metadatenojn de ĉiu enhavo, informojn pri kiaj filmoj estis haveblaj, kiuj kreis la kapablon generi rigardlistojn. Ĝi havis senmarkan REST API bazitan sur la JSON-skemo, HTTP-Responkodo, la sama uzata en moderna arkitekturo, kaj OAuth-sekureca modelo, kio estis postulata tiutempe por antaŭa aplikaĵo. Ĉi tio ebligis transiri de publika modelo de transflua enhavo livero al privata.
La problemo kun la transiro estis fragmentiĝo, ĉar nun nia sistemo funkciigis du servojn bazitajn sur tute malsamaj principoj de operacio - unu sur Rest, JSON kaj OAuth, la alia sur RPC, XML kaj uzanta sekureca mekanismo bazita sur la NTBA-ĵeton-sistemo. Tio estis la unua hibrida arkitekturo.
Ekzistis esence fajroŝirmilo inter niaj du teamoj ĉar komence la API ne tre bone skalis kun NCCP kaj ĉi tio kondukis al frotado inter la teamoj. La diferencoj estis en servoj, protokoloj, cirkvitoj, sekurecaj moduloj, kaj programistoj ofte devis ŝanĝi inter tute malsamaj kuntekstoj.
Ĉi-rilate mi interparolis kun unu el la altrangaj inĝenieroj de la firmao, al kiu mi demandis la demandon: "Kio devus esti la ĝusta longtempa arkitekturo?" kaj li faris la kontraŭdemandon: "Vi verŝajne pli zorgas. pri la organizaj sekvoj - kio okazas se ni integras tiujn aferojn, kaj ili rompas tion, kion ni lernis bone fari? Tiu aliro estas tre signifa al la Juro de Conway: "Organizaĵoj kiuj dezajnsistemoj estas limigitaj per dezajno kiu reproduktas la komunikadstrukturon de tiu organizo." Ĉi tio estas tre abstrakta difino, do mi preferas pli specifan: "Iu ajn programaro reflektas la organizan strukturon kiu kreis ĝin." Jen mia plej ŝatata citaĵo de Eric Raymond: "Se vi havas kvar teamojn de programistoj laborantaj pri kompililo, vi finiĝos kun kvar-pasa kompililo." Nu, Netflix havas kvar-pasan kompililon, kaj tiel ni funkcias.
Ni povas diri, ke ĉi-kaze la vosto svingas la hundon. Nia unua prioritato ne estas la solvo, sed la organizo; ĝi estas la organizo kiu movas la arkitekturon kiun ni havas. Iom post iom, de amaso da servoj, ni transiris al arkitekturo, kiun ni nomis Blade Runner, ĉar ĉi tie ni parolas pri randaj servoj kaj la kapablo de NCCP esti apartigita kaj integrita rekte en la prokurilon Zuul, API-enirejon kaj la respondan funkcian. "pecoj" fariĝis novaj mikroservoj kun pli altnivelaj sekureco, ripeto, datumordigo, ktp.
Tiel, oni povas diri, ke departementaj strukturoj kaj kompania dinamiko ludas gravan rolon en formado de sistema dezajno kaj estas faktoro kiu antaŭenigas aŭ malhelpas ŝanĝon. Mikroserva arkitekturo estas kompleksa kaj organika, kaj ĝia sano baziĝas sur disciplino kaj enkondukita kaoso.
Iom da reklamado
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com