QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

DžoÅ”s Evanss stāsta par haotisko un krāsaino Netflix mikropakalpojumu pasauli, sākot ar paÅ”iem pamatiem ā€“ mikropakalpojumu anatomiju, izaicinājumiem, kas saistÄ«ti ar sadalÄ«tajām sistēmām, un to priekÅ”rocÄ«bām. Balstoties uz Å”o pamatu, viņŔ pēta kultÅ«ras, arhitektÅ«ras un darbÄ«bas praksi, kas noved pie mikropakalpojumu meistarÄ«bas.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 1. daļa
QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 2. daļa
QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 3. daļa

AtŔķirÄ«bā no darbÄ«bas novirzes, jaunu valodu ievieÅ”ana pakalpojumu internacionalizācijai un jaunas tehnoloÄ£ijas, piemēram, konteineri, ir apzināti lēmumi, lai padarÄ«tu vidi sarežģītāku. Mana operāciju komanda standartizēja Netflix labāko tehnoloÄ£iju ceļvedi, kas tika iekļauta iepriekÅ” definētās paraugpraksēs, kuru pamatā ir Java un EC2, taču, biznesam augot, izstrādātāji sāka pievienot jaunus komponentus, piemēram, Python, Ruby, Node-JS un Docker.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

Esmu ļoti lepns, ka bijām pirmie, kas iestājās par to, lai mÅ«su produkts darbotos lieliski, negaidot klientu sÅ«dzÄ«bas. Viss sākās pietiekami vienkārÅ”i ā€” mums bija darbÄ«bas programmas Python un dažas back-office lietojumprogrammas Ruby, taču lietas kļuva daudz interesantākas, kad mÅ«su tÄ«mekļa izstrādātāji paziņoja, ka viņi gatavojas atteikties no JVM un pārvietot tÄ«mekli. lietojumprogramma Node programmatÅ«ras platformai.js. Pēc Docker ievieÅ”anas lietas kļuva daudz sarežģītākas. Mēs sekojām loÄ£ikai, un mÅ«su izstrādātās tehnoloÄ£ijas kļuva par realitāti, kad tās ieviesām klientiem, jo ā€‹ā€‹tām bija liela jēga. Es jums pastāstÄ«Å”u, kāpēc tas tā ir.

API vārtejai faktiski ir iespēja integrēt lieliskus skriptus, kas var darboties kā lietotāja saskarnes izstrādātāju galapunkti. Viņi pārveidoja katru no Å”iem skriptiem tā, lai pēc izmaiņu veikÅ”anas tos varētu izvietot ražoÅ”anas un pēc tam lietotāju ierÄ«cēs, un visas Ŕīs izmaiņas tika sinhronizētas ar galapunktiem, kas darbojās API vārtejā.

Tomēr tas atkārtoja jaunu monolÄ«ta izveidoÅ”anas problēmu, kur API pakalpojums tika pārslogots ar kodu tā, ka radās dažādi kļūmju scenāriji. Piemēram, daži galapunkti tika noņemti vai skripti nejauÅ”i Ä£enerēja tik daudz kaut kā versiju, ka versijas aizņēma visu pieejamo API pakalpojuma atmiņu.

Bija loÄ£iski ņemt Å”os galapunktus un izņemt tos no API pakalpojuma. Lai to izdarÄ«tu, mēs izveidojām Node.js komponentus, kas darbojās kā mazas lietojumprogrammas Docker konteineros. Tas ļāva mums izolēt visas problēmas un avārijas, ko izraisÄ«ja Ŕīs mezgla lietojumprogrammas.

