Josh Evans Netflix mikroservislarining xaotik va rang-barang dunyosi haqida gapiradi, u eng asoslardan - mikroservislar anatomiyasidan, taqsimlangan tizimlar bilan bog'liq muammolar va ularning afzalliklaridan boshlanadi. Ushbu poydevorga asoslanib, u mikroservisni o'zlashtirishga olib keladigan madaniy, arxitektura va operatsion amaliyotlarni o'rganadi.
Operatsion driftdan farqli o'laroq, xizmatni xalqarolashtirish uchun yangi tillarni joriy etish va konteynerlar kabi yangi texnologiyalar atrof-muhitga yangi murakkablik kiritish uchun ongli qarorlardir. Mening operatsion guruhim Netflix uchun eng yaxshi texnologiya yo'l xaritasini standartlashtirdi, u Java va EC2 asosida oldindan belgilangan eng yaxshi amaliyotlarga aylantirildi, ammo biznes o'sishi bilan ishlab chiquvchilar Python, Ruby, Node-JS va Docker kabi yangi komponentlarni qo'shishni boshladilar.
Mijozlarning shikoyatlarini kutmasdan mahsulotimiz ajoyib ishlashini birinchi bo‘lib biz qo‘llab-quvvatlaganimizdan juda faxrlanaman. Hammasi juda oddiy boshlandi - bizda Python-da operatsion dasturlar va Ruby-da bir nechta orqa ofis ilovalari bor edi, lekin bizning veb-ishlab chiquvchilarimiz JVM-dan voz kechishlarini va Internetni ko'chirishni e'lon qilishganida, ishlar ancha qiziqroq bo'ldi. Node dasturiy platformasiga ilova. js. Docker joriy etilgandan so'ng, ishlar ancha murakkablashdi. Biz mantiqqa amal qildik va biz o'ylab topgan texnologiyalar mijozlar uchun ularni amalga oshirganimizda haqiqatga aylandi, chunki ular juda mantiqiy edi. Men sizga nima uchun bunday bo'lganini aytaman.
API Gateway aslida UI ishlab chiquvchilari uchun so'nggi nuqta sifatida harakat qiladigan ajoyib skriptlarni birlashtirish qobiliyatiga ega. Ular ushbu skriptlarning har birini shunday o'zgartirdilarki, o'zgartirishlar kiritilgandan so'ng ularni ishlab chiqarishga, keyin esa foydalanuvchi qurilmalariga joylashtirishlari mumkin edi va bu o'zgarishlarning barchasi API shlyuzida ishlaydigan so'nggi nuqtalar bilan sinxronlashtirildi.
Biroq, bu yangi monolit yaratish muammosini takrorladi, bu erda API xizmati turli xil nosozlik stsenariylari yuzaga kelgan tarzda kod bilan haddan tashqari yuklangan. Misol uchun, ba'zi so'nggi nuqtalar olib tashlandi yoki skriptlar tasodifiy ravishda bir narsaning shunchalik ko'p versiyalarini yaratdiki, versiyalar API xizmatining barcha mavjud xotirasini egalladi.
Ushbu so'nggi nuqtalarni olib, ularni API xizmatidan tortib olish mantiqan to'g'ri edi. Buning uchun biz Docker konteynerlarida kichik ilovalar sifatida ishlaydigan Node.js komponentlarini yaratdik. Bu bizga ushbu tugun ilovalari sabab bo'lgan har qanday muammo va buzilishlarni izolyatsiya qilish imkonini berdi.
Ushbu o'zgarishlarning narxi ancha katta va quyidagi omillardan iborat:
- Hosildorlik vositalari. Yangi texnologiyalarni boshqarish yangi vositalarni talab qildi, chunki samarali model yaratish uchun juda yaxshi skriptlardan foydalangan UI jamoasi infratuzilmani boshqarish uchun ko'p vaqt sarflashi shart emas edi, ular faqat skriptlarni yozishlari va ularning funksionalligini tekshirishlari kerak edi.
Imkoniyatlarni tushunish va saralash - asosiy misol - bu samaradorlik drayverlari ma'lumotlarini ochish uchun zarur bo'lgan yangi vositalar. Protsessor qancha band bo'lganini, xotiradan qanday foydalanayotganini bilish kerak edi va bu ma'lumotlarni yig'ish turli xil vositalarni talab qildi. - Asosiy tasvirlarning parchalanishi - oddiy AMI bazasi yanada parchalanib, ixtisoslashgan.
- Tugun boshqaruvi. Bulutdagi tugunlarni boshqarish imkonini beruvchi tayyor arxitektura yoki texnologiya mavjud emas, shuning uchun biz Amazon AWS bilan kengaytiriladigan va ishonchli konteyner joylashtirish va bulut integratsiyasini taʼminlovchi konteyner boshqaruv platformasi Titusni yaratdik.
- Kutubxona yoki platformaning takrorlanishi. Platformaning bir xil asosiy funksiyalari bilan yangi texnologiyalarni taʼminlash uchun uni bulutga asoslangan Node.js dasturchi vositalariga koʻpaytirish kerak edi.
- Egri chiziq va sanoat tajribasini o'rganish. Yangi texnologiyalarni joriy etish muqarrar ravishda engib o'tish va o'rganish kerak bo'lgan yangi muammolarni keltirib chiqaradi.
Shunday qilib, biz o'zimizni bitta "asfaltlangan yo'l" bilan cheklab qo'ya olmadik va texnologiyalarimizni rivojlantirish uchun doimo yangi yo'llarni qurishimiz kerak edi. Xarajatlarni kamaytirish uchun biz markazlashtirilgan yordamni chekladik va JVM, yangi tugunlar va Docker-ga e'tibor qaratdik. Biz samarali ta'sirni birinchi o'ringa qo'ydik, jamoalarni qarorlarining narxi haqida xabardor qildik va ularni allaqachon ishlab chiqqan yuqori ta'sirli yechimlardan qayta foydalanish yo'llarini izlashga undadik. Biz mahsulotni xalqaro mijozlarga yetkazib berish uchun xizmatni xorijiy tillarga tarjima qilishda ushbu yondashuvdan foydalandik. Masalan, Python versiyasini, Ruby versiyasini, Java versiyasini va boshqalarni yaratish juda oson bo'lishi uchun avtomatik ravishda yaratilishi mumkin bo'lgan nisbatan oddiy mijoz kutubxonalarini o'z ichiga oladi.
Biz doimo bir joyda va boshqa shunga o'xshash vaziyatlarda o'zini isbotlagan tasdiqlangan texnologiyalardan foydalanish imkoniyatlarini qidirar edik.
Keling, oxirgi element - o'zgarishlar yoki o'zgarishlar haqida gapiraylik. Qarang, mahsulotimiz iste'moli kun davomida haftaning kuniga va soatiga qarab notekis o'zgarib turadi. Aytishingiz mumkinki, soat 9:XNUMX tizimdagi yuk maksimal darajaga etganda Netflix uchun eng qiyin vaqt.
Qanday qilib biz xizmat ko‘rsatishda uzilishlar va mijozlarimizga noqulayliklar tug‘dirmasdan, tizimga yangi o‘zgartirishlar kiritib, dasturiy innovatsiyalarni joriy etishning yuqori tezligiga erishishimiz mumkin? Netflix bunga Spinnaker, bulutga asoslangan yangi global boshqaruv va uzluksiz yetkazib berish (CD) platformasidan foydalanish orqali erishdi.
Muhimi, Spinnaker bizning eng yaxshi tajribalarimizni birlashtirish uchun ishlab chiqilgan bo'lib, biz komponentlarni ishlab chiqarishga joylashtirganimizda, biz mahsulotni to'g'ridan-to'g'ri media yetkazib berish texnologiyamizga integratsiyalashimiz mumkin.
Biz yetkazib berish quvurimizga ikkita texnologiyani qo‘shishga muvaffaq bo‘ldik, biz ularni juda qadrlaymiz: avtomatlashtirilgan kanareyka tahlili va bosqichma-bosqich joylashtirish. Kanareyka tahlili shuni anglatadiki, biz trafik oqimini kodning yangi versiyasiga yo'naltiramiz va qolgan ishlab chiqarish trafigini eski versiya orqali o'tkazamiz. Keyin biz yangi kod vazifani qanday bajarishini tekshiramiz - mavjudidan yaxshiroq yoki yomonroq.
Bosqichli tarqatish, agar biror mintaqadagi tarqatishda muammo bo'lsa, biz boshqa mintaqadagi tarqatishga o'tamiz. Bunday holda, yuqorida ko'rsatilgan nazorat ro'yxati ishlab chiqarish quvuriga kiritilishi kerak. Men sizga bir oz vaqtni tejayman va agar siz ushbu mavzuni chuqurroq o'rganishga qiziqsangiz, avvalgi ma'ruzamni "Bulutdagi global Netflix operatsiyalari muhandisligi" ni ko'rib chiqishingizni tavsiya qilaman. Nutqning videoyozuvini slaydning pastki qismidagi havola orqali ko‘rish mumkin.
Suhbat oxirida men Netflixning tashkil etilishi va arxitekturasi haqida qisqacha gapirib beraman. Eng boshida bizda NRDP 1.x media oqimining birinchi versiyasi bo'lgan Elektron yetkazib berish deb nomlangan sxema mavjud edi. Bu erda "orqa oqim" atamasi ishlatilishi mumkin, chunki dastlab foydalanuvchi faqat keyinchalik qurilmada ijro etish uchun kontentni yuklab olishi mumkin edi. Netflix-ning 2009 yilda birinchi raqamli yetkazib berish platformasi shunga o'xshash edi.
Foydalanuvchi qurilmasida NRDP platformasi - Netflix Ready Device Platform-ga asoslangan UI interfeysi, xavfsizlik modullari, xizmatni faollashtirish va ijro etishdan iborat Netflix ilovasi mavjud edi.
O'sha paytda foydalanuvchi interfeysi juda oddiy edi. Unda Queque Reader deb ataladigan narsa bor edi va foydalanuvchi Queque-ga biror narsa qo'shish uchun saytga boradi va keyin qo'shilgan tarkibni o'z qurilmasida ko'radi. Ijobiy tomoni shundaki, oldingi jamoa va orqa tomon jamoasi bir xil Elektron yetkazib berish tashkilotiga tegishli edi va yaqin ish munosabatlariga ega edi. Foydali yuk XML asosida yaratilgan. Shu bilan birga, DVD biznesi uchun Netflix API yaratildi, bu uchinchi tomon ilovalarini bizning xizmatimizga trafikni yo'naltirishga undadi.
Biroq, Netflix API bizga barcha kontentning meta-ma'lumotlarini, tomosha ro'yxatini yaratish imkoniyatini yaratgan qanday filmlar mavjudligi haqidagi ma'lumotlarni o'z ichiga olgan innovatsion foydalanuvchi interfeysi bilan yordam berish uchun yaxshi tayyorlangan. Unda JSON sxemasiga asoslangan umumiy REST API, zamonaviy arxitekturada ishlatiladigan HTTP javob kodi va o'sha paytda front-end ilovasi uchun zarur bo'lgan OAuth xavfsizlik modeli mavjud edi. Bu oqimli kontentni yetkazib berishning ommaviy modelidan shaxsiy modelga o'tish imkonini berdi.
O'tish bilan bog'liq muammo parchalanish edi, chunki endi bizning tizimimiz mutlaqo boshqa ish printsiplariga asoslangan ikkita xizmatni - biri Rest, JSON va OAuth-da, ikkinchisi RPC, XML-da va NTBA token tizimiga asoslangan foydalanuvchi xavfsizligi mexanizmida ishlaydi. Bu birinchi gibrid arxitektura edi.
Ikki jamoamiz o'rtasida asosan xavfsizlik devori mavjud edi, chunki dastlab API NCCP bilan unchalik yaxshi ishlamadi va bu jamoalar o'rtasida ishqalanishga olib keldi. Farqlar xizmatlar, protokollar, sxemalar, xavfsizlik modullarida edi va ishlab chiquvchilar ko'pincha butunlay boshqa kontekstlar o'rtasida o'tishlari kerak edi.
Shu munosabat bilan men kompaniyaning katta muhandislaridan biri bilan suhbatlashdim, unga savol berdim: "Uzoq muddatli arxitektura qanday bo'lishi kerak?" va u qarshi savolni berdi: "Sizni ko'proq tashvishlantirayotgandirsiz. tashkiliy oqibatlar haqida - agar biz bu narsalarni birlashtirsak va ular biz yaxshi qilishni o'rgangan narsalarni buzsa nima bo'ladi? Ushbu yondashuv Konvey qonuniga juda mos keladi: "Tizimlarni loyihalash ushbu tashkilotning aloqa tuzilmasini takrorlaydigan dizayn bilan cheklanadigan tashkilotlar". Bu juda mavhum ta'rif, shuning uchun men aniqroq ta'rifni afzal ko'raman: "Har qanday dasturiy ta'minot uni yaratgan tashkiliy tuzilmani aks ettiradi." Mana, Erik Raymondning eng sevimli iqtiboslari: "Agar sizda kompilyator ustida ishlayotgan to'rtta dasturchilar jamoasi bo'lsa, siz to'rt bosqichli kompilyatorga ega bo'lasiz." Xo'sh, Netflix to'rt o'tishli kompilyatorga ega va biz shunday ishlaymiz.
Aytishimiz mumkinki, bu holda quyruq itni silkitadi. Bizning birinchi ustuvorligimiz yechim emas, balki tashkilotdir; bu bizda mavjud bo'lgan arxitekturani boshqaradigan tashkilotdir. Asta-sekin, xizmatlar to'plamidan biz Blade Runner deb nomlangan arxitekturaga o'tdik, chunki bu erda biz chekka xizmatlar va NCCP-ni Zuul proksi-serveriga, API shlyuziga va mos keladigan funktsional xususiyatlarga ajratish va integratsiya qilish qobiliyati haqida gapiramiz. "Bo'laklar" yanada rivojlangan xavfsizlik, takrorlash, ma'lumotlarni saralash va hokazo xususiyatlarga ega yangi mikroservislarga aylantirildi.
Shunday qilib, shuni aytish mumkinki, bo'lim tuzilmalari va kompaniya dinamikasi tizim dizaynini shakllantirishda muhim rol o'ynaydi va o'zgarishlarni rag'batlantiradigan yoki to'sqinlik qiluvchi omil hisoblanadi. Mikroservislar arxitekturasi murakkab va organik bo'lib, uning sog'lig'i tartib-intizom va joriy qilingan tartibsizlikka asoslangan.
Bir oz reklama
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com