Coş Evans Netflix mikroservislərinin xaotik və rəngarəng dünyasından danışır, ən əsaslardan - mikroxidmətlərin anatomiyasından, paylanmış sistemlərlə bağlı çətinliklərdən və onların üstünlüklərindən başlayır. Bu təməl üzərində quraraq, o, mikroservis ustalığına gətirib çıxaran mədəni, memarlıq və əməliyyat təcrübələrini araşdırır.
Əməliyyat driftindən fərqli olaraq, xidmətin beynəlxalqləşməsi üçün yeni dillərin tətbiqi və konteynerlər kimi yeni texnologiyalar ətraf mühitə yeni mürəkkəblik əlavə etmək üçün şüurlu qərarlardır. Əməliyyatlar komandam Java və EC2 əsasında əvvəlcədən müəyyən edilmiş ən yaxşı təcrübələrə çevrilmiş Netflix üçün ən yaxşı texnologiya yol xəritəsində standartlaşdırıldı, lakin biznes böyüdükcə tərtibatçılar Python, Ruby, Node-JS və Docker kimi yeni komponentlər əlavə etməyə başladılar.
Mən çox qürur duyuram ki, müştəri şikayətlərini gözləmədən məhsulumuzun əla işləməsini ilk müdafiə edən biz olmuşuq. Hər şey kifayət qədər sadə başladı - bizim Python-da əməliyyat proqramlarımız və Ruby-də bir neçə back-ofis proqramımız var idi, lakin veb tərtibatçılarımız JVM-dən əl çəkəcəklərini və interneti köçürəcəklərini elan etdikdə işlər daha da maraqlı oldu. Node proqram platformasına tətbiq.js. Docker-in tətbiqindən sonra işlər daha mürəkkəbləşdi. Biz məntiqə əməl etdik və əldə etdiyimiz texnologiyaları müştərilər üçün tətbiq etdikdə reallığa çevrildi, çünki onlar çox mənalı idi. Bunun niyə belə olduğunu sizə deyəcəyəm.
API Gateway əslində UI tərtibatçıları üçün son nöqtə kimi çıxış edə bilən əla skriptləri inteqrasiya etmək qabiliyyətinə malikdir. Onlar bu skriptlərin hər birini elə çevirdilər ki, dəyişikliklər etdikdən sonra onları istehsala, sonra isə istifadəçi cihazlarına yerləşdirə bildilər və bütün bu dəyişikliklər API şlüzündə işləyən son nöqtələrlə sinxronlaşdırıldı.
Bununla belə, bu, API xidmətinin kodla həddən artıq yükləndiyi yeni monolit yaratmaq problemini təkrarladı ki, müxtəlif uğursuzluq ssenariləri baş verdi. Məsələn, bəzi son nöqtələr silindi və ya skriptlər təsadüfi olaraq bir şeyin o qədər çox versiyasını yaratdı ki, versiyalar API xidmətinin bütün mövcud yaddaşını tutdu.
Bu son nöqtələri götürüb API xidmətindən çıxarmaq məntiqli idi. Bunun üçün biz Docker konteynerlərində kiçik proqramlar kimi işləyən Node.js komponentlərini yaratdıq. Bu, bizə bu node proqramlarının yaratdığı hər hansı problem və qəzaları təcrid etməyə imkan verdi.
Bu dəyişikliklərin dəyəri olduqca böyükdür və aşağıdakı amillərdən ibarətdir:
- Məhsuldarlıq alətləri. Yeni texnologiyaların idarə edilməsi yeni alətlər tələb edirdi, çünki səmərəli model yaratmaq üçün çox yaxşı skriptlərdən istifadə edən UI komandası infrastrukturun idarə edilməsinə çox vaxt sərf etməli deyildi, onlar yalnız skriptlər yazmaq və onların funksionallığını yoxlamaq məcburiyyətində qaldılar.
Opportunity Insight and Sorting - Əsas nümunə performans sürücüsü məlumatlarını aşkar etmək üçün lazım olan yeni alətlərdir. Prosessorun nə qədər məşğul olduğunu, yaddaşın necə istifadə edildiyini bilmək lazım idi və bu məlumatların toplanması müxtəlif alətlər tələb edirdi. - Əsas təsvirlərin parçalanması - sadə baza AMI daha parçalanmış və ixtisaslaşmış olmuşdur.
- Düyün idarə edilməsi. Buludda qovşaqları idarə etməyə imkan verən heç bir hazır memarlıq və ya texnologiya mövcud deyil, ona görə də biz Amazon AWS ilə miqyaslana bilən və etibarlı konteyner yerləşdirilməsi və bulud inteqrasiyasını təmin edən konteyner idarəetmə platforması olan Titus yaratdıq.
- Kitabxananın və ya platformanın təkrarlanması. Platformanın eyni əsas funksionallığı ilə yeni texnologiyaların təmin edilməsi onun bulud əsaslı Node.js tərtibatçı alətlərinə təkrarlanmasını tələb edirdi.
- Öyrənmə əyrisi və sənaye təcrübəsi. Yeni texnologiyaların tətbiqi qaçılmaz olaraq aradan qaldırılmalı və öyrənilməli olan yeni problemlər yaradır.
Beləliklə, biz özümüzü bir “asfalt yol”la məhdudlaşdıra bilmədik və texnologiyalarımızı inkişaf etdirmək üçün daim yeni yollar qurmalı olduq. Xərcləri azaltmaq üçün biz mərkəzləşdirilmiş dəstəyi məhdudlaşdırdıq və diqqəti JVM, yeni qovşaqlar və Docker-ə yönəltdik. Biz effektiv təsirə üstünlük verdik, komandaları qərarlarının dəyəri barədə məlumatlandırdıq və onları artıq inkişaf etdirdikləri yüksək təsirli həllərdən yenidən istifadə etmək yollarını axtarmağa təşviq etdik. Məhsulu beynəlxalq müştərilərə çatdırmaq üçün xidməti xarici dillərə tərcümə edərkən bu yanaşmadan istifadə etdik. Nümunələr arasında Python versiyasını, Ruby versiyasını, Java versiyasını və s. yaratmaq kifayət qədər asan olması üçün avtomatik yaradıla bilən nisbətən sadə müştəri kitabxanaları daxildir.
Biz daim bir yerdə və digər oxşar vəziyyətlərdə özünü sübut etmiş sübut edilmiş texnologiyalardan istifadə imkanlarını axtarırdıq.
Sonuncu elementdən danışaq - dəyişikliklər və ya varyasyonlar. Görün məhsulumuzun istehlakı həftənin gününə və gün ərzində saata görə necə qeyri-bərabər dəyişir. Səhər saat 9-un Netflix üçün ən çətin vaxt olduğunu, sistemdəki yükün maksimuma çatdığını söyləyə bilərsiniz.
Proqram təminatı innovasiyalarının tətbiqinin yüksək sürətinə, yəni sistemdə daim yeni dəyişikliklər etməklə, xidmətin göstərilməsində fasilələr yaratmadan və müştərilərimizə narahatlıq yaratmadan necə nail ola bilərik? Netflix buna yeni qlobal bulud əsaslı idarəetmə və davamlı çatdırılma (CD) platforması olan Spinnaker-dən istifadə etməklə nail olub.
Tənqidi olaraq, Spinnaker ən yaxşı təcrübələrimizi inteqrasiya etmək üçün hazırlanmışdır ki, biz komponentləri istehsala yerləşdirdikcə, biz məhsulu birbaşa media çatdırılma texnologiyamıza inteqrasiya edə bilək.
Biz yüksək qiymətləndirdiyimiz iki texnologiyanı çatdırılma xəttimizə daxil edə bildik: avtomatlaşdırılmış kanar analizi və mərhələli yerləşdirmə. Canary analizi o deməkdir ki, biz trafik axınını kodun yeni versiyasına yönəldirik və istehsal trafikinin qalan hissəsini köhnə versiyadan keçirik. Sonra yeni kodun tapşırığın öhdəsindən necə gəldiyini yoxlayırıq - mövcud olandan daha yaxşı və ya daha pis.
Mərhələli yayım o deməkdir ki, bir bölgədə yayımda problem olarsa, biz başqa regionda yayıma keçəcəyik. Bu halda, yuxarıda qeyd olunan yoxlama siyahısı istehsal boru kəmərinə daxil edilməlidir. Mən sizə bir az vaxta qənaət edəcəyəm və bu mövzuya daha dərindən baxmaqda maraqlısınızsa, əvvəlki çıxışıma, “Buludda Qlobal Netflix Əməliyyatlarının Mühəndisliyi”nə baxmağı tövsiyə edəcəyəm. Çıxışın videoyazısına slaydın altındakı linkə daxil olaraq baxmaq olar.
Söhbətin sonunda Netflix-in təşkili və arxitekturası haqqında qısaca danışacağam. İlk vaxtlarda NRDP 1.x media axınının ilk versiyası olan Elektron Çatdırılma adlı bir sxemimiz var idi. Burada "backstream" termini istifadə edilə bilər, çünki əvvəlcə istifadəçi yalnız sonradan cihazda oxutmaq üçün məzmunu endirə bilərdi. Netflix-in 2009-cu ildə ilk rəqəmsal çatdırılma platforması buna bənzəyirdi.
İstifadəçi cihazında NRDP platforması - Netflix Ready Device Platform-a əsaslanan UI interfeysi, təhlükəsizlik modulları, xidmətin aktivləşdirilməsi və oxutmadan ibarət Netflix tətbiqi var idi.
O zaman istifadəçi interfeysi çox sadə idi. O, Queque Reader adlanan şeyi ehtiva edir və istifadəçi Queque-ə nəsə əlavə etmək üçün sayta daxil olur və sonra öz cihazında əlavə edilmiş məzmuna baxırdı. Müsbət cəhət o idi ki, ön tərəf komandası və arxa tərəf komandası eyni Elektron Çatdırılma təşkilatına mənsub idi və sıx iş əlaqəsi var idi. Faydalı yük XML əsasında yaradılmışdır. Eyni zamanda DVD biznesi üçün Netflix API yaradıldı ki, bu da üçüncü tərəf proqramlarını trafiki xidmətimizə yönəltməyə təşviq etdi.
Bununla belə, Netflix API bizə baxış siyahıları yaratmaq imkanı yaradan bütün məzmunun metadatasını, mövcud filmlər haqqında məlumatları ehtiva edən yenilikçi istifadəçi interfeysi ilə kömək etmək üçün yaxşı hazırlanmışdır. O, JSON sxeminə əsaslanan ümumi REST API-yə, müasir arxitekturada istifadə edilən HTTP Cavab Koduna və o zaman front-end tətbiqi üçün tələb olunan OAuth təhlükəsizlik modelinə malik idi. Bu, axın məzmununun çatdırılmasının ictimai modelindən özəl modelə keçməyə imkan verdi.
Keçid problemi parçalanma idi, çünki indi sistemimiz tamamilə fərqli iş prinsiplərinə əsaslanan iki xidmətlə işləyirdi - biri Rest, JSON və OAuth-da, digəri RPC, XML-də və NTBA token sisteminə əsaslanan istifadəçi təhlükəsizlik mexanizmi. Bu, ilk hibrid memarlıq idi.
Əsasən iki komandamız arasında firewall var idi, çünki əvvəlcə API NCCP ilə çox yaxşı miqyasda deyildi və bu, komandalar arasında sürtünməyə səbəb oldu. Fərqlər xidmətlərdə, protokollarda, sxemlərdə, təhlükəsizlik modullarında idi və tərtibatçılar çox vaxt tamamilə fərqli kontekstlər arasında keçid etməli olurdular.
Bununla əlaqədar, şirkətin baş mühəndislərindən biri ilə söhbət etdim, ona sual verdim: “Uzun müddətli arxitektura nə olmalıdır?” və o, əks sual verdi: “Yəqin ki, sizi daha çox narahat edirsiniz. təşkilati nəticələr haqqında - əgər biz bunları birləşdirsək və yaxşı etməyi öyrəndiyimiz şeyi pozarsaq nə olar? Bu yanaşma Conway Qanununa çox uyğundur: “Sistemlərin layihələndirilməsi həmin təşkilatın kommunikasiya strukturunu təkrarlayan dizaynla məhdudlaşdırılan təşkilatlar”. Bu çox mücərrəd tərifdir, ona görə də mən daha konkret birinə üstünlük verirəm: “Hər hansı bir proqram təminatı onu yaradan təşkilati strukturu əks etdirir.” Erik Raymonddan ən çox sevdiyim sitat budur: "Əgər sizin tərtibatçılardan ibarət dörd komandanız kompilyator üzərində işləyirsə, nəticədə dörd keçidli kompilyator əldə edəcəksiniz." Yaxşı, Netflix-in dörd keçidli kompilyatoru var və biz belə işləyirik.
Deyə bilərik ki, bu halda quyruq iti yelləyir. Bizim birinci prioritetimiz həll yolu deyil, təşkilatdır; malik olduğumuz arxitekturanı idarə edən təşkilatdır. Tədricən, bir sıra xidmətlərdən Blade Runner adlandırdığımız arxitekturaya keçdik, çünki burada kənar xidmətlərdən və NCCP-nin birbaşa Zuul proksisinə, API şlüzinə və müvafiq funksionala ayrılıb inteqrasiya olunmaq qabiliyyətindən danışırıq. “parçalar” daha təkmil təhlükəsizlik, təkrar oxutma, məlumatların çeşidlənməsi və s. xüsusiyyətləri olan yeni mikroservislərə çevrildi.
Beləliklə, demək olar ki, departament strukturları və şirkət dinamikası sistem dizaynının formalaşmasında mühüm rol oynayır və dəyişiklikləri təşviq edən və ya əngəlləyən amildir. Mikroservislərin arxitekturası mürəkkəb və orqanikdir və onun sağlamlığı nizam-intizam və xaosa əsaslanır.
Bir az reklam
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com