Å o izmaiņu izmaksas ir diezgan lielas un sastāv no Ŕādiem faktoriem:

  • Produktivitātes instrumenti. Lai pārvaldÄ«tu jaunas tehnoloÄ£ijas, bija nepiecieÅ”ami jauni rÄ«ki, jo lietotāja saskarnes komandai, izmantojot ļoti labus skriptus efektÄ«va modeļa izveidei, nebija jātērē daudz laika infrastruktÅ«ras pārvaldÄ«Å”anai, bija tikai jāraksta skripti un jāpārbauda to funkcionalitāte.
    Iespēju ieskats un ŔķiroÅ”ana ā€” galvenais piemērs ir jauni rÄ«ki, kas nepiecieÅ”ami, lai atklātu informāciju par veiktspējas draiveriem. Bija jāzina, cik daudz procesora ir aizņemts, kā tiek izmantota atmiņa, un Ŕīs informācijas apkopoÅ”anai bija nepiecieÅ”ami dažādi rÄ«ki.
  • Bāzes attēlu sadrumstalotÄ«ba - vienkārÅ”ais bāzes AMI ir kļuvis sadrumstalotāks un specializētāks.
  • Mezglu pārvaldÄ«ba. Nav pieejama gatavā arhitektÅ«ra vai tehnoloÄ£ija, kas ļautu pārvaldÄ«t mezglus mākonÄ«, tāpēc mēs izveidojām Titus ā€” konteineru pārvaldÄ«bas platformu, kas nodroÅ”ina mērogojamu un uzticamu konteineru izvietoÅ”anu un mākoņa integrāciju ar Amazon AWS.
  • Bibliotēkas vai platformas dublÄ“Å”ana. Lai nodroÅ”inātu jaunas tehnoloÄ£ijas ar tādu paÅ”u platformas pamatfunkcionalitāti, bija nepiecieÅ”ama tā dublÄ“Å”ana mākoņa bāzes Node.js izstrādātāju rÄ«kos.
  • MācÄ«bu lÄ«kne un industriālā pieredze. Jaunu tehnoloÄ£iju ievieÅ”ana neizbēgami rada jaunus izaicinājumus, kas ir jāpārvar un no kuriem jāmācās.

Tādējādi mēs nevarējām aprobežoties ar vienu ā€œbruģētu ceļuā€, un mums bija pastāvÄ«gi jāveido jauni veidi, kā uzlabot mÅ«su tehnoloÄ£ijas. Lai samazinātu izmaksas, mēs ierobežojām centralizēto atbalstu un koncentrējāmies uz JVM, jauniem mezgliem un Docker. Mēs izvirzÄ«jām prioritāti efektÄ«vai ietekmei, informējām komandas par viņu lēmumu izmaksām un mudinājām tās meklēt veidus, kā atkārtoti izmantot jau izstrādātos augstas ietekmes risinājumus. Mēs izmantojām Å”o pieeju, tulkojot pakalpojumu sveÅ”valodās, lai piegādātu produktu starptautiskiem klientiem. Kā piemērus var minēt salÄ«dzinoÅ”i vienkārÅ”as klientu bibliotēkas, kuras var Ä£enerēt automātiski, tāpēc ir diezgan viegli izveidot Python versiju, Ruby versiju, Java versiju utt.

NemitÄ«gi meklējām iespējas izmantot pārbaudÄ«tas tehnoloÄ£ijas, kas sevi pierādÄ«juÅ”as vienuviet un citās lÄ«dzÄ«gās situācijās.

Parunāsim par pēdējo elementu ā€“ izmaiņām, jeb variācijām. Paskatieties, kā mÅ«su produkta patēriņŔ mainās nevienmērÄ«gi pa nedēļas dienām un pa stundām visas dienas garumā. Varētu teikt, ka 9:XNUMX ir grÅ«tākais laiks Netflix, kad sistēmas slodze sasniedz maksimumu.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

Kā panākt lielu programmatÅ«ras inovāciju ievieÅ”anas ātrumu, tas ir, pastāvÄ«gi veikt jaunas izmaiņas sistēmā, neradot pārtraukumus pakalpojumu sniegÅ”anā un neradot neērtÄ«bas mÅ«su klientiem? Netflix to sasniedza, izmantojot Spinnaker ā€” jaunu globālu mākoņdatoÅ”anas pārvaldÄ«bas un nepārtrauktas piegādes (CD) platformu.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

BÅ«tiski, ka Spinnaker tika izstrādāts, lai integrētu mÅ«su labāko praksi, lai, izvietojot komponentus ražoÅ”anā, mēs varētu integrēt izvadi tieÅ”i mÅ«su multivides piegādes tehnoloÄ£ijā.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

