Джош Еванс говори за хаотичния и пъстър свят на микроуслугите на Netflix, започвайки със самите основи – анатомията на микроуслугите, предизвикателствата, свързани с разпределените системи, и техните предимства. Надграждайки тази основа, той изследва културните, архитектурните и оперативните практики, които водят до овладяване на микросервизите.
За разлика от оперативния дрейф, въвеждането на нови езици за интернационализация на услугите и нови технологии като контейнери са съзнателни решения за добавяне на нова сложност към средата. Моят оперативен екип стандартизира най-добрата технологична пътна карта за Netflix, която беше вградена в предварително дефинирани най-добри практики, базирани на Java и EC2, но с разрастването на бизнеса разработчиците започнаха да добавят нови компоненти като Python, Ruby, Node-JS и Docker.
Много съм горд, че ние бяхме първите, които се застъпиха за това нашият продукт да работи отлично, без да чакаме оплаквания от клиенти. Всичко започна достатъчно просто - имахме операционни програми в Python и няколко бек-офис приложения в Ruby, но нещата станаха много по-интересни, когато нашите уеб разработчици обявиха, че ще се откажат от JVM и ще преместят мрежата приложение към софтуерната платформа Node. js. След въвеждането на Docker нещата станаха много по-сложни. Следвахме логиката и технологиите, които измислихме, станаха реалност, когато ги внедрихме за клиентите, защото имаха много смисъл. Ще ви кажа защо това е така.
API Gateway всъщност има способността да интегрира страхотни скриптове, които могат да действат като крайни точки за разработчиците на UI. Те преобразуваха всеки от тези скриптове по такъв начин, че след извършване на промени да могат да ги внедрят в производствени и след това в потребителски устройства, и всички тези промени бяха синхронизирани с крайни точки, които се изпълняваха в API шлюза.
Това обаче повтори проблема със създаването на нов монолит, при който API услугата беше претоварена с код по такъв начин, че възникнаха различни сценарии за неизправност. Например, някои крайни точки бяха премахнати или скриптове произволно генерираха толкова много версии на нещо, че версиите заеха цялата налична памет на API услугата.
Логично беше да вземем тези крайни точки и да ги изтеглим от API услугата. За да направим това, създадохме Node.js компоненти, които се изпълняват като малки приложения в Docker контейнери. Това ни позволи да изолираме всички проблеми и сривове, причинени от тези възлови приложения.
Цената на тези промени е доста голяма и се състои от следните фактори:
- Инструменти за производителност. Управлението на нови технологии изискваше нови инструменти, тъй като екипът на потребителския интерфейс, използвайки много добри скриптове за създаване на ефективен модел, не трябваше да отделя много време за управление на инфраструктурата, те трябваше само да напишат скриптове и да проверят тяхната функционалност.
Вникване и сортиране на възможностите – ключов пример са новите инструменти, необходими за разкриване на информация за драйверите за производителност. Беше необходимо да се знае колко е зает процесорът, как се използва паметта и събирането на тази информация изискваше различни инструменти. - Фрагментиране на базови изображения - простият базов AMI стана по-фрагментиран и специализиран.
- Управление на възли. Няма налична готова архитектура или технология, която да ви позволява да управлявате възли в облака, затова създадохме Titus, платформа за управление на контейнери, която осигурява мащабируемо и надеждно внедряване на контейнери и облачна интеграция с Amazon AWS.
- Дублиране на библиотека или платформа. Предоставянето на нови технологии със същата основна функционалност на платформата изисква дублирането й в базирани на облак инструменти за разработчици Node.js.
- Крива на обучение и индустриален опит. Въвеждането на нови технологии неизбежно създава нови предизвикателства, които трябва да бъдат преодолени и от които да се учим.
По този начин не можехме да се ограничим до един „павиран път“ и трябваше постоянно да изграждаме нови начини за напредване на нашите технологии. За да намалим разходите, ограничихме централизираната поддръжка и се фокусирахме върху JVM, новите възли и Docker. Дадохме приоритет на ефективното въздействие, информирахме екипите за цената на техните решения и ги насърчихме да търсят начини за повторно използване на решенията с голямо въздействие, които вече бяха разработили. Използвахме този подход, когато превеждахме услугата на чужди езици, за да доставим продукта на международни клиенти. Примерите включват сравнително прости клиентски библиотеки, които могат да бъдат генерирани автоматично, така че е доста лесно да се създаде версия на Python, версия на Ruby, версия на Java и т.н.
Непрекъснато търсихме възможности да използваме доказани технологии, доказали се на едно място и в други подобни ситуации.
Нека поговорим за последния елемент - промени или вариации. Вижте как консумацията на нашия продукт варира неравномерно по дни от седмицата и по часове през деня. Може да се каже, че 9 сутринта е най-трудното време за Netflix, когато натоварването на системата достига своя максимум.
Как можем да постигнем висока скорост на внедряване на софтуерни иновации, тоест непрекъснато да правим нови промени в системата, без да причиняваме прекъсвания в предоставянето на услуги и без да създаваме неудобства на нашите клиенти? Netflix постигна това чрез използването на Spinnaker, нова глобална облачна платформа за управление и непрекъснато доставяне (CD).
Критично, Spinnaker е проектиран да интегрира нашите най-добри практики, така че докато внедряваме компоненти в производството, да можем да интегрираме изхода директно в нашата технология за доставяне на медии.
Успяхме да включим две технологии в нашия тръбопровод за доставка, които ценим високо: автоматизиран канаричен анализ и поетапно внедряване. Canary анализът означава, че насочваме струйка трафик към новата версия на кода и прекарваме останалата част от производствения трафик през старата версия. След това проверяваме как новият код се справя със задачата - по-добре или по-зле от съществуващия.
Поетапното внедряване означава, че ако внедряването в един регион има проблеми, преминаваме към внедряване в друг регион. В този случай горепосоченият контролен списък трябва да бъде включен в производствения процес. Ще ви спестя малко време и ще ви препоръчам да разгледате предишната ми лекция, Инженеринг на глобални операции на Netflix в облака, ако се интересувате да се потопите по-дълбоко в тази тема. Видеозаписът на речта може да видите, като последвате връзката в долната част на слайда.
В края на разговора ще говоря накратко за организацията и архитектурата на Netflix. В самото начало имахме схема, наречена Electronic Delivery, която беше първата версия на NRDP 1.x медийно поточно предаване. Терминът „backstream“ може да се използва тук, тъй като първоначално потребителят можеше да изтегли само съдържание за по-късно възпроизвеждане на устройството. Първата платформа за дигитална доставка на Netflix през 2009 г. изглеждаше по този начин.
Потребителското устройство съдържаше приложението Netflix, което се състоеше от UI интерфейс, модули за сигурност, активиране на услугата и възпроизвеждане, базирано на платформата NRDP - Netflix Ready Device Platform.
По това време потребителският интерфейс беше много прост. Той съдържа това, което се нарича Queque Reader и потребителят ще отиде на сайта, за да добави нещо към Queque и след това ще види добавеното съдържание на своето устройство. Положителното беше, че предният екип и задният екип принадлежаха към една и съща организация за електронна доставка и имаха близки работни отношения. Полезният товар е създаден въз основа на XML. В същото време беше създаден Netflix API за бизнеса с DVD, което насърчи приложенията на трети страни да насочват трафик към нашата услуга.
Въпреки това API на Netflix беше добре подготвен, за да ни помогне с иновативен потребителски интерфейс, съдържащ метаданни за цялото съдържание, информация за наличните филми, което създаде възможност за генериране на списъци за гледане. Имаше общ REST API, базиран на схемата JSON, HTTP код за отговор, същият, който се използва в съвременната архитектура, и OAuth модел за сигурност, което беше това, което се изискваше по това време за приложение от предния край. Това направи възможно преминаването от публичен модел на доставка на поточно съдържание към частен.
Проблемът с прехода беше фрагментацията, тъй като сега нашата система управляваше две услуги, базирани на напълно различни принципи на работа - едната на Rest, JSON и OAuth, другата на RPC, XML и механизъм за сигурност на потребителя, базиран на системата за токени NTBA. Това беше първата хибридна архитектура.
По същество имаше защитна стена между нашите два екипа, защото първоначално API не се мащабира много добре с NCCP и това доведе до търкания между екипите. Разликите бяха в услугите, протоколите, схемите, модулите за сигурност и разработчиците често трябваше да превключват между напълно различни контексти.
В тази връзка имах разговор с един от старшите инженери на компанията, на когото зададох въпроса: „Каква трябва да бъде правилната дългосрочна архитектура?“ и той зададе контра въпроса: „Вие вероятно сте по-загрижени относно организационните последствия - какво се случва, ако интегрираме тези неща и те развалят това, което сме се научили да правим добре? Този подход е много подходящ за закона на Конуей: "Организациите, които проектират системи, са ограничени от дизайн, който възпроизвежда комуникационната структура на тази организация." Това е много абстрактно определение, така че предпочитам по-конкретно: „Всеки софтуер отразява организационната структура, която го е създала.“ Ето любимия ми цитат от Ерик Реймънд: "Ако имате четири екипа от разработчици, работещи върху компилатор, ще получите компилатор с четири прохода." Е, Netflix има четириходов компилатор и така работим.
Можем да кажем, че в този случай опашката маха кучето. Нашият първи приоритет не е решението, а организацията; организацията е тази, която движи архитектурата, която имаме. Постепенно от смесица от услуги преминахме към архитектура, която нарекохме Blade Runner, защото тук говорим за крайни услуги и способността на NCCP да бъде отделена и интегрирана директно в Zuul проксито, API шлюза и съответната функционалност „парчета“ са превърнати в нови микроуслуги с по-усъвършенствани функции за сигурност, повторение, сортиране на данни и др.
По този начин може да се каже, че структурите на отделите и динамиката на компанията играят важна роля при оформянето на системния дизайн и са фактор, който насърчава или възпрепятства промяната. Архитектурата на микроуслугите е сложна и органична и нейното здраве се основава на дисциплина и въведен хаос.
Малко реклама
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за
Източник: www.habr.com