Josh Evans räägib Netflixi mikroteenuste kaootilisest ja värvikast maailmast, alustades päris põhitõdedest – mikroteenuste anatoomiast, hajutatud süsteemidega kaasnevatest väljakutsetest ja nende eelistest. Sellele alusele tuginedes uurib ta kultuurilisi, arhitektuurilisi ja tegevustavasid, mis viivad mikroteenuste meisterlikkuseni.
Erinevalt operatiivsest triivist on uute keelte kasutuselevõtt teenuste rahvusvahelistumiseks ja uued tehnoloogiad, nagu konteinerid, teadlikud otsused, mis muudavad keskkonda keerukamaks. Minu operatiivmeeskond standardiseeris Netflixi parima tehnoloogia tegevuskava, mis põhines Java-l ja EC2-l eelnevalt määratletud parimateks tavadeks, kuid äri kasvades hakkasid arendajad lisama uusi komponente, nagu Python, Ruby, Node-JS ja Docker.
Olen väga uhke, et olime esimesed, kes propageerisid, et meie toode töötaks suurepäraselt ilma klientide kaebusi ootamata. Algas kõik piisavalt lihtsalt – meil olid Pythonis tööprogrammid ja Rubys mõned back-office’i rakendused, kuid asjad läksid palju huvitavamaks, kui meie veebiarendajad teatasid, et nad loobuvad JVM-ist ja hakkavad veebi teisaldama. rakendus Node tarkvaraplatvormile.js. Pärast Dockeri kasutuselevõttu muutusid asjad palju keerulisemaks. Järgisime loogikat ja väljamõeldud tehnoloogiad said reaalsuseks, kui me need klientide jaoks kasutusele võtsime, sest neil oli palju mõtet. Ma ütlen teile, miks see nii on.
API Gatewayl on tegelikult võimalus integreerida suurepäraseid skripte, mis võivad toimida kasutajaliidese arendajate lõpp-punktidena. Nad teisendasid kõik need skriptid nii, et pärast muudatuste tegemist said nad need tootmis- ja seejärel kasutajaseadmetesse juurutada ning kõik need muudatused sünkrooniti API lüüsis töötavate lõpp-punktidega.
See aga kordas probleemi uue monoliidi loomisel, kus API teenus oli koodiga üle koormatud nii, et tekkisid erinevad tõrkestsenaariumid. Näiteks eemaldati mõned lõpp-punktid või skriptid genereerisid juhuslikult millestki nii palju versioone, et versioonid võtsid kogu API-teenuse vaba mälu.
Loogiline oli need lõpp-punktid võtta ja API-teenusest välja tõmmata. Selleks lõime Node.js komponendid, mis jooksid väikeste rakendustena Dockeri konteinerites. See võimaldas meil eraldada nende sõlmerakenduste põhjustatud probleemid ja krahhid.
Nende muudatuste maksumus on üsna suur ja koosneb järgmistest teguritest:
- Tootlikkuse tööriistad. Uute tehnoloogiate haldamine nõudis uusi tööriistu, sest kasutajaliidese meeskond, kes kasutas tõhusa mudeli loomiseks väga häid skripte, ei pidanud palju aega kulutama infrastruktuuri haldamisele, tuli vaid kirjutada skripte ja kontrollida nende funktsionaalsust.
Võimaluste ülevaade ja sortimine – peamine näide on uued tööriistad, mis on vajalikud jõudluse draiveriteabe leidmiseks. Oli vaja teada, kui palju protsessor on hõivatud, kuidas mälu kasutatakse ja selle teabe kogumine nõudis erinevaid tööriistu. - Põhipiltide killustumine – lihtne baas-AMI on muutunud killustatumaks ja spetsialiseeritumaks.
- Sõlmehaldus. Saadaval pole valmisarhitektuuri ega tehnoloogiat, mis võimaldaks hallata pilvesõlmi, seetõttu ehitasime Tituse, konteinerihaldusplatvormi, mis pakub skaleeritavat ja usaldusväärset konteinerite juurutamist ja pilve integreerimist Amazon AWS-iga.
- Teegi või platvormi dubleerimine. Uute tehnoloogiate pakkumine platvormi samade põhifunktsioonidega nõudis selle dubleerimist pilvepõhistesse Node.js arendajatööriistadesse.
- Õppimiskõver ja tööstuskogemus. Uute tehnoloogiate kasutuselevõtt tekitab paratamatult uusi väljakutseid, millest tuleb üle saada ja millest tuleb õppida.
Seega ei saanud me piirduda ühe „sillutisega teega“ ja pidime pidevalt ehitama uusi võimalusi oma tehnoloogiate edendamiseks. Kulude vähendamiseks piirasime tsentraliseeritud tuge ja keskendusime JVM-ile, uutele sõlmedele ja Dockerile. Seasime prioriteediks tõhusa mõju, teavitasime meeskondi nende otsuste maksumusest ja julgustasime neid otsima võimalusi juba välja töötatud suure mõjuga lahenduste taaskasutamiseks. Kasutasime seda lähenemist teenuse tõlkimisel võõrkeeltesse, et tarnida toodet rahvusvahelistele klientidele. Näited hõlmavad suhteliselt lihtsaid klienditeeke, mida saab automaatselt genereerida, nii et Pythoni versiooni, Ruby versiooni, Java versiooni jne loomine on üsna lihtne.
Otsisime pidevalt võimalusi kasutada end tõestanud tehnoloogiaid, mis on end tõestanud ühes kohas ja teistes sarnastes olukordades.
Räägime viimasest elemendist – muudatustest ehk variatsioonidest. Vaadake, kuidas meie toote tarbimine erineb ebaühtlaselt nädalapäevade ja tundide lõikes kogu päeva jooksul. Võib öelda, et kell 9 on Netflixi jaoks kõige raskem aeg, mil süsteemi koormus saavutab maksimumi.
Kuidas saavutada tarkvarauuenduste kiire juurutamine ehk pidev süsteemis uute muudatuste tegemine, ilma et tekiks katkestusi teenuse osutamisel ja tekitamata klientidele ebamugavusi? Netflix saavutas selle uue globaalse pilvepõhise halduse ja pideva edastamise (CD) platvormi Spinnaker abil.
Spinnaker loodi meie parimate tavade integreerimiseks nii, et komponentide tootmisse juurutamisel saaksime integreerida väljundi otse oma meediumiedastustehnoloogiasse.
Oleme suutnud oma tarnetorusse lisada kaks tehnoloogiat, mida hindame kõrgelt: automatiseeritud kanaari analüüs ja etapiviisiline juurutamine. Canary analüüs tähendab, et suuname liikluse nire koodi uuele versioonile ja edastame ülejäänud tootmisliikluse vana versiooni kaudu. Seejärel kontrollime, kuidas uus kood ülesandega hakkama saab – paremini või halvemini kui olemasolev.
Järkjärguline levitamine tähendab, et kui ühes piirkonnas levitamisega on probleeme, liigume üle levitamisele teises piirkonnas. Sel juhul peab ülalnimetatud kontrollnimekiri olema tootmisprotsessis. Säästan teie aega ja soovitan teil vaadata minu eelmist kõnet, Global Netflix Operations in the Cloud, kui olete huvitatud sellesse teemasse süvenemisest. Kõne videosalvestust saab vaadata slaidi allosas oleva lingi järgi.
Kõne lõpus räägin lühidalt Netflixi organisatsioonist ja arhitektuurist. Alguses oli meil skeem nimega Electronic Delivery, mis oli NRDP 1.x meedia voogedastuse esimene versioon. Siin võib kasutada terminit "tagasivoog", kuna algselt sai kasutaja sisu alla laadida ainult hilisemaks taasesituseks seadmes. Netflixi esimene digitaalne edastamisplatvorm nägi 2009. aastal välja umbes selline.
Kasutajaseade sisaldas NRDP platvormil põhinevat Netflixi rakendust, mis koosnes kasutajaliidesest, turvamoodulitest, teenuse aktiveerimisest ja taasesitusest – Netflix Ready Device Platform.
Sel ajal oli kasutajaliides väga lihtne. See sisaldas nn Queque Readerit ja kasutaja läks saidile, et Queque'ile midagi lisada ja seejärel vaadata lisatud sisu oma seadmes. Positiivne oli see, et esiotsa ja tagaotsa meeskond kuulusid samasse Electronic Delivery organisatsiooni ja neil oli tihe töösuhe. Kasulik koormus loodi XML-i alusel. Samal ajal loodi DVD-äri jaoks Netflixi API, mis julgustas kolmandate osapoolte rakendusi liiklust meie teenusesse suunama.
Netflixi API oli aga hästi ette valmistatud aitama meid uuendusliku kasutajaliidesega, mis sisaldas kogu sisu metaandmeid, teavet saadaolevate filmide kohta, mis lõi võimaluse luua vaatamisloendeid. Sellel oli JSON-skeemil põhinev üldine REST API, HTTP-vastuskood, sama, mida kasutatakse kaasaegses arhitektuuris, ja OAuthi turbemudel, mis oli tollal esiotsa rakenduse jaoks vajalik. See võimaldas liikuda avalikult voogesituse sisu edastamise mudelilt privaatsele mudelile.
Ülemineku probleemiks oli killustatus, kuna nüüd opereeris meie süsteem kahte täiesti erinevatel tööpõhimõtetel põhinevat teenust - üks Rest, JSON ja OAuth, teine RPC, XML ja NTBA tokensüsteemil põhinev kasutaja turvamehhanism. See oli esimene hübriidarhitektuur.
Meie kahe meeskonna vahel oli sisuliselt tulemüür, sest algselt ei sobinud API NCCP-ga kuigi hästi ja see põhjustas meeskondade vahel hõõrdumist. Erinevused olid teenustes, protokollides, vooluringides, turvamoodulites ja arendajad pidid sageli lülituma täiesti erinevate kontekstide vahel.
Sellega seoses vestlesin ühe ettevõtte vaneminseneriga, kellele esitasin küsimuse: “Milline peaks olema õige pikaajaline arhitektuur?” ja ta esitas vastuküsimuse: “Te olete ilmselt rohkem mures. korralduslike tagajärgede kohta – mis juhtub, kui integreerime need asjad ja need lõhuvad seda, mida oleme õppinud hästi tegema? See lähenemine on väga asjakohane Conway seadusele: "Organisatsioonid, mis projekteerivad süsteeme, on piiratud disainiga, mis kordab selle organisatsiooni kommunikatsioonistruktuuri." See on väga abstraktne määratlus, nii et eelistan konkreetsemat: "Iga tarkvaraosa peegeldab organisatsiooni struktuuri, mis selle lõi." Siin on minu lemmiktsitaat Eric Raymondilt: "Kui teil on neli arendajate meeskonda, kes töötavad kompilaatori kallal, saate lõpuks neljakäigulise kompilaatori." Noh, Netflixil on neljakäiguline kompilaator ja nii me töötame.
Võime öelda, et sel juhul liputab saba koera. Meie esimene prioriteet ei ole lahendus, vaid organisatsioon; see on organisatsioon, mis juhib meie olemasolevat arhitektuuri. Järk-järgult liikusime teenuste hulgast arhitektuurile, mida nimetasime Blade Runneriks, sest siin räägime servateenustest ja NCCP võimalusest eraldada ja integreerida otse Zuuli puhverserverisse, API lüüsi ja vastavasse funktsionaalsusesse. “tükkidest” on tehtud uued mikroteenused, millel on täiustatud turvalisuse, taasesituse, andmete sorteerimise jms funktsioonid.
Seega võib öelda, et osakondade struktuurid ja ettevõtte dünaamika mängivad süsteemi disaini kujundamisel olulist rolli ning on muutusi soodustavaks või takistavaks teguriks. Mikroteenuste arhitektuur on keeruline ja orgaaniline ning selle tervis põhineb distsipliinil ja sissetoodud kaosel.
Natuke reklaami
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com