Конференција за QCon. Совладување на хаосот: Водич за микроуслуги на Нетфликс. Дел 4

Џош Еванс зборува за хаотичниот и колоритен свет на микросервисите на Netflix, почнувајќи од самите основи - анатомијата на микросервисите, предизвиците поврзани со дистрибуираните системи и нивните придобивки. Надоврзувајќи се на оваа основа, тој ги истражува културните, архитектонските и оперативните практики кои водат до мајсторство со микросервис.

Конференција за QCon. Совладување на хаосот: Водич за микроуслуги на Нетфликс. Дел 1
Конференција за QCon. Совладување на хаосот: Водич за микроуслуги на Нетфликс. Дел 2
Конференција за QCon. Совладување на хаосот: Водич за микроуслуги на Нетфликс. Дел 3

За разлика од оперативното движење, воведувањето нови јазици за интернационализација на услугите и новите технологии како што се контејнерите се свесни одлуки за додавање нова сложеност на околината. Мојот оперативен тим го стандардизираше најдобриот технолошки патоказ за Netflix, кој беше преработен во претходно дефинирани најдобри практики базирани на Java и EC2, но како што растеше бизнисот, програмерите почнаа да додаваат нови компоненти како што се Python, Ruby, Node-JS и Docker.

Многу сум горд што бевме првите што се заложивме нашиот производ да работи одлично без да чекаме поплаки од клиентите. Сè започна доволно едноставно - имавме оперативни програми во Python и неколку back-office апликации во Ruby, но работите станаа многу поинтересни кога нашите веб-програмери објавија дека ќе го отфрлат JVM и дека ќе ја преместат мрежата. апликација на софтверската платформа Node.js. По воведувањето на Docker, работите станаа многу посложени. Ја следевме логиката и технологиите до кои дојдовме станаа реалност кога ги имплементиравме за клиентите бидејќи имаа многу смисла. Ќе ти кажам зошто е тоа така.

API Gateway всушност има способност да интегрира одлични скрипти кои можат да дејствуваат како крајни точки за развивачите на интерфејс. Тие ја конвертираа секоја од овие скрипти на таков начин што откако ќе ги направат промените, можеа да ги распоредат на производство, а потоа на кориснички уреди, и сите овие промени беа синхронизирани со крајните точки што работеа во портата API.

Сепак, ова го повтори проблемот со создавање на нов монолит каде што услугата API беше преоптоварена со код на таков начин што се случија различни сценарија за неуспех. На пример, некои крајни точки беа отстранети, или скриптите случајно генерираа толку многу верзии на нешто што верзиите ја заземаа целата достапна меморија на услугата API.

Логично беше да се земат овие крајни точки и да се извлечат од услугата API. За да го направите ова, создадовме компоненти на Node.js кои работеа како мали апликации во контејнерите на Docker. Ова ни овозможи да ги изолираме сите проблеми и падови предизвикани од овие апликации за јазли.

Цената на овие промени е прилично голема и се состои од следниве фактори:

• Алатки за продуктивност. Управувањето со новите технологии бараше нови алатки бидејќи тимот на UI, користејќи многу добри скрипти за да создаде ефикасен модел, не мораше да троши многу време за управување со инфраструктурата, тие требаше само да пишуваат скрипти и да ја проверат нивната функционалност.
  Увид во можностите и сортирање - Клучен пример се новите алатки потребни за да се откријат информациите за двигателот за перформансите. Требаше да се знае колку процесорот е окупиран, како се користи меморијата и за собирање на овие информации потребни се различни алатки.
• Фрагментација на основни слики - едноставната основна AMI стана пофрагментирана и специјализирана.
• Управување со јазли. Не постои достапна архитектура или технологија што ви овозможува да управувате со јазли во облакот, па затоа изградивме Titus, платформа за управување со контејнери која обезбедува скалабилно и сигурно распоредување на контејнери и интеграција во облак со Amazon AWS.
• Умножување на библиотека или платформа. Обезбедувањето нови технологии со истата основна функционалност на платформата бараше нејзино дуплирање во алатки за програмери Node.js базирани на облак.
• Крива на учење и индустриско искуство. Воведувањето на нови технологии неминовно создава нови предизвици кои мора да се надминат и од нив да се научи.

