Pinag-uusapan ni Josh Evans ang magulong at makulay na mundo ng mga microservice ng Netflix, simula sa mga pangunahing kaalaman - ang anatomy ng mga microservice, ang mga hamon na nauugnay sa mga distributed system, at ang mga benepisyo ng mga ito. Batay sa pundasyong ito, tinutuklasan niya ang kultural, arkitektura, at mga kasanayan sa pagpapatakbo na humahantong sa microservice mastery.
Hindi tulad ng operational drift, ang pagpapakilala ng mga bagong wika para sa internasyunalisasyon ng serbisyo at mga bagong teknolohiya tulad ng mga lalagyan ay malay na mga desisyon upang magdagdag ng bagong kumplikado sa kapaligiran. Ang aking operations team ay nag-standardize sa pinakamahusay na roadmap ng teknolohiya para sa Netflix, na ginawa sa mga paunang natukoy na pinakamahuhusay na kagawian batay sa Java at EC2, ngunit habang lumalago ang negosyo, nagsimula ang mga developer na magdagdag ng mga bagong bahagi tulad ng Python, Ruby, Node-JS, at Docker.
Lubos akong ipinagmamalaki na kami ang unang nagtaguyod para sa aming produkto na gumana nang mahusay nang hindi naghihintay ng mga reklamo ng customer. Nagsimula ang lahat sa sapat na simple - mayroon kaming mga operating program sa Python at ilang back-office application sa Ruby, ngunit mas naging interesante ang mga bagay nang ipahayag ng aming mga web developer na tatanggalin na nila ang JVM at ililipat ang web. application sa platform ng software ng Node.js. Matapos ang pagpapakilala ng Docker, ang mga bagay ay naging mas kumplikado. Sinunod namin ang lohika at ang mga teknolohiyang aming naisip ay naging realidad nang ipatupad namin ang mga ito para sa mga customer dahil malaki ang kahulugan ng mga ito. Sasabihin ko sa iyo kung bakit ganito.
Ang API Gateway ay talagang may kakayahang magsama ng magagandang script na maaaring kumilos bilang mga endpoint para sa mga developer ng UI. Na-convert nila ang bawat isa sa mga script na ito sa paraang pagkatapos gumawa ng mga pagbabago maaari nilang i-deploy ang mga ito sa produksyon at pagkatapos ay sa mga device ng user, at ang lahat ng pagbabagong ito ay naka-synchronize sa mga endpoint na tumatakbo sa API gateway.
Gayunpaman, inulit nito ang problema sa paglikha ng isang bagong monolith kung saan ang serbisyo ng API ay na-overload ng code sa paraang naganap ang iba't ibang mga senaryo ng pagkabigo. Halimbawa, inalis ang ilang endpoint, o random na nakabuo ang mga script ng napakaraming bersyon ng isang bagay na kinuha ng mga bersyon ang lahat ng available na memory ng serbisyo ng API.
Lohikal na kunin ang mga endpoint na ito at alisin ang mga ito sa serbisyo ng API. Para magawa ito, gumawa kami ng mga bahagi ng Node.js na tumatakbo bilang maliliit na application sa mga container ng Docker. Nagpahintulot ito sa amin na ihiwalay ang anumang mga problema at pag-crash na dulot ng mga application na ito ng node.
Ang halaga ng mga pagbabagong ito ay medyo malaki at binubuo ng mga sumusunod na salik:
- Mga tool sa pagiging produktibo. Ang pamamahala ng mga bagong teknolohiya ay nangangailangan ng mga bagong tool dahil ang UI team, na gumagamit ng napakahusay na mga script upang lumikha ng isang mahusay na modelo, ay hindi kailangang gumastos ng maraming oras sa pamamahala ng imprastraktura, kailangan lang nilang magsulat ng mga script at suriin ang kanilang pag-andar.
Insight at Pag-uuri ng Pagkakataon - Ang isang pangunahing halimbawa ay ang mga bagong tool na kailangan upang matuklasan ang impormasyon ng driver ng pagganap. Ito ay kinakailangan upang malaman kung gaano karaming ang processor ay inookupahan, kung paano memory ay ginagamit, at pagkolekta ng impormasyon na ito ay nangangailangan ng iba't ibang mga tool. - Fragmentation ng mga batayang larawan - ang simpleng base AMI ay naging mas pira-piraso at dalubhasa.
- Pamamahala ng node. Walang available na arkitektura o teknolohiya sa labas na nagbibigay-daan sa iyong pamahalaan ang mga node sa cloud, kaya binuo namin ang Titus, isang platform ng pamamahala ng container na nagbibigay ng scalable at maaasahang pag-deploy ng container at pagsasama ng cloud sa Amazon AWS.
- Pagdoble ng isang library o platform. Ang pagbibigay ng mga bagong teknolohiya na may parehong pangunahing functionality ng platform ay nangangailangan ng pag-duplicate nito sa cloud-based na mga tool ng developer ng Node.js.
- Learning curve at karanasan sa industriya. Ang pagpapakilala ng mga bagong teknolohiya ay hindi maiiwasang lumikha ng mga bagong hamon na dapat malampasan at matutunan.
Kaya, hindi namin maaaring limitahan ang aming sarili sa isang "sementadong kalsada" at kailangang patuloy na bumuo ng mga bagong paraan upang isulong ang aming mga teknolohiya. Para mapababa ang mga gastos, nilimitahan namin ang sentralisadong suporta at nakatutok sa JVM, mga bagong node, at Docker. Inuna namin ang epektibong epekto, ipinaalam sa mga team ang tungkol sa halaga ng kanilang mga desisyon, at hinikayat namin silang maghanap ng mga paraan upang muling magamit ang mga solusyon na may mataas na epekto na nagawa na nila. Ginamit namin ang diskarteng ito kapag nagsasalin ng serbisyo sa mga wikang banyaga upang maihatid ang produkto sa mga internasyonal na kliyente. Kasama sa mga halimbawa ang medyo simpleng mga library ng kliyente na maaaring awtomatikong mabuo, upang medyo madaling gumawa ng bersyon ng Python, bersyon ng Ruby, bersyon ng Java, atbp.
Patuloy kaming naghahanap ng mga pagkakataon na gumamit ng mga napatunayang teknolohiya na napatunayan ang kanilang mga sarili sa isang lugar at sa iba pang katulad na mga sitwasyon.
Pag-usapan natin ang huling elemento - mga pagbabago, o mga pagkakaiba-iba. Tingnan kung paano hindi pantay ang pagkonsumo ng aming produkto ayon sa araw ng linggo at oras sa buong araw. Maaari mong sabihin na 9 a.m. ang pinakamahirap na oras para sa Netflix, kapag ang load sa system ay umabot sa maximum nito.
Paano natin makakamit ang mataas na bilis ng pagpapatupad ng mga inobasyon ng software, iyon ay, patuloy na gumagawa ng mga bagong pagbabago sa system, nang hindi nagdudulot ng mga pagkaantala sa paghahatid ng serbisyo at nang hindi lumilikha ng abala sa ating mga customer? Nakamit ito ng Netflix sa pamamagitan ng paggamit ng Spinnaker, isang bagong pandaigdigang cloud-based na pamamahala at tuluy-tuloy na paghahatid (CD) platform.
Sa kritikal na paraan, ang Spinnaker ay idinisenyo upang isama ang aming pinakamahuhusay na kagawian nang sa gayon habang nagde-deploy kami ng mga bahagi sa produksyon, maaari naming isama ang output nang direkta sa aming teknolohiya sa paghahatid ng media.
Nagawa naming isama ang dalawang teknolohiya sa aming pipeline ng paghahatid na lubos naming pinahahalagahan: awtomatikong pagsusuri ng canary at nakaplanong pag-deploy. Nangangahulugan ang pagsusuri ng Canary na nagdidirekta kami ng patak ng trapiko sa bagong bersyon ng code, at ipinapasa namin ang natitirang trapiko sa produksyon sa lumang bersyon. Pagkatapos ay sinusuri namin kung paano nakayanan ng bagong code ang gawain - mas mabuti o mas masahol pa kaysa sa umiiral na.
Nangangahulugan ang staggered rollout na kung ang isang rollout sa isang rehiyon ay may mga problema, lilipat kami sa isang rollout sa ibang rehiyon. Sa kasong ito, ang nabanggit na checklist ay dapat na kasama sa pipeline ng produksyon. Makakatipid ako sa iyo ng ilang oras at irerekomenda na tingnan mo ang aking nakaraang usapan, Engineering Global Netflix Operations in the Cloud, kung interesado kang sumisid nang mas malalim sa paksang ito. Maaaring matingnan ang video recording ng talumpati sa pamamagitan ng pagsunod sa link sa ibaba ng slide.
Sa pagtatapos ng pag-uusap, maikling pag-uusapan ko ang tungkol sa organisasyon at arkitektura ng Netflix. Sa simula pa lang, mayroon kaming scheme na tinatawag na Electronic Delivery, na siyang unang bersyon ng NRDP 1.x media streaming. Ang terminong "backstream" ay maaaring gamitin dito dahil sa simula ay maaari lang mag-download ng nilalaman ang user para sa pag-playback sa device sa ibang pagkakataon. Ang pinakaunang digital delivery platform ng Netflix, noong 2009, ay ganito ang hitsura.
Ang device ng user ay naglalaman ng Netflix application, na binubuo ng isang interface ng UI, mga module ng seguridad, pag-activate ng serbisyo at pag-playback, batay sa NRDP platform - Netflix Ready Device Platform.
Sa oras na iyon ang interface ng gumagamit ay napaka-simple. Naglalaman ito ng tinatawag na Queque Reader, at pupunta ang user sa site upang magdagdag ng isang bagay sa Queque at pagkatapos ay tingnan ang idinagdag na nilalaman sa kanilang device. Ang positibo ay ang front end team at ang back end team ay kabilang sa parehong Electronic Delivery na organisasyon at nagkaroon ng malapit na relasyon sa pagtatrabaho. Ang payload ay nilikha batay sa XML. Kasabay nito, nilikha ang Netflix API para sa negosyo ng DVD, na naghikayat sa mga third-party na application na idirekta ang trapiko sa aming serbisyo.
Gayunpaman, ang Netflix API ay mahusay na inihanda upang tulungan kami sa isang makabagong user interface, na naglalaman ng metadata ng lahat ng nilalaman, impormasyon tungkol sa kung anong mga pelikula ang magagamit, na lumikha ng kakayahang bumuo ng mga listahan ng panonood. Mayroon itong generic na REST API batay sa JSON schema, HTTP Response Code, ang parehong ginamit sa modernong arkitektura, at isang modelo ng seguridad ng OAuth, na kung ano ang kinakailangan sa oras para sa isang front-end na application. Ginawa nitong posible na lumipat mula sa isang pampublikong modelo ng streaming na paghahatid ng nilalaman patungo sa isang pribado.
Ang problema sa paglipat ay fragmentation, dahil ngayon ang aming system ay nagpapatakbo ng dalawang serbisyo batay sa ganap na magkaibang mga prinsipyo ng pagpapatakbo - isa sa Rest, JSON at OAuth, ang isa sa RPC, XML at isang mekanismo ng seguridad ng user batay sa NTBA token system. Ito ang unang hybrid na arkitektura.
Sa esensya, nagkaroon ng firewall sa pagitan ng aming dalawang team dahil sa una ay hindi masyadong na-scale ang API sa NCCP at humantong ito sa alitan sa pagitan ng mga team. Ang mga pagkakaiba ay sa mga serbisyo, protocol, circuit, module ng seguridad, at madalas na kailangang lumipat ng mga developer sa pagitan ng ganap na magkakaibang konteksto.
Kaugnay nito, nakipag-usap ako sa isa sa mga senior engineer ng kumpanya, kung saan tinanong ko ang tanong: "Ano ang dapat na tamang pang-matagalang arkitektura?" at tinanong niya ang sagot na tanong: "Marahil ay mas nababahala ka. tungkol sa mga kahihinatnan ng organisasyon - ano ang mangyayari kung isasama natin ang mga bagay na ito, at sinira ng mga ito ang natutunan nating gawin nang maayos? Napakahalaga ng diskarteng ito sa Batas ng Conway: "Ang mga organisasyong nagdidisenyo ng mga sistema ay pinipigilan ng isang disenyo na ginagaya ang istruktura ng komunikasyon ng organisasyong iyon." Ito ay isang napaka-abstract na kahulugan, kaya mas gusto ko ang isang mas tiyak: "Ang anumang piraso ng software ay sumasalamin sa istruktura ng organisasyon na lumikha nito." Narito ang aking paboritong quote mula kay Eric Raymond: "Kung mayroon kang apat na koponan ng mga developer na nagtatrabaho sa isang compiler, magkakaroon ka ng isang four-pass compiler." Well, ang Netflix ay may isang four-pass compiler, at ganyan kami nagtatrabaho.
Masasabi natin na sa kasong ito ang buntot ay kumakawag sa aso. Ang aming unang priyoridad ay hindi ang solusyon, ngunit ang organisasyon; ito ay ang organisasyon na nagtutulak sa arkitektura na mayroon kami. Unti-unti, mula sa isang hodgepodge ng mga serbisyo, lumipat kami sa isang arkitektura na tinawag naming Blade Runner, dahil dito pinag-uusapan natin ang tungkol sa mga serbisyo sa gilid at ang kakayahan ng NCCP na paghiwalayin at isama nang direkta sa Zuul proxy, API gateway, at ang kaukulang functionality. Ang "mga piraso" ay ginawang mga bagong microservice na may mas advanced na seguridad, replay, pag-uuri ng data, atbp. na mga feature.
Kaya, masasabing ang mga istruktura ng departamento at dinamika ng kumpanya ay may mahalagang papel sa paghubog ng disenyo ng system at isang salik na nagsusulong o humahadlang sa pagbabago. Ang arkitektura ng Microservices ay kumplikado at organiko, at ang kalusugan nito ay nakabatay sa disiplina at ipinakilalang kaguluhan.
Isang maliit na advertising
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com