Mēs esam spējuÅ”i iekļaut mÅ«su piegādes cauruļvadā divas tehnoloÄ£ijas, kuras mēs augstu vērtējam: automatizēto kanāriju analÄ«zi un pakāpenisku izvietoÅ”anu. Kanāriju analÄ«ze nozÄ«mē, ka mēs novirzām datplÅ«smu uz jauno koda versiju, bet pārējo produkcijas datplÅ«smu nododam vecajai versijai. Pēc tam pārbaudām, kā jaunais kods tiek galā ar uzdevumu ā€“ labāk vai sliktāk par esoÅ”o.

Pakāpeniska izlaiÅ”ana nozÄ«mē, ka, ja izlaiÅ”anai vienā reÄ£ionā rodas problēmas, mēs pārietam uz izlaiÅ”anu citā reÄ£ionā. Å ajā gadÄ«jumā iepriekÅ” minētais kontrolsaraksts ir jāiekļauj ražoÅ”anas konveijerā. Es ietaupÄ«Å”u jums kādu laiku un iesaku izlasÄ«t manu iepriekŔējo runu ā€œInženierijas globālās Netflix operācijas mākonÄ«ā€, ja vēlaties ienirt Å”ajā tēmā. Runas videoierakstu var noskatÄ«ties, sekojot saitei slaida apakŔā.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

Sarunas noslēgumā es Ä«si pastāstÄ«Å”u par Netflix organizāciju un arhitektÅ«ru. PaŔā sākumā mums bija shēma ar nosaukumu Electronic Delivery, kas bija pirmā NRAP 1.x mediju straumÄ“Å”anas versija. Å eit var izmantot terminu "backstream", jo sākotnēji lietotājs varēja lejupielādēt saturu tikai vēlākai atskaņoÅ”anai ierÄ«cē. Netflix pati pirmā digitālās piegādes platforma 2009. gadā izskatÄ«jās apmēram Ŕādi.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

Lietotāja ierÄ«cē bija Netflix aplikācija, kas sastāvēja no UI interfeisa, droŔības moduļiem, servisa aktivizÄ“Å”anas un atskaņoÅ”anas, pamatojoties uz NRDP platformu ā€“ Netflix Ready Device Platform.

Tolaik lietotāja interfeiss bija ļoti vienkārÅ”s. Tajā bija tā sauktais Queque Reader, un lietotājs apmeklēja vietni, lai kaut ko pievienotu Queque un pēc tam skatÄ«tu pievienoto saturu savā ierÄ«cē. PozitÄ«vi bija tas, ka priekÅ”gala komanda un aizmugures komanda piederēja vienai elektroniskās piegādes organizācijai un tām bija cieÅ”as darba attiecÄ«bas. Krava tika izveidota, pamatojoties uz XML. Tajā paŔā laikā tika izveidota Netflix API DVD biznesam, kas mudināja treÅ”o puÅ”u lietojumprogrammas novirzÄ«t trafiku uz mÅ«su pakalpojumu.

Tomēr Netflix API bija labi sagatavota, lai palÄ«dzētu mums ar novatorisku lietotāja interfeisu, kas satur visa satura metadatus, informāciju par pieejamām filmām, kas radÄ«ja iespēju Ä£enerēt skatÄ«Å”anās sarakstus. Tam bija vispārÄ«ga REST API, kuras pamatā bija JSON shēma, HTTP atbildes kods, tas pats, kas tiek izmantots mÅ«sdienu arhitektÅ«rā, un OAuth droŔības modelis, kas tajā laikā bija nepiecieÅ”ams priekÅ”gala lietojumprogrammai. Tas ļāva pāriet no publiska straumÄ“Å”anas satura piegādes modeļa uz privātu.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

Pārejas problēma bija sadrumstalotÄ«ba, jo tagad mÅ«su sistēma darbojās uz diviem pakalpojumiem, kas balstÄ«ti uz pilnÄ«gi atŔķirÄ«giem darbÄ«bas principiem - viens uz Rest, JSON un OAuth, otrs uz RPC, XML un lietotāja droŔības mehānisms, kas balstÄ«ts uz NTBA marÄ·iera sistēmu. Å Ä« bija pirmā hibrÄ«da arhitektÅ«ra.