Така, не можевме да се ограничиме на еден „асфалтиран пат“ и моравме постојано да градиме нови начини за унапредување на нашите технологии. За да ги намалиме трошоците, ја ограничивме централизираната поддршка и се фокусиравме на JVM, новите јазли и Docker. Направивме приоритет на ефективно влијание, ги информиравме тимовите за цената на нивните одлуки и ги охрабривме да бараат начини за повторно користење на решенијата со големо влијание што веќе ги развија. Овој пристап го користевме при преведување на услугата на странски јазици за да го доставиме производот до меѓународни клиенти. Примерите вклучуваат релативно едноставни библиотеки на клиенти кои можат да се генерираат автоматски, така што е прилично лесно да се создаде верзија на Python, верзија Ruby, верзија Java итн.

Постојано баравме можности да користиме докажани технологии кои се докажаа на едно место и во други слични ситуации.

Ајде да зборуваме за последниот елемент - промени или варијации. Погледнете како потрошувачката на нашиот производ варира нерамномерно по ден во неделата и по час во текот на денот. Може да се каже дека 9 часот наутро е најтешкото време за Netflix, кога оптоварувањето на системот го достигнува својот максимум.

Како да постигнеме голема брзина на имплементација на софтверските иновации, односно постојано да правиме нови промени во системот, без да предизвикуваме прекини во испораката на услугите и без да им создаваме непријатности на нашите клиенти? Netflix го постигна ова преку употреба на Spinnaker, нова глобална платформа за управување и континуирана испорака (CD) базирана на облак.

Критички, Spinnaker е дизајниран да ги интегрира нашите најдобри практики, така што додека ги распоредуваме компонентите во производството, можеме да го интегрираме излезот директно во нашата технологија за испорака на медиуми.

Успеавме да вградиме две технологии во нашиот цевковод за испорака што многу ги цениме: автоматска анализа на канари и етапно распоредување. Анализата на Канари значи дека ние насочуваме малку сообраќај кон новата верзија на кодот, а остатокот од производствениот сообраќај го пренесуваме преку старата верзија. Потоа проверуваме како новиот код се справува со задачата - подобар или полош од постоечкиот.

Завртеното пуштање во употреба значи дека ако префрлањето во еден регион има проблеми, се префрламе на воведување во друг регион. Во овој случај, горенаведената листа за проверка мора да биде вклучена во производниот цевковод. Ќе ви заштедам малку време и ќе ви препорачам да го погледнете мојот претходен говор, Инженерски глобални операции на Netflix во облакот, доколку сте заинтересирани да нурнете подлабоко во оваа тема. Видеоснимката од говорот може да се погледне со следење на врската на дното на слајдот.

На крајот од говорот накратко ќе зборувам за организацијата и архитектурата на Нетфликс. На самиот почеток имавме шема наречена Електронска испорака, која беше првата верзија на NRDP 1.x стриминг на медиуми. Терминот „backstream“ може да се користи овде бидејќи првично корисникот можел да презема содржини само за подоцнежна репродукција на уредот. Првата платформа за дигитална испорака на Нетфликс, во 2009 година, изгледаше вака.

Корисничкиот уред ја содржеше апликацијата Netflix, која се состоеше од интерфејс за интерфејс, безбедносни модули, активирање и репродукција на услугата, базирана на платформата NRDP - Netflix Ready Device Platform.

