Сервергүй гэдэг нь серверийн физик байхгүй тухай биш юм. Энэ бол чингэлэг алуурчин эсвэл өнгөрөх хандлага биш юм. Энэ бол үүлэн дотор систем бүтээх шинэ арга юм. Өнөөдрийн нийтлэлд бид Сервергүй програмуудын архитектурын талаар ярих болно, Сервергүй үйлчилгээ үзүүлэгч болон нээлттэй эхийн төслүүд ямар үүрэг гүйцэтгэж байгааг харцгаая. Эцэст нь Serverless ашиглахтай холбоотой асуудлуудын талаар ярилцъя.
Би програмын (эсвэл онлайн дэлгүүрийн) серверийн хэсгийг бичихийг хүсч байна. Энэ нь чат, контент нийтлэх үйлчилгээ эсвэл ачаалал тэнцвэржүүлэгч байж болно. Ямар ч тохиолдолд маш их толгой өвдөх болно: та дэд бүтцийг бэлтгэх, хэрэглээний хамаарлыг тодорхойлох, хост үйлдлийн системийн талаар бодох хэрэгтэй болно. Дараа нь та цул үлдсэн хэсгийн үйл ажиллагаанд нөлөөлөхгүй жижиг бүрэлдэхүүн хэсгүүдийг шинэчлэх хэрэгтэй болно. За, ачааллын дор масштаблах тухай мартаж болохгүй.
Хэрэв бид шаардлагатай хамаарлыг урьдчилан суулгасан түр зуурын савыг авбал ямар вэ? Бид монолитийг микро үйлчилгээнд хуваах бөгөөд тэдгээр нь тус бүрийг бусдаас үл хамааран шинэчилж, өргөжүүлж болно. Кодоо ийм саванд хийснээр би ямар ч дэд бүтэц дээр ажиллуулж чадна. Аль хэдийн дээрдсэн.
Хэрэв та савыг тохируулахыг хүсэхгүй байвал яах вэ? Би програмыг томруулах талаар бодохыг хүсэхгүй байна. Үйлчилгээний ачаалал бага байхад би сул зогсолттой савны төлбөр төлөхийг хүсэхгүй байна. Би код бичмээр байна. Бизнесийн логик дээр анхаарлаа төвлөрүүлж, гэрлийн хурдаар бүтээгдэхүүнээ зах зээлд гарга.
Ийм бодол намайг сервергүй тооцоолол руу хөтөлсөн. Энэ тохиолдолд сервергүй гэсэн үг серверийн бие махбодийн хомсдол биш, харин дэд бүтцийн менежментийн толгойн өвчин байхгүй.
Хэрэглээний логик нь бие даасан функцүүдэд хуваагддаг гэсэн санаа юм. Тэд үйл явдлын бүтэцтэй байдаг. Функц бүр нэг "микро даалгавар" гүйцэтгэдэг. Хөгжүүлэгчээс шаардагдах бүх зүйл бол үүлэн үйлчилгээ үзүүлэгчийн өгсөн консол руу функцуудыг ачаалж, үйл явдлын эх сурвалжтай уялдуулах явдал юм. Код нь хүсэлтээр автоматаар бэлтгэгдсэн саванд хийгдэх бөгөөд би зөвхөн гүйцэтгэлийн хугацааг төлнө.
Одоо програм боловсруулах үйл явц ямар байхыг харцгаая.
Хөгжүүлэгчийн талаас
Өмнө нь бид онлайн дэлгүүрт зориулсан програмын талаар ярьж эхэлсэн. Уламжлалт аргын хувьд системийн үндсэн логикийг цул хэрэглээгээр гүйцэтгэдэг. Мөн програмтай сервер ачаалалгүй байсан ч байнга ажиллаж байна.
Сервергүй горимд шилжихийн тулд бид програмыг бичил даалгавар болгон хуваадаг. Бид тус бүрийн хувьд өөрсдийн функцийг бичдэг. Функцүүд нь бие биенээсээ хамааралгүй бөгөөд төрийн мэдээллийг (харьяалалгүй) хадгалдаггүй. Тэдгээрийг бүр өөр хэлээр бичсэн байж болно. Хэрэв тэдгээрийн аль нэг нь "унавал" програм бүхэлдээ зогсохгүй. Хэрэглээний архитектур нь дараах байдлаар харагдах болно.
Сервергүй горимд функцүүдэд хуваагдах нь микро үйлчилгээтэй ажиллахтай адил юм. Гэхдээ микро үйлчилгээ нь хэд хэдэн даалгаврыг гүйцэтгэх боломжтой бөгөөд функц нь хамгийн тохиромжтой нь нэгийг гүйцэтгэх ёстой. Даалгавар бол статистик мэдээллийг цуглуулж, хэрэглэгчийн хүсэлтээр харуулах явдал юм гэж төсөөлөөд үз дээ. Микро үйлчилгээний арга барилд даалгаврыг бичих, унших гэсэн хоёр нэвтрэх цэг бүхий нэг үйлчилгээ гүйцэтгэдэг. Сервергүй тооцоолоход эдгээр нь хоорондоо хамааралгүй хоёр өөр функц байх болно. Жишээлбэл, статистик мэдээлэл татагдсанаас илүү олон удаа шинэчлэгдэж байвал хөгжүүлэгч компьютерийн нөөцийг хэмнэдэг.
Сервергүй функцууд нь үйлчилгээ үзүүлэгчээс тодорхойлогддог богино хугацаанд (цаг завсарлага) гүйцэтгэгдэх ёстой. Жишээлбэл, AWS-ийн хувьд завсарлага нь 15 минут байна. Энэ нь урт хугацааны функцуудыг шаардлагад нийцүүлэн өөрчлөх шаардлагатай гэсэн үг юм - энэ нь Serverless-ийг бусад алдартай технологиос (контейнер ба платформ нь үйлчилгээ) ялгаж буй зүйл юм.
Бид функц бүрт үйл явдал оноодог. Үйл явдал нь үйлдлийг өдөөх хүчин зүйл юм:
Үйл явдал
Функцийн гүйцэтгэдэг үйлдэл
Бүтээгдэхүүний зургийг хадгалах газарт байршуулсан.
Зургийг шахаж, лавлах руу байршуулна уу
Дэлгүүрийн хаягийг мэдээллийн санд шинэчилсэн
Газрын зурагт шинэ байршлыг ачаалах
Үйлчлүүлэгч барааны төлбөрийг төлдөг
Төлбөрийн боловсруулалтыг эхлүүлнэ үү
Үйл явдал нь HTTP хүсэлт, дамжуулалтын өгөгдөл, мессежийн дараалал гэх мэт байж болно. Үйл явдлын эх сурвалж нь өгөгдлийн өөрчлөлт эсвэл тохиолдлууд юм. Үүнээс гадна функцуудыг таймераар идэвхжүүлж болно.
Архитектурыг боловсруулж, програм бараг сервергүй болсон. Дараа нь бид үйлчилгээ үзүүлэгч рүү очно.
Үйлчилгээ үзүүлэгчийн талаас
Ер нь сервергүй тооцооллыг үүлэн үйлчилгээ үзүүлэгчид санал болгодог. Тэдгээрийг өөрөөр нэрлэдэг: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Бид үйлчилгээ үзүүлэгчийн консол эсвэл хувийн дансаар дамжуулан үйлчилгээг ашиглах болно. Функцийн кодыг дараах аргуудын аль нэгээр татаж авч болно.
- вэб консолоор дамжуулан суулгасан редакторуудад код бичих,
- кодтой архивыг татаж авах,
- нийтийн болон хувийн git репозиторуудтай ажиллах.
Энд бид функцийг дууддаг үйл явдлуудыг тохируулна. Үйл явдлын багц нь өөр өөр үйлчилгээ үзүүлэгчийн хувьд өөр байж болно.
Үйлчилгээ үзүүлэгч нь өөрийн дэд бүтцэд Үйлчилгээний функц (FaaS) системийг барьж, автоматжуулсан:
- Функцийн код нь үйлчилгээ үзүүлэгчийн талд хадгалагддаг.
- Үйл явдал тохиолдоход бэлтгэсэн орчинтой контейнерууд сервер дээр автоматаар тавигддаг. Функцийн жишээ бүр өөрийн гэсэн тусгаарлагдсан савтай байдаг.
- Хадгалалтаас функцийг саванд илгээж, тооцоолж, үр дүнг буцаана.
- Зэрэгцээ үйл явдлын тоо нэмэгдэж байна - савны тоо нэмэгдэж байна. Систем автоматаар хэмжигддэг. Хэрэв хэрэглэгчид энэ функцэд хандахгүй бол энэ нь идэвхгүй болно.
- Үйлчилгээ үзүүлэгч нь савны сул зогсолтыг тогтоодог - хэрэв энэ хугацаанд функцууд саванд харагдахгүй бол устгагдсан болно.
Ингэснээр бид Serverless-ийг хайрцагнаас гаргаж авдаг. Бид үйлчилгээний төлбөрийг ашигласнаараа төлдөг загвараар, зөвхөн ашиглагдаж байгаа функцүүдийнх нь төлөө, зөвхөн ашиглаж байсан хугацаандаа төлнө.
Хөгжүүлэгчдийг үйлчилгээнд нэвтрүүлэхийн тулд үйлчилгээ үзүүлэгчид 12 сар хүртэлх хугацаанд үнэ төлбөргүй туршилтыг санал болгодог боловч нийт тооцооллын хугацаа, сард хийх хүсэлтийн тоо, хөрөнгө эсвэл эрчим хүчний хэрэглээг хязгаарладаг.
Үйлчилгээ үзүүлэгчтэй ажиллахын гол давуу тал нь дэд бүтцийн (сервер, виртуал машин, контейнер) талаар санаа зовохгүй байх чадвар юм. Үйлчилгээ үзүүлэгч нь өөрийн хөгжүүлэлт болон нээлттэй эхийн хэрэгслийг ашиглан FaaS-ийг хэрэгжүүлэх боломжтой. Тэдний талаар цааш нь яръя.
Нээлттэй эх сурвалжаас
Нээлттэй эх сурвалжийн нийгэмлэг сүүлийн хоёр жилийн турш Сервергүй хэрэгслүүд дээр идэвхтэй ажиллаж байна. Зах зээлийн хамгийн том тоглогчид сервергүй платформыг хөгжүүлэхэд хувь нэмрээ оруулдаг.
- Google-ийн хөгжүүлэгчдэд нээлттэй эхийн хэрэгслийг санал болгодог - . Үүнийг боловсруулахад IBM, RedHat, Pivotal, SAP нар оролцсон;
- IBM сервергүй платформ дээр ажиллаж байсан , дараа нь Апачи сангийн төсөл болсон;
- Microsoft- платформын кодыг хэсэгчлэн нээсэн .
Мөн сервергүй фреймворкийн чиглэлд хөгжүүлэлт хийгдэж байна. и урьдчилан бэлтгэсэн Kubernetes кластер дотор байрлуулсан, Kubernetes болон Docker Swarm хоёуланд нь ажилладаг. Хүрээ нь нэг төрлийн хянагчийн үүрэг гүйцэтгэдэг - хүсэлтийн дагуу кластер дотор ажиллах орчныг бэлтгэж, дараа нь тэнд функц ажиллуулдаг.
Frameworks нь таны хэрэгцээнд нийцүүлэн багажийг тохируулах боломжийг олгодог. Тиймээс, Kubeless-д хөгжүүлэгч функцийн гүйцэтгэлийн хугацааг тохируулах боломжтой (өгөгдмөл утга нь 180 секунд). Fission нь хүйтэн эхлэх асуудлыг шийдэхийн тулд зарим савыг байнга ажиллуулахыг санал болгож байна (хэдийгээр энэ нь нөөцийн сул зогсолтыг шаарддаг). OpenFaaS нь амт, өнгө бүрт зориулсан триггерүүдийг санал болгодог: HTTP, Кафка, Редис, MQTT, Cron, AWS SQS, NATs болон бусад.
Эхлэх зааврыг хүрээний албан ёсны баримт бичгээс олж болно. Тэдэнтэй ажиллах нь үйлчилгээ үзүүлэгчтэй ажиллахаас арай илүү ур чадвар шаарддаг - энэ нь наад зах нь CLI-ээр дамжуулан Kubernetes кластерыг ажиллуулах чадвар юм. Хамгийн ихдээ бусад нээлттэй эхийн хэрэгслүүдийг (жишээлбэл, Кафка дарааллын менежер) оруулаарай.
Бид Serverless-тэй хэрхэн ажиллахаас үл хамааран - үйлчилгээ үзүүлэгчээр дамжуулан эсвэл нээлттэй эх сурвалжийг ашиглахаас үл хамааран бид Сервергүй аргын олон давуу болон сул талуудыг хүлээн авах болно.
Давуу болон сул талуудын үүднээс авч үзвэл
Сервергүй нь контейнерийн дэд бүтэц, микро үйлчилгээний аргын санааг хөгжүүлдэг бөгөөд багууд нэг платформд холбогдоогүй олон хэлний горимд ажиллах боломжтой. Системийг бий болгох нь хялбаршуулсан бөгөөд алдааг засахад хялбар байдаг. Микро үйлчилгээний архитектур нь цул програмаас хамаагүй хурдан системд шинэ функц нэмэх боломжийг олгодог.
Сервергүй нь хөгжүүлэлтийн хугацааг улам бүр багасгаж, хөгжүүлэгч зөвхөн програмын бизнесийн логик болон кодчилол дээр анхаарлаа төвлөрүүлэх боломжийг олгодог. Үүний үр дүнд бүтээн байгуулалтыг зах зээлд гаргах хугацаа багасдаг.
Урамшууллын хувьд бид ачааллын автомат масштабыг авдаг. мөн бид зөвхөн ашигласан нөөцийнх нь төлбөрийг зөвхөн ашигласан үед нь төлдөг.
Аливаа технологийн нэгэн адил Serverless нь сул талуудтай.
Жишээлбэл, ийм сул тал нь хүйтэн эхлэх хугацаа байж болно (JavaScript, Python, Go, Java, Ruby гэх мэт хэлний хувьд дунджаар 1 секунд хүртэл).
Нэг талаас, бодит байдал дээр хүйтэн эхлэх цаг нь олон хувьсагчаас хамаардаг: функц бичигдсэн хэл, номын сангийн тоо, кодын хэмжээ, нэмэлт нөөцтэй харилцах (ижил мэдээллийн сан эсвэл баталгаажуулалтын серверүүд). Хөгжүүлэгч эдгээр хувьсагчдыг хянадаг тул эхлүүлэх хугацааг багасгаж чадна. Гэхдээ нөгөө талаас, хөгжүүлэгч нь контейнерийг эхлүүлэх хугацааг хянах боломжгүй - энэ бүхэн үйлчилгээ үзүүлэгчээс хамаарна.
Өмнөх үйл явдлаар эхлүүлсэн савыг функц дахин ашиглах үед хүйтэн эхлэл нь дулаан эхлэл болж хувирдаг. Энэ нөхцөл байдал гурван тохиолдолд үүснэ:
- үйлчлүүлэгчид энэ үйлчилгээг байнга ашигладаг бол функц руу залгах тоо нэмэгддэг;
- хэрэв үйлчилгээ үзүүлэгч, платформ эсвэл хүрээ нь зарим контейнерыг байнга ажиллуулах боломжийг олгодог бол;
- хэрэв хөгжүүлэгч таймер дээр функцуудыг ажиллуулдаг бол (3 минут тутамд хэлэх).
Олон тооны хэрэглээний хувьд хүйтэн эхлэх нь асуудал биш юм. Энд та үйлчилгээний төрөл, даалгавар дээр тулгуурлах хэрэгтэй. Эхлэх секундын саатал нь бизнесийн хэрэглээний хувьд үргэлж чухал биш боловч эмнэлгийн үйлчилгээнд чухал үүрэг гүйцэтгэдэг. Энэ тохиолдолд сервергүй арга нь цаашид тохирохгүй байх магадлалтай.
Сервергүй үйлдлийн дараагийн сул тал бол функцийн ашиглалтын хугацаа богино байдаг (функцийг гүйцэтгэх ёстой завсарлага).
Гэхдээ хэрэв та урт хугацааны даалгавартай ажиллах шаардлагатай бол эрлийз архитектурыг ашиглаж болно - Serverless-ийг өөр технологитой хослуулах.
Бүх системүүд Сервергүй схемийг ашиглан ажиллах боломжгүй.
Зарим аппликешн нь гүйцэтгэлийн явцад өгөгдөл болон төлөвийг хадгалсаар байх болно. Зарим архитектурууд нь цул хэвээр байх бөгөөд зарим шинж чанарууд нь урт наслах болно. Гэсэн хэдий ч (үүл технологи, дараа нь контейнер гэх мэт) сервергүй технологи нь гайхалтай ирээдүйтэй технологи юм.
Энэ утгаараа би Сервергүй аргыг ашиглах асуудал руу жигд шилжихийг хүсч байна.
Хэрэглээний талаас
2018 оны хувьд сервергүй ашиглалтын хувь . Технологийг үйлчилгээндээ аль хэдийн нэвтрүүлсэн компаниудын дунд Twitter, PayPal, Netflix, T-Mobile, Coca-Cola зэрэг зах зээлийн аварга компаниуд байдаг. Үүний зэрэгцээ, сервергүй бол өвчин эмгэг биш, харин тодорхой хэмжээний асуудлыг шийдвэрлэх хэрэгсэл гэдгийг ойлгох хэрэгтэй.
- Нөөцийн сул зогсолтыг багасгах. Цөөн дуудлагатай үйлчилгээнд зориулж виртуал машиныг байнга байлгах шаардлагагүй.
- Өгөгдлийг шууд боловсруулах. Зургийг шахах, дэвсгэр зургийг хайчлах, видео кодчилолыг өөрчлөх, IoT мэдрэгчтэй ажиллах, математикийн үйлдлүүдийг хийх.
- Бусад үйлчилгээг хамтад нь "цавуу". Дотоод программ бүхий Git репозитор, Jira-тай Slack-ийн чат бот, хуанли.
- Ачааллыг тэнцвэржүүлэх. Эндээс илүү дэлгэрэнгүй харцгаая.
50 хүн татдаг үйлчилгээ байна гэж бодъё. Үүний доор сул техник хангамжтай виртуал машин байдаг. Үе үе үйлчилгээний ачаалал ихээхэн нэмэгддэг. Дараа нь сул техник хангамж даван туулж чадахгүй.
Та гурван виртуал машинд ачааллыг хуваарилах тэнцвэржүүлэгчийг системд оруулж болно. Энэ үе шатанд бид ачааллыг нарийн урьдчилан таамаглах боломжгүй тул тодорхой хэмжээний нөөцийг "нөөцөд" ажиллуулдаг. Мөн бид сул зогсолтын төлбөрийг илүү төлдөг.
Ийм нөхцөлд бид системийг эрлийз аргаар оновчтой болгож чадна: бид ачааллын тэнцвэржүүлэгчийн ард нэг виртуал машиныг үлдээж, функц бүхий сервергүй төгсгөлийн холбоосыг тавьдаг. Хэрэв ачаалал босго хэмжээнээс хэтэрвэл тэнцвэржүүлэгч нь хүсэлтийн боловсруулалтын хэсгийг авах функцийн тохиолдлуудыг ажиллуулдаг.
Тиймээс сервергүй програмыг олон тооны хүсэлтийг олон удаа биш, харин эрчимтэй боловсруулах шаардлагатай тохиолдолд ашиглаж болно. Энэ тохиолдолд 15 минутын турш хэд хэдэн функц ажиллуулах нь виртуал машин эсвэл серверийг байнга ажиллуулахаас илүү ашигтай байдаг.
Сервергүй тооцооллын бүх давуу талуудтай тул хэрэгжүүлэхээсээ өмнө эхлээд програмын логикийг үнэлж, тодорхой тохиолдолд сервергүй ямар асуудлыг шийдэж болохыг ойлгох хэрэгтэй.
Сервергүй ба Сонголттой
Selectel дээр бид аль хэдийн байна Манай хяналтын самбараар дамжуулан. Одоо бид өөрсдийн FaaS платформыг барьж байна. Бид хөгжүүлэгчдийг тохиромжтой, уян хатан интерфейсээр дамжуулан Serverless ашиглан асуудлаа шийдэхийг хүсч байна.
Хэрэв танд хамгийн тохиромжтой FaaS платформ гэж юу байх ёстой, мөн өөрийн төслүүдэд Serverless ашиглах талаар санаа байгаа бол сэтгэгдэл дээр хуваалцаарай. Платформыг боловсруулахдаа бид таны хүслийг харгалзан үзэх болно.
Нийтлэлд ашигласан материалууд:
Эх сурвалж: www.habr.com