BÅ«tÄ«bā starp mÅ«su abām komandām bija ugunsmÅ«ris, jo sākotnēji API nedarbojās ļoti labi ar NCCP, un tas izraisÄ«ja berzi starp komandām. AtŔķirÄ«bas bija pakalpojumos, protokolos, shēmās, droŔības moduļos, un izstrādātājiem bieži bija jāpārslēdzas starp pilnÄ«gi atŔķirÄ«giem kontekstiem.

QCon konference. Haosa apgūŔana: Netflix ceļvedis mikropakalpojumiem. 4. daļa

Å ajā sakarā man bija saruna ar vienu no uzņēmuma vecākajiem inženieriem, kuram uzdevu jautājumu: ā€œKādai vajadzētu bÅ«t pareizai ilgtermiņa arhitektÅ«rai?ā€, un viņŔ uzdeva pretjautājumu: ā€œJÅ«s droÅ”i vien esat vairāk nobažījies. par organizatoriskajām sekām ā€“ kas notiek, ja Ŕīs lietas integrējam, un tās sagrauj to, ko esam iemācÄ«juÅ”ies darÄ«t labi? Å Ä« pieeja ir ļoti bÅ«tiska Konveja likumam: "Organizācijas, kuras projektē sistēmas, ierobežo dizains, kas atkārto Ŕīs organizācijas komunikācijas struktÅ«ru." Å Ä« ir ļoti abstrakta definÄ«cija, tāpēc es dodu priekÅ”roku konkrētākai definÄ«cijai: ā€œJebkura programmatÅ«ras daļa atspoguļo organizatorisko struktÅ«ru, kas to radÄ«ja.ā€ Å eit ir mans iecienÄ«tākais citāts no Ērika Raimonda: "Ja jums ir četras izstrādātāju komandas, kas strādā pie kompilatora, jÅ«s iegÅ«sit četru pakāpju kompilatoru." Nu, Netflix ir četru pakāpju kompilators, un tā mēs strādājam.

Var teikt, ka Å”ajā gadÄ«jumā aste luncina suni. MÅ«su pirmā prioritāte nav risinājums, bet gan organizācija; tā ir organizācija, kas virza mÅ«su arhitektÅ«ru. Pakāpeniski no pakalpojumu klāsta mēs pārgājām uz arhitektÅ«ru, ko saucām par Blade Runner, jo Å”eit mēs runājam par malas pakalpojumiem un NCCP spēju atdalÄ«t un integrēt tieÅ”i Zuul starpniekserverÄ«, API vārtejā un atbilstoÅ”ajā funkcionālajā. ā€œgabaliā€ ir pārvērsti jaunos mikropakalpojumos ar uzlabotām droŔības, atskaņoÅ”anas, datu ŔķiroÅ”anas u.c. funkcijām.

Tādējādi var teikt, ka departamentu struktÅ«rām un uzņēmuma dinamikai ir liela nozÄ«me sistēmas dizaina veidoÅ”anā un tie ir faktors, kas veicina vai kavē izmaiņas. Mikropakalpojumu arhitektÅ«ra ir sarežģīta un organiska, un tās veselÄ«ba ir balstÄ«ta uz disciplÄ«nu un ieviesto haosu.

Kaut kāda reklāma

Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, mākoņa VPS izstrādātājiem no 4.99 USD, unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: Visa patiesība par VPS (KVM) E5-2697 v3 (6 kodoli) 10GB DDR4 480GB SSD 1Gbps no 19$ vai kā koplietot serveri? (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).

Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai Å”eit 2x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV no 199$ NÄ«derlandē! Dell R420 ā€” 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB ā€” no 99 USD! LasÄ«t par Kā izveidot infrastruktÅ«ras uzņēmumu klase ar Dell R730xd E5-2650 v4 serveru izmantoÅ”anu 9000 eiro par santÄ«mu?

Avots: www.habr.com

Pievieno komentāru