Josh Evans anazungumza kuhusu ulimwengu wenye machafuko na rangi wa huduma ndogo za Netflix, akianza na mambo ya msingi sana - anatomy ya huduma ndogo, changamoto zinazohusiana na mifumo iliyosambazwa, na faida zake. Akijenga juu ya msingi huu, anachunguza mazoea ya kitamaduni, usanifu na uendeshaji ambayo husababisha umilisi wa huduma ndogo.
Tofauti na kuteleza kwa utendaji, kuanzishwa kwa lugha mpya za utaftaji wa huduma za kimataifa na teknolojia mpya kama vile vyombo ni maamuzi ya uangalifu ya kuongeza ugumu mpya kwa mazingira. Timu yangu ya uendeshaji ilisanifishwa kwenye ramani bora zaidi ya teknolojia ya Netflix, ambayo iliwekwa katika mbinu bora zilizofafanuliwa awali kulingana na Java na EC2, lakini biashara ilipokua, wasanidi walianza kuongeza vipengee vipya kama vile Python, Ruby, Node-JS na Docker.
Ninajivunia kuwa tulikuwa wa kwanza kutetea bidhaa zetu kufanya kazi vizuri bila kungoja malalamiko ya wateja. Yote ilianza rahisi vya kutosha - tulikuwa na programu za kufanya kazi huko Python na programu chache za ofisi huko Ruby, lakini mambo yalipendeza zaidi wakati watengenezaji wetu wa wavuti walipotangaza kwamba wangeondoa JVM na wangeenda kuhamisha wavuti. programu kwa jukwaa la programu ya Node. js. Baada ya kuanzishwa kwa Docker, mambo yakawa magumu zaidi. Tulifuata mantiki na teknolojia tulizokuja nazo zikawa ukweli tulipozitekeleza kwa wateja kwa sababu zilikuwa na maana kubwa. Nitakuambia kwa nini hii ni hivyo.
Lango la API kwa hakika lina uwezo wa kuunganisha hati nzuri ambazo zinaweza kufanya kazi kama viingilio kwa wasanidi wa UI. Walibadilisha kila moja ya hati hizi kwa njia ambayo baada ya kufanya mabadiliko wangeweza kuzipeleka kwa uzalishaji na kisha kwa vifaa vya watumiaji, na mabadiliko haya yote yalisawazishwa na miisho ambayo iliendeshwa kwenye lango la API.
Walakini, hii ilirudia shida ya kuunda monolith mpya ambapo huduma ya API ilijazwa na nambari kwa njia ambayo hali tofauti za kutofaulu zilitokea. Kwa mfano, baadhi ya sehemu za mwisho ziliondolewa, au hati zilizalisha matoleo mengi sana hivi kwamba matoleo yalichukua kumbukumbu yote inayopatikana ya huduma ya API.
Ilikuwa ni jambo la busara kuchukua ncha hizi na kuziondoa kwenye huduma ya API. Ili kufanya hivyo, tuliunda vipengee vya Node.js ambavyo vilitumika kama programu ndogo katika vyombo vya Docker. Hii ilituruhusu kutenga matatizo na mivurugiko yoyote inayosababishwa na programu hizi za nodi.
Gharama ya mabadiliko haya ni kubwa kabisa na ina mambo yafuatayo:
- Zana za uzalishaji. Kusimamia teknolojia mpya kulihitaji zana mpya kwa sababu timu ya UI, ikitumia hati nzuri sana kuunda muundo mzuri, haikulazimika kutumia muda mwingi kusimamia miundombinu, ilibidi tu kuandika hati na kuangalia utendakazi wao.
Maarifa ya Fursa na Upangaji - Mfano muhimu ni zana mpya zinazohitajika ili kufichua maelezo ya kiendeshaji. Ilikuwa ni lazima kujua ni kiasi gani processor ilikuwa inamilikiwa, jinsi kumbukumbu ilikuwa inatumiwa, na kukusanya taarifa hii kunahitaji zana tofauti. - Kugawanyika kwa picha za msingi - AMI ya msingi rahisi imegawanyika zaidi na maalum.
- Usimamizi wa nodi. Hakuna usanifu wa nje ya rafu au teknolojia inayopatikana inayokuruhusu kudhibiti nodi katika wingu, kwa hivyo tulitengeneza Titus, jukwaa la usimamizi wa kontena ambalo hutoa uwekaji wa kontena wa hatari na wa kutegemewa na ujumuishaji wa wingu na Amazon AWS.
- Rudufu ya maktaba au jukwaa. Kutoa teknolojia mpya zilizo na utendakazi sawa wa msingi wa jukwaa kulihitaji kuiiga katika zana za wasanidi wa Node.js za wingu.
- Curve ya kujifunza na uzoefu wa viwanda. Kuanzishwa kwa teknolojia mpya bila shaka huleta changamoto mpya ambazo lazima zishinde na kujifunza kutoka.
Kwa hivyo, hatukuweza kujiwekea kikomo kwa "barabara ya lami" na ilibidi tujenge kila wakati njia mpya za kuendeleza teknolojia zetu. Ili kupunguza gharama, tulipunguza usaidizi wa kati na kulenga JVM, nodi mpya na Docker. Tulitanguliza matokeo madhubuti, tuliarifu timu kuhusu gharama ya maamuzi yao, na tukawahimiza kutafuta njia za kutumia tena masuluhisho yenye athari ya juu ambayo tayari walikuwa wametayarisha. Tulitumia mbinu hii wakati wa kutafsiri huduma katika lugha za kigeni ili kuwasilisha bidhaa kwa wateja wa kimataifa. Mifano ni pamoja na maktaba rahisi za mteja ambazo zinaweza kuzalishwa kiotomatiki, ili iwe rahisi kuunda toleo la Python, toleo la Ruby, toleo la Java, n.k.
Tulikuwa tukitafuta kila mara fursa za kutumia teknolojia zilizothibitishwa ambazo zimejidhihirisha katika sehemu moja na katika hali zingine zinazofanana.
Hebu tuzungumze juu ya kipengele cha mwisho - mabadiliko, au tofauti. Angalia jinsi matumizi ya bidhaa zetu yanavyotofautiana kwa siku ya wiki na kwa saa siku nzima. Unaweza kusema kwamba 9 asubuhi ni wakati mgumu zaidi kwa Netflix, wakati mzigo kwenye mfumo unafikia upeo wake.
Tunawezaje kufikia kasi ya juu ya utekelezaji wa ubunifu wa programu, yaani, kufanya mabadiliko mapya kila mara kwenye mfumo, bila kusababisha usumbufu katika utoaji wa huduma na bila kuleta usumbufu kwa wateja wetu? Netflix ilifanikisha hili kupitia matumizi ya Spinnaker, jukwaa jipya la kimataifa la usimamizi na uwasilishaji unaotegemea wingu (CD).
Kimsingi, Spinnaker iliundwa kujumuisha mbinu zetu bora ili tunaposambaza vipengele katika uzalishaji, tunaweza kuunganisha matokeo moja kwa moja kwenye teknolojia yetu ya uwasilishaji wa maudhui.
Tumeweza kujumuisha teknolojia mbili kwenye bomba letu la uwasilishaji ambalo tunathamini sana: uchanganuzi wa kiotomatiki wa canary na usambazaji kwa hatua. Uchambuzi wa Canary unamaanisha kuwa tunaelekeza msururu wa trafiki kwenye toleo jipya la msimbo, na kupitisha trafiki nyingine ya uzalishaji kupitia toleo la zamani. Kisha tunaangalia jinsi msimbo mpya unakabiliana na kazi - bora au mbaya zaidi kuliko iliyopo.
Utoaji kwa hatua kwa hatua unamaanisha kuwa ikiwa uchapishaji katika eneo moja una matatizo, tunahamia kwenye uchapishaji katika eneo lingine. Katika kesi hii, orodha iliyotajwa hapo juu lazima iingizwe kwenye bomba la uzalishaji. Nitakuokoa muda na kukupendekeza uangalie mazungumzo yangu ya awali, Uendeshaji wa Uhandisi wa Global Netflix katika Wingu, ikiwa ungependa kuzama zaidi katika mada hii. Rekodi ya video ya hotuba inaweza kutazamwa kwa kufuata kiungo kilicho chini ya slaidi.
Mwishoni mwa mazungumzo, nitazungumza kwa ufupi juu ya shirika na usanifu wa Netflix. Hapo mwanzo tulikuwa na mpango unaoitwa Utoaji wa Kielektroniki, ambao ulikuwa toleo la kwanza la utiririshaji wa media wa NRDP 1.x. Neno "mkondo wa nyuma" linaweza kutumika hapa kwa sababu mwanzoni mtumiaji angeweza kupakua maudhui kwa ajili ya kucheza baadaye kwenye kifaa. Jukwaa la kwanza kabisa la utoaji wa kidijitali la Netflix, mwaka wa 2009, lilionekana kama hii.
Kifaa cha mtumiaji kilikuwa na programu ya Netflix, ambayo ilikuwa na kiolesura cha UI, moduli za usalama, kuwezesha huduma na uchezaji, kulingana na jukwaa la NRDP - Netflix Ready Device Platform.
Wakati huo kiolesura cha mtumiaji kilikuwa rahisi sana. Ilikuwa na kile kilichoitwa Queque Reader, na mtumiaji angeenda kwenye tovuti ili kuongeza kitu kwenye Queque na kisha kutazama maudhui yaliyoongezwa kwenye kifaa chake. Chanya ni kwamba timu ya mbele na timu ya nyuma ilikuwa ya shirika moja la Utoaji wa Kielektroniki na walikuwa na uhusiano wa karibu wa kufanya kazi. Upakiaji uliundwa kulingana na XML. Wakati huo huo, API ya Netflix ya biashara ya DVD iliundwa, ambayo ilihimiza programu za watu wengine kuelekeza trafiki kwa huduma yetu.
Hata hivyo, API ya Netflix ilitayarishwa vyema ili kutusaidia na kiolesura cha ubunifu cha mtumiaji, kilicho na metadata ya maudhui yote, taarifa kuhusu sinema gani zilipatikana, ambayo iliunda uwezo wa kuzalisha orodha za kutazama. Ilikuwa na API ya jumla ya REST kulingana na schema ya JSON, Msimbo wa Majibu wa HTTP, ule ule unaotumika katika usanifu wa kisasa, na muundo wa usalama wa OAuth, ambao ndio ulihitajika wakati huo kwa programu ya mbele. Hii ilifanya iwezekane kuhama kutoka kwa muundo wa umma wa utiririshaji wa maudhui hadi ule wa faragha.
Tatizo la mpito lilikuwa kugawanyika, kwa kuwa sasa mfumo wetu uliendesha huduma mbili kulingana na kanuni tofauti kabisa za uendeshaji - moja kwenye Rest, JSON na OAuth, nyingine kwenye RPC, XML na utaratibu wa usalama wa mtumiaji kulingana na mfumo wa tokeni wa NTBA. Huu ulikuwa usanifu wa kwanza wa mseto.
Kulikuwa na ngome kati ya timu zetu mbili kwa sababu mwanzoni API haikufanya vizuri sana na NCCP na hii ilisababisha msuguano kati ya timu. Tofauti zilikuwa katika huduma, itifaki, saketi, moduli za usalama, na watengenezaji mara nyingi walilazimika kubadili kati ya muktadha tofauti kabisa.
Katika suala hili, nilikuwa na mazungumzo na mmoja wa wahandisi wakuu wa kampuni hiyo, ambaye nilimuuliza swali: "Je, usanifu sahihi wa muda mrefu unapaswa kuwa nini?" na aliuliza swali la kukabiliana: "Labda unajali zaidi. kuhusu matokeo ya shirika - nini kitatokea ikiwa tutaunganisha mambo haya, na yanavunja kile tulichojifunza kufanya vizuri? Mbinu hii inafaa sana kwa Sheria ya Conway: "Mashirika ambayo mifumo ya usanifu inabanwa na muundo unaoiga muundo wa mawasiliano wa shirika hilo." Huu ni ufafanuzi wa kufikirika sana, kwa hivyo napendelea ule maalum zaidi: "Kipande chochote cha programu kinaonyesha muundo wa shirika ulioiunda." Hapa kuna nukuu ninayopenda kutoka kwa Eric Raymond: "Ikiwa una timu nne za wasanidi wanaofanya kazi kwenye mkusanyaji, utaishia na mkusanyaji wa pasi nne." Kweli, Netflix ina mkusanyaji wa pasi nne, na ndivyo tunavyofanya kazi.
Tunaweza kusema kwamba katika kesi hii mkia unatikisa mbwa. Kipaumbele chetu cha kwanza sio suluhisho, lakini shirika; ni shirika ambalo linaendesha usanifu tulionao. Hatua kwa hatua, kutoka kwa hodgepodge ya huduma, tulihamia kwenye usanifu ambao tuliuita Blade Runner, kwa sababu hapa tunazungumzia huduma za makali na uwezo wa NCCP kutenganishwa na kuunganishwa moja kwa moja kwenye proksi ya Zuul, lango la API, na kazi inayolingana. "vipande" vimegeuzwa kuwa huduma ndogo ndogo zenye usalama wa hali ya juu zaidi, kucheza tena, kupanga data, nk.
Kwa hivyo, inaweza kusemwa kuwa miundo ya idara na mienendo ya kampuni ina jukumu muhimu katika kuunda muundo wa mfumo na ni sababu inayokuza au kuzuia mabadiliko. Usanifu wa Microservices ni ngumu na hai, na afya yake inategemea nidhamu na machafuko yaliyoletwa.
Matangazo kidogo
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com