Без сервер не е за физичко отсуство на сервери. Ова не е убиец на контејнери или минлив тренд. Ова е нов пристап за градење системи во облакот. Во денешната статија ќе ја допреме архитектурата на апликациите без сервер, ајде да видиме каква улога играат давателот на услуги без сервер и проектите со отворен код. Конечно, да разговараме за прашањата за користење без сервер.
Сакам да напишам сервер дел од апликација (или дури и онлајн продавница). Ова може да биде разговор, услуга за објавување содржина или балансирач на оптоварување. Во секој случај, ќе има многу главоболки: ќе треба да ја подготвите инфраструктурата, да ги одредите зависностите на апликациите и да размислите за оперативниот систем на домаќинот. Потоа ќе треба да ажурирате мали компоненти кои не влијаат на работата на остатокот од монолитот. Па, да не заборавиме на скалирање под оптоварување.
Што ако земеме ефемерни контејнери, во кои потребните зависности се веќе претходно инсталирани, а самите контејнери се изолирани едни од други и од оперативниот систем домаќин? Монолитот ќе го поделиме на микросервиси, од кои секоја може да се ажурира и скалира независно од другите. Со ставање на кодот во таков контејнер, можам да го стартувам на која било инфраструктура. Веќе подобро.
Што ако не сакате да ги конфигурирате контејнерите? Не сакам да размислувам за скалирање на апликацијата. Не сакам да плаќам за неактивен контејнери кога оптоварувањето на услугата е минимално. Сакам да напишам код. Фокусирајте се на деловната логика и носете производи на пазарот со брзина на светлината.
Таквите мисли ме доведоа до пресметување без сервер. Без сервер во овој случај значи не физичкото отсуство на сервери, туку отсуството на главоболки за управување со инфраструктурата.
Идејата е дека логиката на апликацијата е поделена на независни функции. Тие имаат структура на настани. Секоја функција извршува една „микрозадача“. Сè што е потребно од развивачот е да ги вчита функциите во конзолата обезбедена од давателот на облакот и да ги поврзе со изворите на настани. Кодот ќе се изврши на барање во автоматски подготвен контејнер, а јас ќе платам само за времето на извршување.
Ајде да видиме како ќе изгледа сега процесот на развој на апликации.
Од страната на инвеститорот
Претходно почнавме да зборуваме за апликација за онлајн продавница. Во традиционалниот пристап, главната логика на системот се изведува со монолитна апликација. И серверот со апликацијата постојано работи, дури и ако нема оптоварување.
За да се префрлиме на без сервер, ја разделуваме апликацијата на микрозадачи. За секоја од нив пишуваме своја функција. Функциите се независни една од друга и не складираат информации за состојбата (без државјанство). Тие дури може да бидат напишани на различни јазици. Ако еден од нив „падне“, целата апликација нема да запре. Архитектурата на апликацијата ќе изгледа вака:
Поделбата на функции во без сервер е слична на работата со микросервиси. Но, микросервис може да изврши неколку задачи, а функцијата идеално треба да изврши една. Да замислиме дека задачата е да се соберат статистики и да се прикажат на барање на корисникот. Во пристапот на микросервис, задача врши една услуга со две влезни точки: пишување и читање. Во компјутерите без сервер, ова ќе бидат две различни функции кои не се поврзани една со друга. Програмерот зачувува компјутерски ресурси ако, на пример, статистиката се ажурира почесто отколку што се презема.
Функциите без сервер мора да се извршат во краток временски период (тајмаут), што го одредува давателот на услугата. На пример, за AWS тајмаутот е 15 минути. Ова значи дека долготрајните функции ќе треба да се променат за да одговараат на барањата - тоа е она што го разликува Serverless од другите популарни технологии денес (контејнери и платформа како услуга).
Доделуваме настан на секоја функција. Настанот е активирач за дејство:
Настан
Дејството што го врши функцијата
Сликата на производот е поставена во складиштето.
Компресирајте ја сликата и поставете ја во директориум
Адресата на физичката продавница е ажурирана во базата на податоци
Вчитајте нова локација на мапи
Клиентот плаќа за стоката
Започнете со обработка на плаќање
Настаните може да бидат барања за HTTP, стриминг податоци, редици за пораки и така натаму. Изворите на настани се промени или појави на податоци. Покрај тоа, функциите може да се активираат со тајмер.
Архитектурата беше разработена, а апликацијата речиси стана без сервер. Следно, одиме кај давателот на услугата.
Од страната на давателот
Вообичаено, компјутерите без сервер се нудат од давателите на облак услуги. Тие се нарекуваат поинаку: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Ќе ја користиме услугата преку конзолата или личната сметка на давателот. Кодот на функцијата може да се преземе на еден од следниве начини:
- пишувајте код во вградените уредници преку веб-конзолата,
- преземете ја архивата со кодот,
- работа со јавни или приватни git складишта.
Овде ги поставуваме настаните што ја повикуваат функцијата. Збирките на настани може да се разликуваат за различни провајдери.
Давателот го изгради и автоматизираше системот Функција како услуга (FaaS) на својата инфраструктура:
- Кодот на функцијата завршува во складиштето на страната на давателот.
- Кога ќе се случи настан, контејнерите со подготвена околина автоматски се распоредуваат на серверот. Секој функционален пример има свој изолиран контејнер.
- Од складиштето, функцијата се испраќа до контејнерот, се пресметува и го враќа резултатот.
- Расте бројот на паралелни настани - расте бројот на контејнери. Системот автоматски се зголемува. Доколку корисниците не пристапат до функцијата, таа ќе биде неактивна.
- Давателот го поставува времето на мирување за контејнерите - ако за тоа време функциите не се појават во контејнерот, тој се уништува.
На овој начин го вадиме без сервер од кутијата. Ќе плаќаме за услугата користејќи го моделот pay-as-you-go и само за оние функции што се користат и само за времето кога биле користени.
За да ги запознаат програмерите со услугата, провајдерите нудат до 12 месеци бесплатно тестирање, но го ограничуваат вкупното време на пресметување, бројот на барања месечно, средствата или потрошувачката на енергија.
Главната предност на работата со провајдер е можноста да не се грижите за инфраструктурата (сервери, виртуелни машини, контејнери). Од своја страна, давателот може да го имплементира FaaS и со користење на сопствените случувања и со користење на алатки со отворен код. Ајде да зборуваме за нив понатаму.
Од страната со отворен код
Заедницата со отворен код активно работи на алатки без сервер во последните неколку години. Најголемите играчи на пазарот, исто така, придонесуваат за развој на платформи без сервери:
- Google им нуди на програмерите својата алатка со отворен код - . Во неговиот развој учествуваа IBM, RedHat, Pivotal и SAP;
- IBM, работеше на платформа без сервер , кој потоа стана проект на Фондацијата Апачи;
- Мајкрософт делумно го отвори кодот на платформата .
Развојот е во тек и во насока на рамки без сервери. и распоредени во претходно подготвени кластери Кубернетес, работи и со Kubernetes и со Docker Swarm. Рамката делува како еден вид контролер - по барање, подготвува животна средина за време на работа во кластерот, а потоа стартува функција таму.
Рамките оставаат простор за конфигурирање на алатката за да одговара на вашите потреби. Значи, во Kubeless, развивачот може да го конфигурира истекот на извршувањето на функцијата (стандардната вредност е 180 секунди). Fission, во обид да се реши проблемот со ладното стартување, предлага некои контејнери постојано да работат (иако тоа повлекува трошоци за прекин на ресурсите). И OpenFaaS нуди збир на предизвикувачи за секој вкус и боја: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs и други.
Упатствата за почеток може да се најдат во официјалната документација на рамки. Работата со нив бара да имате малку повеќе вештини отколку кога работите со провајдер - ова е барем способност да се стартува кластерот Kubernetes преку CLI. Најмногу, вклучете други алатки со отворен код (на пример, менаџерот на редици Кафка).
Без оглед на тоа како работиме со Serverless - преку провајдер или користејќи отворен код, ќе добиеме голем број на предности и недостатоци на пристапот без сервер.
Од гледна точка на предности и недостатоци
Без сервер ги развива идеите за контејнерска инфраструктура и пристап за микросервис, во кој тимовите можат да работат во повеќејазичен режим без да бидат врзани за една платформа. Изградбата на систем е поедноставена и грешките полесно се поправаат. Микросервисната архитектура ви овозможува да додадете нова функционалност на системот многу побрзо отколку во случај на монолитна апликација.
Без сервер го намалува времето за развој уште повеќе, овозможувајќи му на развивачот да се фокусира исклучиво на деловната логика и кодирање на апликацијата. Како резултат на тоа, времето за пазар за развој е намалено.
Како бонус, добиваме автоматско скалирање за оптоварување, а ние плаќаме само за искористените ресурси и само во времето кога тие се користат.
Како и секоја технологија, без сервер има недостатоци.
На пример, таков недостаток може да биде времето на ладно започнување (во просек до 1 секунда за јазици како што се JavaScript, Python, Go, Java, Ruby).
Од една страна, во реалноста, времето на ладно започнување зависи од многу променливи: јазикот на кој е напишана функцијата, бројот на библиотеки, количината на код, комуникацијата со дополнителни ресурси (истите бази на податоци или сервери за автентикација). Бидејќи развивачот ги контролира овие променливи, тој може да го намали времето за стартување. Но, од друга страна, развивачот не може да го контролира времето на стартување на контејнерот - сè зависи од давателот.
Ладниот почеток може да се претвори во топол почеток кога функцијата повторно користи контејнер пуштен од претходен настан. Оваа ситуација ќе се појави во три случаи:
- ако клиентите често ја користат услугата и бројот на повици до функцијата се зголемува;
- ако провајдерот, платформата или рамката ви дозволуваат постојано да работат некои контејнери;
- ако програмерот работи функции на тајмер (да речеме на секои 3 минути).
За многу апликации, ладниот почеток не е проблем. Овде треба да се надоврзете на видот и задачите на услугата. Доцнењето на почетокот од секунда не е секогаш критично за деловна апликација, но може да стане критично за медицинските услуги. Во овој случај, пристапот без сервер веројатно повеќе нема да биде соодветен.
Следниот недостаток на Serverless е краткиот животен век на функцијата (времето за време на кое функцијата мора да се изврши).
Но, ако треба да работите со долготрајни задачи, можете да користите хибридна архитектура - комбинирајте без сервер со друга технологија.
Не сите системи ќе можат да работат користејќи ја шемата без сервер.
Некои апликации сè уште ќе складираат податоци и состојби за време на извршувањето. Некои архитектури ќе останат монолитни, а некои карактеристики ќе бидат долготрајни. Сепак (како облак технологиите, а потоа и контејнерите), Serverless е технологија со голема иднина.
Во оваа насока, би сакал непречено да се префрлам на прашањето за користење на пристапот без сервер.
Од страната на апликацијата
За 2018 година, процентот на користење без сервер . Меѓу компаниите кои веќе ја имаат имплементирано технологијата во своите услуги се пазарните гиганти како Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Во исто време, треба да разберете дека без сервер не е лек, туку алатка за решавање на одреден опсег на проблеми:
- Намалете го времето на прекин на ресурсите. Нема потреба постојано да чувате виртуелна машина за услуги кои имаат малку повици.
- Обработете ги податоците во лет. Компресирајте слики, исечете ги позадините, менувајте кодирање на видео, работете со IoT сензори, изведувајте математички операции.
- „Залепете“ други услуги заедно. Git складиште со внатрешни програми, бот за разговор во Slack со Jira и календар.
- Избалансирајте го товарот. Ајде да погледнеме подетално овде.
Да речеме дека постои услуга која привлекува 50 луѓе. Под него има виртуелна машина со слаб хардвер. Од време на време, оптоварувањето на услугата значително се зголемува. Тогаш слабиот хардвер не може да се справи.
Може да вклучите балансер во системот кој ќе го дистрибуира оптоварувањето, да речеме, низ три виртуелни машини. Во оваа фаза, не можеме точно да го предвидиме оптоварувањето, така што задржуваме одредена количина на ресурси „во резерва“. И ние преплаќаме за застој.
Во таква ситуација, можеме да го оптимизираме системот преку хибриден пристап: оставаме една виртуелна машина зад балансерот на оптоварување и ставаме врска до крајната точка без сервер со функции. Ако оптоварувањето го надмине прагот, балансерот стартува функционални инстанци кои преземаат дел од обработката на барањата.
Така, Serverless може да се користи каде што е неопходно да се обработуваат голем број барања не премногу често, но интензивно. Во овој случај, извршувањето на неколку функции за 15 минути е попрофитабилно отколку постојаното одржување на виртуелна машина или сервер.
Со сите предности на пресметувањето без сервер, пред имплементацијата, прво треба да ја процените логиката на апликацијата и да разберете кои проблеми може да ги реши без сервер во одреден случај.
Без сервер и Selectel
Во Селетел сме веќе преку нашиот контролен панел. Сега градиме сопствена FaaS платформа. Сакаме програмерите да можат да ги решат своите проблеми користејќи без сервер преку удобен, флексибилен интерфејс.
Ако имате идеи за тоа каква треба да биде идеалната платформа FaaS и како сакате да користите Serverless во вашите проекти, споделете ги во коментарите. Ќе ги земеме предвид вашите желби при развивањето на платформата.
Материјали што се користат во статијата:
Извор: www.habr.com