Тази статия съдържа някои общи модели, които да помогнат на инженерите да работят с широкомащабни услуги, достъпни от милиони потребители.
Според опита на автора това не е изчерпателен списък, но наистина ефективен съвет. И така, да започваме.
Преведено с поддръжка .
Първо ниво
Изброените по-долу мерки са относително лесни за прилагане, но имат голямо въздействие. Ако не сте ги опитвали преди, ще се изненадате от значителните подобрения.
Инфраструктурата като код
Първата част от съвета е да се внедри инфраструктурата като код. Това означава, че трябва да имате програмен начин за разгръщане на цялата инфраструктура. Звучи сложно, но всъщност говорим за следния код:
Внедряване на 100 виртуални машини
- с Ubuntu
- 2 GB RAM всяка
- те ще имат следния код
- с тези параметри
Можете да проследявате промените във вашата инфраструктура и бързо да се връщате към тях с помощта на контрол на версиите.
Модернистът в мен казва, че можете да използвате Kubernetes/Docker, за да направите всичко по-горе, и той е прав.
Освен това можете да осигурите автоматизация с помощта на Chef, Puppet или Terraform.
Непрекъсната интеграция и доставка
За да създадете мащабируема услуга, е важно да имате конвейер за изграждане и тестване за всяка заявка за изтегляне. Дори ако тестът е много прост, той поне ще гарантира, че кодът, който внедрявате, се компилира.
Всеки път на този етап отговаряте на въпроса: моето събрание ще се компилира и ще премине тестове, валидно ли е? Това може да изглежда като ниска летва, но решава много проблеми.
Няма нищо по-красиво от това да видиш тези кърлежи
За тази технология можете да оцените Github, CircleCI или Jenkins.
Балансери на натоварването
И така, искаме да стартираме балансьор на натоварването, за да пренасочи трафика и да осигури еднакво натоварване на всички възли или услугата да продължи в случай на повреда:
Устройството за балансиране на натоварването обикновено върши добра работа за разпределяне на трафика. Най-добрата практика е да балансирате, така че да нямате нито една точка на отказ.
Обикновено балансьорите на натоварването се конфигурират в облака, който използвате.
RayID, ID на корелация или UUID за заявки
Срещали ли сте някога грешка в приложението със съобщение като това: "Нещо се обърка. Запазете този идентификатор и го изпратете на нашия екип за поддръжка"?
Уникален идентификатор, ID на корелация, RayID или някоя от вариациите е уникален идентификатор, който ви позволява да проследявате заявка през целия й жизнен цикъл. Това ви позволява да проследявате целия път на заявката в регистрационните файлове.
Потребителят прави заявка към система A, след това A се свързва с B, която се свързва със C, съхранява я в X и след това заявката се връща на A
Ако се свържете отдалечено с виртуални машини и се опитате да проследите пътя на заявката (и ръчно да корелирате кои повиквания се правят), ще полудеете. Наличието на уникален идентификатор прави живота много по-лесен. Това е едно от най-простите неща, които можете да направите, за да спестите време, докато услугата ви расте.
Средно ниво
Съветите тук са по-сложни от предишните, но правилните инструменти улесняват задачата, осигурявайки възвръщаемост на инвестицията дори за малки и средни компании.
Централизирано регистриране
Честито! Разположихте 100 виртуални машини. На следващия ден главният изпълнителен директор идва и се оплаква от грешка, която е получил, докато е тествал услугата. Той съобщава съответния идентификатор, за който говорихме по-горе, но ще трябва да прегледате регистрационните файлове на 100 машини, за да намерите тази, която е причинила срива. И трябва да се намери преди утрешната презентация.
Въпреки че това звучи като забавно приключение, най-добре е да се уверите, че имате възможност да търсите във всички списания на едно място. Реших проблема с централизирането на регистрационни файлове, използвайки вградената функционалност на стека ELK: той поддържа събиране на регистрационни файлове с възможност за търсене. Това наистина ще помогне за решаването на проблема с намирането на конкретен дневник. Като бонус можете да създавате диаграми и други подобни забавни неща.
Функционалност на ELK стека
Агенти за наблюдение
Сега, когато услугата ви е готова и работи, трябва да се уверите, че работи гладко. Най-добрият начин да направите това е да стартирате няколко агенти, които работят паралелно и проверяват дали работи и се изпълняват основни операции.
На този етап проверявате това работещата компилация се чувства добре и работи добре.
За малки до средни проекти препоръчвам Postman за наблюдение и документиране на API. Но като цяло просто искате да сте сигурни, че имате начин да разберете кога е възникнало прекъсване и да бъдете уведомени своевременно.
Автоматично мащабиране в зависимост от натоварването
Много е просто. Ако имате заявки за обслужване на виртуална машина и тя наближава 80% използване на паметта, можете или да увеличите нейните ресурси, или да добавите още виртуални машини към клъстера. Автоматичното изпълнение на тези операции е отлично за еластични промени на мощността при натоварване. Но винаги трябва да внимавате колко пари харчите и да поставяте разумни граници.
С повечето облачни услуги можете да го конфигурирате за автоматично мащабиране, като използвате повече сървъри или по-мощни сървъри.
Експериментална система
Добър начин за безопасно пускане на актуализации е да можете да тествате нещо за 1% от потребителите за един час. Вие, разбира се, сте виждали подобни механизми в действие. Например Facebook показва части от аудиторията с различен цвят или променя размера на шрифта, за да види как потребителите възприемат промените. Това се нарича A/B тестване.
Дори пускането на нова функция може да започне като експеримент и след това да се определи как да бъде пусната. Вие също така получавате способността да „запомняте“ или променяте конфигурацията в движение въз основа на функцията, която причинява влошаване на вашата услуга.
ниво за напреднали
Ето съвети, които са доста трудни за изпълнение. Вероятно ще ви трябват малко повече ресурси, така че малка или средна компания трудно ще се справи с това.
Синьо-зелени внедрявания
Това е, което наричам "Erlang" начин на разгръщане. Erlang стана широко използван, когато се появиха телефонните компании. Софтуерните суичове започнаха да се използват за маршрутизиране на телефонни разговори. Основната цел на софтуера на тези комутатори беше да не прекъсва повикванията по време на системни надстройки. Erlang има хубав начин за зареждане на нов модул, без да срине предишния.
Тази стъпка зависи от наличието на балансьор на натоварването. Нека си представим, че имате версия N на вашия софтуер и след това искате да внедрите версия N+1.
Ви бихме могли просто спрете услугата и пуснете следващата версия във време, което работи за вашите потребители и получете известно време на престой. Но да предположим, че имате наистина строги условия на SLA. Така че SLA 99,99% означава, че можете да преминете офлайн само с 52 минути годишно.
Ако наистина искате да постигнете такива показатели, имате нужда от две внедрявания едновременно:
- този, който е точно сега (N);
- следваща версия (N+1).
Казвате на балансиращото натоварване да пренасочи процент от трафика към новата версия (N+1), докато активно наблюдавате за регресии.
Тук имаме зелено N внедряване, което работи добре. Опитваме се да преминем към следващата версия на това внедряване
Първо изпращаме наистина малък тест, за да видим дали нашето N+1 внедряване работи с малко количество трафик:
И накрая, имаме набор от автоматизирани проверки, които в крайна сметка изпълняваме, докато внедряването приключи. Ако ти много много внимавайте, можете също да запазите своето N внедряване завинаги за бързо връщане назад в случай на лоша регресия:
Ако искате да преминете към още по-напреднало ниво, оставете всичко в синьо-зеленото внедряване да работи автоматично.
Откриване на аномалии и автоматично смекчаване
Като се има предвид, че имате централизирано регистриране и добро събиране на регистрационни файлове, вече можете да си поставите по-високи цели. Например, проактивно прогнозирайте неуспехите. Функциите се проследяват на монитори и в регистрационни файлове и се изграждат различни диаграми - и можете да предвидите предварително какво ще се обърка:
След като бъдат открити аномалии, вие започвате да изследвате някои от уликите, които предоставя услугата. Например, пик в натоварването на процесора може да означава, че твърд диск се проваля, докато скок в заявките може да означава, че трябва да увеличите мащаба. Този вид статистически данни ви позволяват да направите услугата проактивна.
С тези прозрения можете да мащабирате във всяко измерение и проактивно и реактивно да променяте характеристиките на машини, бази данни, връзки и други ресурси.
Това е всичко!
Този списък с приоритети ще ви спести много проблеми, ако издигате облачна услуга.
Авторът на оригиналната статия кани читателите да оставят своите коментари и да правят промени. Статията се разпространява като отворен код, заявки за изтегляне от автора .
Какво още да прочетете по темата:
Източник: www.habr.com