Во тоа време корисничкиот интерфејс беше многу едноставен. Содржеше она што се нарекуваше Queque Reader, а корисникот одеше на страницата за да додаде нешто во Queque и потоа ја гледаше додадената содржина на својот уред. Позитивно беше тоа што тимот на предниот дел и тимот на задниот дел припаѓаа на истата организација за електронска испорака и имаа блиски работни односи. Товарот е создаден врз основа на XML. Во исто време, беше создаден Netflix API за бизнисот со ДВД, што ги охрабри апликациите од трети страни да го насочат сообраќајот кон нашата услуга.

Сепак, Netflix API беше добро подготвен да ни помогне со иновативен кориснички интерфејс, кој содржи метаподатоци за целата содржина, информации за тоа кои филмови беа достапни, што создаде можност за генерирање списоци за гледање. Имаше генерички REST API заснован на шемата JSON, код за одговор на HTTP, истиот што се користи во модерната архитектура и безбедносен модел OAuth, што беше она што беше потребно во тоа време за предната апликација. Ова овозможи да се пресели од јавен модел на испорака на содржини за стриминг на приватен.

Проблемот со транзицијата беше фрагментацијата, бидејќи сега нашиот систем управуваше со две услуги засновани на сосема различни принципи на работа - едната на Rest, JSON и OAuth, другата на RPC, XML и безбедносниот механизам на корисникот базиран на системот за токени NTBA. Ова беше првата хибридна архитектура.

Во суштина постоеше заштитен ѕид помеѓу нашите два тима затоа што првично API не се совпаѓаше многу добро со NCCP и тоа доведе до триење меѓу тимовите. Разликите беа во услугите, протоколите, кола, безбедносните модули, а програмерите честопати мораа да се префрлаат помеѓу сосема различни контексти.

Во врска со ова, имав разговор со еден од високите инженери на компанијата, кому му го поставив прашањето: „Каква треба да биде вистинската долгорочна архитектура?“, а тој го постави контра прашањето: „Веројатно сте повеќе загрижени. за организациските последици - што се случува ако ги интегрираме овие работи, а тие го скршат она што сме научиле да го правиме добро? Овој пристап е многу релевантен за Законот на Конвеј: „Организациите кои дизајнираат системи се ограничени од дизајн кој ја реплицира комуникациската структура на таа организација“. Ова е многу апстрактна дефиниција, па затоа претпочитам поконкретна: „Секое парче софтвер ја одразува организациската структура што го создала“. Еве го мојот омилен цитат од Ерик Рејмонд: „Ако имате четири тима на програмери кои работат на компајлер, ќе завршите со компајлер со четири премини“. Па, Нетфликс има компајлер со четири премини, и така работиме.

Можеме да кажеме дека во овој случај опашката го мава кучето. Нашиот прв приоритет не е решението, туку организацијата; организацијата е таа што ја движи архитектурата што ја имаме. Постепено, од куп услуги, се преселивме во архитектура која ја нарековме Blade Runner, бидејќи овде зборуваме за edge услуги и способноста на NCCP да се одвои и интегрира директно во Zuul прокси, API gateway и соодветните функционални „Парчињата“ се претворени во нови микросервиси со понапредни функции за безбедност, повторување, сортирање податоци итн.

Така, може да се каже дека одделенските структури и динамиката на компанијата играат важна улога во обликувањето на дизајнот на системот и се фактор кој промовира или попречува промени. Архитектурата на микроуслугите е сложена и органска, а нејзиното здравје се заснова на дисциплина и воведен хаос.

Малку рекламирање

Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, облак VPS за програмери од 4.99 долари, уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: Целата вистина за VPS (KVM) E5-2697 v3 (6 јадра) 10GB DDR4 480GB SSD 1Gbps од 19 долари или како да споделите сервер? (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB DDR4).

Dell R730xd 2 пати поевтин во центарот за податоци Equinix Tier IV во Амстердам? Само овде 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 телевизор од 199 долари во Холандија! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - од 99 долари! Прочитајте за Како да се изгради инфраструктурна корп. класа со употреба на сервери Dell R730xd E5-2650 v4 вредни 9000 евра за денар?

Извор: www.habr.com