Без сървър не става въпрос за физическо отсъствие на сървъри. Това не е убиец на контейнери или преминаваща тенденция. Това е нов подход за изграждане на системи в облака. В днешната статия ще се докоснем до архитектурата на приложенията без сървър, нека видим каква роля играят доставчикът на услуги без сървър и проектите с отворен код. И накрая, нека поговорим за проблемите с използването на Serverless.
Искам да напиша сървърна част на приложение (или дори онлайн магазин). Това може да е чат, услуга за публикуване на съдържание или инструмент за балансиране на натоварването. Във всеки случай ще има много главоболия: ще трябва да подготвите инфраструктурата, да определите зависимостите на приложението и да помислите за операционната система на хоста. След това ще трябва да актуализирате малки компоненти, които не засягат работата на останалата част от монолита. Е, нека не забравяме мащабирането при натоварване.
Ами ако вземем ефимерни контейнери, в които необходимите зависимости вече са предварително инсталирани, а самите контейнери са изолирани един от друг и от хост ОС? Ще разделим монолита на микроуслуги, всяка от които може да се актуализира и мащабира независимо от другите. Поставяйки кода в такъв контейнер, мога да го стартирам във всяка инфраструктура. Вече по-добре.
Ами ако не искате да конфигурирате контейнери? Не искам да мисля за мащабиране на приложението. Не искам да плащам за неработещи контейнери, когато натоварването на услугата е минимално. Искам да напиша код. Фокусирайте се върху бизнес логиката и пуснете продуктите на пазара със скоростта на светлината.
Такива мисли ме насочиха към изчисления без сървър. Serverless в случая означава не физическата липса на сървъри, а липсата на главоболия за управление на инфраструктурата.
Идеята е, че логиката на приложението е разделена на независими функции. Те имат събитийна структура. Всяка функция изпълнява една „микрозадача“. Всичко, което се изисква от разработчика, е да зареди функциите в конзолата, предоставена от облачния доставчик, и да ги свърже с източниците на събития. Кодът ще бъде изпълнен при поискване в автоматично подготвен контейнер и аз ще платя само времето за изпълнение.
Нека да видим как ще изглежда процесът на разработка на приложения сега.
От страна на разработчика
По-рано започнахме да говорим за приложение за онлайн магазин. При традиционния подход основната логика на системата се изпълнява от монолитно приложение. И сървърът с приложението работи постоянно, дори и да няма натоварване.
За да преминем към сървър без сървър, ние разделяме приложението на микрозадачи. Ние пишем собствена функция за всеки от тях. Функциите са независими една от друга и не съхраняват информация за състоянието (без състояние). Те дори могат да бъдат написани на различни езици. Ако някой от тях „падне“, цялото приложение няма да спре. Архитектурата на приложението ще изглежда така:
Разделянето на функции в Serverless е подобно на работата с микроуслуги. Но една микроуслуга може да изпълнява няколко задачи и една функция в идеалния случай трябва да изпълнява една. Нека си представим, че задачата е да се съберат статистически данни и да се покажат по искане на потребителя. При подхода на микроуслугата дадена задача се изпълнява от една услуга с две входни точки: писане и четене. При изчисленията без сървър това ще бъдат две различни функции, които не са свързани една с друга. Разработчикът спестява изчислителни ресурси, ако например статистическите данни се актуализират по-често, отколкото се изтеглят.
Функциите без сървър трябва да се изпълняват за кратък период от време (таймаут), който се определя от доставчика на услугата. Например за AWS времето за изчакване е 15 минути. Това означава, че дълготрайните функции ще трябва да бъдат променени, за да отговарят на изискванията - това е, което отличава Serverless от други популярни технологии днес (контейнери и платформа като услуга).
Присвояваме събитие на всяка функция. Събитието е тригер за действие:
събитие
Действието, което функцията изпълнява
Изображение на продукта е качено в хранилището.
Компресирайте изображението и го качете в директория
Адресът на физическия магазин е актуализиран в базата данни
Заредете ново местоположение в картите
Клиентът плаща за стоките
Започнете обработката на плащанията
Събитията могат да бъдат HTTP заявки, поточно предаване на данни, опашки от съобщения и т.н. Източници на събития са промени или възникване на данни. Освен това функциите могат да се задействат от таймер.
Архитектурата беше разработена и приложението почти стана без сървър. След това отиваме при доставчика на услуги.
От страна на доставчика
Обикновено изчисленията без сървър се предлагат от доставчици на облачни услуги. Те се наричат по различен начин: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Ние ще използваме услугата чрез конзолата на доставчика или личния акаунт. Функционалният код може да бъде изтеглен по един от следните начини:
- пишете код във вградени редактори чрез уеб конзолата,
- изтеглете архива с кода,
- работа с публични или частни git хранилища.
Тук настройваме събитията, които извикват функцията. Наборите от събития може да се различават за различните доставчици.
Доставчикът изгради и автоматизира системата Function as a Service (FaaS) на своята инфраструктура:
- Кодът на функцията завършва в хранилището от страната на доставчика.
- Когато възникне събитие, контейнерите с подготвена среда се разполагат автоматично на сървъра. Всеки екземпляр на функция има свой собствен изолиран контейнер.
- От хранилището функцията се изпраща до контейнера, изчислява се и връща резултата.
- Броят на паралелните събития расте - расте броят на контейнерите. Системата се мащабира автоматично. Ако потребителите нямат достъп до функцията, тя ще бъде неактивна.
- Доставчикът задава времето на празен ход за контейнерите - ако през това време функции не се появят в контейнера, той се унищожава.
По този начин получаваме Serverless от кутията. Ние ще платим за услугата, като използваме модела pay-as-you-go и само за тези функции, които се използват, и само за времето, когато са били използвани.
За да запознаят разработчиците с услугата, доставчиците предлагат до 12 месеца безплатно тестване, но ограничават общото време за изчисление, броя на заявките на месец, средствата или консумацията на енергия.
Основното предимство на работата с доставчик е възможността да не се притеснявате за инфраструктурата (сървъри, виртуални машини, контейнери). От своя страна, доставчикът може да внедри FaaS както със собствени разработки, така и с инструменти с отворен код. Нека поговорим за тях по-нататък.
От страна на отворения код
Общността с отворен код работи активно върху инструменти без сървър през последните няколко години. Най-големите играчи на пазара също допринасят за развитието на безсървърни платформи:
- Google предлага на разработчиците своя инструмент с отворен код - . IBM, RedHat, Pivotal и SAP участваха в разработването му;
- IBM работи на платформа без сървър , който след това става проект на фондация Apache;
- Microsoft частично отвори кода на платформата .
Текат разработки и в посока безсървърни рамки. и разположени в предварително подготвени Kubernetes клъстери, работи както с Kubernetes, така и с Docker Swarm. Рамката действа като вид контролер - при поискване тя подготвя среда за изпълнение вътре в клъстера, след което стартира функция там.
Рамките оставят място за конфигуриране на инструмента според вашите нужди. Така че в Kubeless разработчикът може да конфигурира времето за изчакване на изпълнението на функцията (стойността по подразбиране е 180 секунди). Fission, в опит да разреши проблема със студения старт, предлага някои контейнери да работят през цялото време (въпреки че това води до разходи за прекъсване на ресурсите). А OpenFaaS предлага набор от тригери за всеки вкус и цвят: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs и други.
Инструкции за започване можете да намерите в официалната документация на рамките. Работата с тях изисква малко повече умения, отколкото при работа с доставчик - това е поне възможността да стартирате Kubernetes клъстер чрез CLI. Включете най-много други инструменти с отворен код (например Kafka queue manager).
Независимо как работим с Serverless – чрез доставчик или с отворен код, ние ще получим редица предимства и недостатъци на Serverless подхода.
От гледна точка на предимствата и недостатъците
Serverless развива идеите за контейнерна инфраструктура и подход на микроуслуга, при който екипите могат да работят в многоезичен режим, без да са обвързани с една платформа. Изграждането на система е опростено и грешките се коригират по-лесно. Архитектурата на микросервизите ви позволява да добавяте нова функционалност към системата много по-бързо, отколкото в случай на монолитно приложение.
Без сървър намалява още повече времето за разработка, което позволява на разработчика да се съсредоточи единствено върху бизнес логиката и кодирането на приложението. В резултат на това времето за пускане на пазара на разработките се намалява.
Като бонус получаваме автоматично мащабиране за натоварване, и плащаме само за използваните ресурси и само в момента, в който се използват.
Като всяка технология, Serverless има недостатъци.
Например, такъв недостатък може да бъде времето за студен старт (средно до 1 секунда за езици като JavaScript, Python, Go, Java, Ruby).
От една страна, в действителност времето за студен старт зависи от много променливи: езикът, на който е написана функцията, броят на библиотеките, количеството код, комуникацията с допълнителни ресурси (същите бази данни или сървъри за удостоверяване). Тъй като разработчикът контролира тези променливи, той може да намали времето за стартиране. Но от друга страна, разработчикът не може да контролира времето за стартиране на контейнера - всичко зависи от доставчика.
Студеният старт може да се превърне в топъл старт, когато дадена функция използва повторно контейнер, стартиран от предишно събитие. Тази ситуация ще възникне в три случая:
- ако клиентите често използват услугата и броят на обажданията към функцията се увеличава;
- ако доставчикът, платформата или рамката ви позволяват да поддържате някои контейнери работещи през цялото време;
- ако разработчикът изпълнява функции на таймер (да кажем на всеки 3 минути).
За много приложения студеният старт не е проблем. Тук трябва да надграждате вида и задачите на услугата. Забавянето на стартиране от секунда не винаги е критично за бизнес приложение, но може да стане критично за медицински услуги. В този случай подходът без сървър вероятно вече няма да е подходящ.
Следващият недостатък на Serverless е краткият живот на функцията (изчакване, през което функцията трябва да се изпълни).
Но ако трябва да работите с дълготрайни задачи, можете да използвате хибридна архитектура - комбинирайте Serverless с друга технология.
Не всички системи ще могат да работят с помощта на схемата без сървър.
Някои приложения все още ще съхраняват данни и състояние по време на изпълнение. Някои архитектури ще останат монолитни, а някои функции ще имат дълъг живот. Въпреки това (като облачните технологии и след това контейнерите), Serverless е технология с голямо бъдеще.
В този смисъл бих искал плавно да премина към въпроса за използването на подхода без сървър.
От страна на приложението
За 2018 г. процентът на използване без сървър . Сред компаниите, които вече внедриха технологията в услугите си, са пазарни гиганти като Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. В същото време трябва да разберете, че Serverless не е панацея, а инструмент за решаване на определен набор от проблеми:
- Намалете времето на престой на ресурсите. Няма нужда постоянно да поддържате виртуална машина за услуги, които имат малко обаждания.
- Обработвайте данни в движение. Компресирайте снимки, изрязвайте фонове, променяйте видео кодирането, работете с IoT сензори, извършвайте математически операции.
- „Слепете“ други услуги заедно. Git хранилище с вътрешни програми, чат бот в Slack с Jira и календар.
- Балансирайте натоварването. Нека разгледаме по-отблизо тук.
Да кажем, че има услуга, която привлича 50 души. Под него има виртуална машина със слаб хардуер. От време на време натоварването на услугата се увеличава значително. Тогава слабият хардуер не може да се справи.
Можете да включите балансьор в системата, който ще разпредели натоварването, да речем, между три виртуални машини. На този етап не можем да предвидим точно натоварването, така че поддържаме определено количество ресурси, работещи „в резерв“. И ние надплащаме за престой.
В такава ситуация можем да оптимизираме системата чрез хибриден подход: оставяме една виртуална машина зад балансиращото натоварване и поставяме връзка към крайната точка без сървър с функции. Ако натоварването надхвърли прага, балансиращият стартира функционални екземпляри, които поемат част от обработката на заявката.
По този начин Serverless може да се използва, когато е необходимо да се обработват голям брой заявки не твърде често, но интензивно. В този случай изпълнението на няколко функции за 15 минути е по-изгодно от поддържането на виртуална машина или сървър през цялото време.
С всички предимства на изчисленията без сървър, преди внедряването, първо трябва да оцените логиката на приложението и да разберете какви проблеми може да реши без сървър в конкретен случай.
Без сървър и Selectel
В Selectel вече сме чрез нашия контролен панел. Сега изграждаме собствена платформа FaaS. Ние искаме разработчиците да могат да решават проблемите си, като използват безсървърно чрез удобен, гъвкав интерфейс.
Ако имате идеи каква трябва да бъде идеалната FaaS платформа и как искате да използвате Serverless във вашите проекти, споделете ги в коментарите. Ние ще вземем предвид вашите желания при разработването на платформата.
Използвани материали в статията:
Източник: www.habr.com