Ключевые моментууд
- Хэдэн жилийн турш сервергүй тооцоолол нь програмуудыг ажиллуулах тусгай үйлдлийн системгүй шинэ эрин үеийг эхлүүлнэ гэж бид амлаж байсан. Энэ бүтэц нь өргөтгөх чадварын олон асуудлыг шийднэ гэж бидэнд хэлсэн. Үнэндээ бүх зүйл өөр байдаг.
- Сервергүй байхыг олон хүн шинэ санаа гэж үздэг ч түүний үндэс нь сервергүй архитектурыг ашигладаг Zimki PaaS болон Google App Engine бий болсноор 2006 оноос улбаатай.
- Хязгаарлагдмал програмчлалын хэлний дэмжлэгээс эхлээд гүйцэтгэлийн асуудал хүртэл сервергүй хувьсгал зогссон дөрвөн шалтгаан бий.
- Сервергүй тооцоолох нь тийм ч хэрэггүй зүйл биш юм. Огт үгүй. Гэсэн хэдий ч тэдгээрийг серверийг шууд орлуулах гэж үзэж болохгүй. Зарим програмын хувьд тэдгээр нь тохиромжтой хэрэгсэл байж болно.
Сервер үхсэн байна, сервер урт наслаарай!
Энэ бол сервергүй хувьсгалын тэмцэл юм. Сүүлийн хэдэн жилийн салбарын хэвлэлүүдийг харвал уламжлалт серверийн загвар нь унасан бөгөөд хэдхэн жилийн дараа бид бүгд сервергүй архитектурыг ашиглах болно гэж дүгнэхэд амархан.
Салбарын хэн ч мэдэж байгаачлан, мөн бидний нийтлэлд дурдсанчлан , энэ бол буруу. Гавьяаны талаар олон нийтлэл бичсэн ч гэсэн , энэ нь хэзээ ч тохиолдоогүй. Үнэндээ, Энэ хувьсгал мухардалд орсон байж магадгүй.
Сервергүй загваруудын зарим амлалтууд биелсэн ч бүгд биш. Хүн бүр биш.
Энэ нийтлэлд би энэ нөхцлийн шалтгааныг авч үзэхийг хүсч байна. Яагаад сервергүй загваруудын уян хатан чанар дутмаг байгаа нь тодорхой, тодорхой нөхцөл байдалд ашигтай хэвээр байгаа ч илүү өргөн хүрээнд нэвтрүүлэхэд саад болж байна.
Сервергүй тооцооллын мэргэжилтнүүд юу амласан бэ?
Сервергүй тооцоолоход тулгарч буй бэрхшээлүүдийн талаар ярихаасаа өмнө энэ нь юу өгөх ёстойг харцгаая. олон байсан бөгөөд заримдаа маш их амбицтай байсан.
Энэ нэр томъёог мэдэхгүй хүмүүст зориулж товч тайлбарыг энд оруулав. Сервергүй тооцоолол нь ихэвчлэн алсаас байршуулдаг ажиллах цагийн орчинд програмууд (эсвэл хэрэглээний хэсгүүд) эрэлт хэрэгцээгээр ажилладаг архитектурыг тодорхойлдог. Үүнээс гадна сервергүй системийг гэртээ байршуулах боломжтой. Сервергүй уян хатан системийг бий болгох нь сүүлийн хэдэн жилийн хугацаанд системийн администраторууд болон SaaS компаниудын хувьд гол асуудал байсаар ирсэн, учир нь энэхүү архитектур нь "уламжлалт" клиент-сервер загвараас хэд хэдэн гол давуу талыг санал болгож байна.
- Сервергүй загварууд нь хэрэглэгчдээс өөрийн үйлдлийн системээ хадгалах, тэр ч байтугай тодорхой үйлдлийн системтэй нийцтэй програмуудыг үүсгэх шаардлагагүй. Үүний оронд хөгжүүлэгчид хуваалцсан код үүсгэж, сервергүй платформд байршуулж, ажиллахыг нь хардаг.
- Сервергүй хүрээн дэх нөөцийг ихэвчлэн минутаар (эсвэл бүр секундээр) тооцдог. Энэ нь үйлчлүүлэгчид зөвхөн кодыг ажиллуулсан хугацааныхаа төлбөрийг төлдөг гэсэн үг юм. Энэ нь уламжлалт үүл VM-тэй харьцуулахад харьцангуй сайн бөгөөд машин нь ихэвчлэн сул зогсдог боловч та үүнийг төлөх ёстой.
- Өргөтгөх чадварын асуудал ч шийдэгдсэн. Сервергүй хүрээн дэх нөөцүүдийг динамик байдлаар хуваарилдаг бөгөөд ингэснээр систем нь эрэлтийн гэнэтийн өсөлтийг амархан даван туулж чадна.
Товчхондоо сервергүй загварууд нь уян хатан, хямд өртөгтэй, өргөтгөх боломжтой шийдлүүдийг өгдөг. Энэ санааг бид эртхэн бодсонгүй нь гайхмаар.
Энэ үнэхээр шинэ санаа мөн үү?
Үнэндээ энэ санаа нь шинэ зүйл биш юм. Хэрэглэгчид зөвхөн тухайн код ажиллаж байгаа хугацаандаа төлбөр төлөхийг зөвшөөрөх тухай ойлголт нь анх нэвтрүүлсэн цагаасаа хойш байсаар ирсэн 2006 онд, мөн яг тэр үед Google App Engine маш төстэй шийдлийг санал болгосон.
Үнэн хэрэгтээ, бидний одоо "сервергүй" загвар гэж нэрлэгддэг загвар нь одоогийн "үүлний эх" гэж нэрлэгддэг олон технологиос илүү эртний бөгөөд ижил зүйлийг өгдөг. Дээр дурдсанчлан сервергүй загварууд нь үндсэндээ хэдэн арван жилийн турш бий болсон SaaS бизнесийн загварын өргөтгөл юм.
Хэдийгээр сервергүй бол FaaS архитектур биш гэдгийг ойлгох нь зүйтэй, гэхдээ энэ хоёрын хооронд холболт байдаг. FaaS нь үндсэндээ сервергүй архитектурын тооцоололд төвлөрсөн хэсэг боловч бүхэл бүтэн системийг төлөөлдөггүй.
Тэгэхээр юун дээр шуугиан тарьж байна вэ? Хөгжиж буй орнуудад интернетийн нэвтрэлт хурдацтай өссөөр байгаа тул компьютерийн нөөцийн эрэлт хэрэгцээ нэгэн зэрэг нэмэгдэж байна. Жишээлбэл, цахим худалдааны салбар хурдацтай хөгжиж буй олон оронд эдгээр платформ дээрх програмуудыг тооцоолох дэд бүтэц байдаггүй. Эндээс төлбөртэй сервергүй платформууд орж ирдэг.
Сервергүй загвартай холбоотой асуудлууд
Хамгийн гол нь сервергүй загварууд ... асуудалтай байдаг. Намайг битгий буруугаар ойлгоорой: Би тэдгээр нь муу эсвэл зарим тохиолдолд зарим компаниудад чухал ач холбогдол өгдөггүй гэж хэлэхгүй. Гэвч сервергүй архитектур нь уламжлалт архитектурыг хурдан орлох болно гэсэн "хувьсгалын" гол мэдэгдэл хэзээ ч биелдэггүй.
Тийм ч учраас.
Програмчлалын хэлийг дэмжих хязгаарлагдмал
Ихэнх сервергүй платформууд нь зөвхөн тодорхой хэл дээр бичигдсэн програмуудыг ажиллуулах боломжийг олгодог. Энэ нь эдгээр системийн уян хатан байдал, дасан зохицох чадварыг ноцтойгоор хязгаарладаг.
Сервергүй платформууд нь ихэнх гол хэлийг дэмждэг гэж үздэг. AWS Lambda болон Azure функцууд нь дэмжигдээгүй хэл дээрх програмууд болон функцуудыг ажиллуулахад зориулж боодол өгдөг ч энэ нь ихэвчлэн гүйцэтгэлийн өртөгтэй байдаг. Тиймээс ихэнх байгууллагуудын хувьд энэ хязгаарлалт нь ихэвчлэн тийм ч том асуудал биш юм. Гэхдээ энд нэг зүйл байна. Сервергүй загваруудын давуу талуудын нэг нь бага мэддэг, ховор хэрэглэгддэг программуудыг зөвхөн ажиллаж байгаа хугацаанд нь төлдөг тул илүү хямдхан ашиглах боломжтой юм. Мөн бага мэддэг, ховор хэрэглэгддэг программуудыг ихэвчлэн ... бага мэддэг, ховор хэрэглэгддэг програмчлалын хэлээр бичдэг.
Энэ нь сервергүй загварын гол давуу талуудын нэгийг үгүйсгэж байна.
Борлуулагчийн алба
Сервергүй платформуудын хоёрдахь асуудал, эсвэл наад зах нь тэдгээрийг одоо хэрэгжүүлж байгаа арга нь үйл ажиллагааны түвшинд ихэвчлэн бие биентэйгээ төстэй байдаггүй явдал юм. Бичих функц, байршуулалт, удирдлагын хувьд стандартчилал бараг байдаггүй. Энэ нь функцуудыг нэг платформоос нөгөө платформ руу шилжүүлэх нь маш их цаг хугацаа шаарддаг гэсэн үг юм.
Сервергүй загвар руу шилжих хамгийн хэцүү хэсэг нь ихэвчлэн кодын хэсэгчилсэн хэсэг болох тооцоолох функцууд биш, харин програмууд объект хадгалах, таниулах удирдлага, дараалал зэрэг холбогдсон системүүдтэй хэрхэн харилцдаг явдал юм. Функцуудыг зөөж болох боловч бусад програмыг зөөх боломжгүй. Энэ нь амласан хямд, уян хатан платформуудын яг эсрэг зүйл юм.
Зарим нь сервергүй загварууд шинэ бөгөөд тэдгээрийн хэрхэн ажилладагийг стандартчилах цаг байхгүй гэж маргадаг. Гэхдээ эдгээр нь дээр дурдсанчлан тийм ч шинэ зүйл биш бөгөөд сайн стандартыг боловсруулж, өргөнөөр нэвтрүүлсний ачаар чингэлэг зэрэг бусад олон үүлэн технологиуд аль хэдийн илүү ашиглах боломжтой болсон.
Бүтээмж
Сервергүй платформуудын тооцооллын гүйцэтгэлийг хэмжихэд хэцүү байдаг нь зарим талаараа борлуулагчид мэдээллийг нууцлах хандлагатай байдаг. Ихэнх нь алсын, сервергүй платформ дээрх функцууд нь дотоод серверүүдтэй адил хурдан ажилладаг гэж маргадаг бөгөөд зарим зайлшгүй хоцролттой холбоотой асуудлуудыг эс тооцвол.
Гэсэн хэдий ч хувь хүний баримтууд эсрэгээрээ байгааг харуулж байна. Өмнө нь тодорхой платформ дээр ажиллаагүй эсвэл хэсэг хугацаанд ажиллаагүй функцуудыг эхлүүлэхэд хэсэг хугацаа шаардагдана. Энэ нь тэдний кодыг зарим нэг хүртээмжтэй хадгалах хэрэгсэлд шилжүүлсэнтэй холбоотой байж болох ч жишиг үзүүлэлтүүдийн нэгэн адил ихэнх үйлдвэрлэгчид өгөгдөл шилжүүлэх талаар танд хэлэхгүй.
Мэдээжийн хэрэг, үүнийг тойрон гарах хэд хэдэн арга бий. Нэг нь таны сервергүй платформ дээр ажиллаж байгаа ямар ч үүлэн хэл дээр функцүүдийг оновчтой болгох явдал боловч энэ нь эдгээр платформууд нь "хөдөлгөөнтэй" гэсэн мэдэгдлийг бага зэрэг үгүйсгэдэг.
Өөр нэг арга бол бүтээмжид чухал ач холбогдолтой хөтөлбөрүүдийг шинэ байлгахын тулд тогтмол ажиллуулж байх явдал юм. Мэдээжийн хэрэг, энэ хоёр дахь арга нь сервергүй платформууд нь илүү хэмнэлттэй байдаг тул та зөвхөн програмаа ажиллуулж байгаа хугацаандаа мөнгө төлдөг гэсэн мэдэгдэлтэй бага зэрэг зөрчилддөг. Үүлэн үйлчилгээ үзүүлэгчид хүйтэн эхлэхийг багасгах шинэ аргуудыг нэвтрүүлсэн боловч тэдгээрийн ихэнх нь FaaS-ийн анхны үнэ цэнийг алдагдуулж, "нэг хүртэл масштаб" шаарддаг.
Хүйтэн эхлүүлэх асуудлыг дотооддоо сервергүй системийг ажиллуулах замаар хэсэгчлэн шийдэж болох боловч энэ нь өөрийн өртөгтэй бөгөөд нөөц сайтай багуудын хувьд чухал сонголт хэвээр байна.
Та бүх програмыг ажиллуулж чадахгүй
Эцэст нь сервергүй архитектурууд уламжлалт загваруудыг хэзээ ч орлохгүй байх хамгийн чухал шалтгаан нь: тэд (ихэвчлэн) бүх програмыг ажиллуулж чадахгүй.
Бүр тодруулбал, энэ нь зардлын хувьд боломжгүй юм. Таны амжилттай монолитийг найман гарц, дөчин дараалал, өгөгдлийн сангийн арваад тохиолдлоор холбосон дөрвөн арван функцын багц болгон хувиргах ёсгүй. Ийм учраас сервергүй нь шинэ хөгжүүлэлтүүдэд илүү тохиромжтой. Бараг ямар ч одоо байгаа программыг (архитектур) шилжүүлэх боломжгүй. Та шилжиж болно, гэхдээ та эхнээс нь эхлэх хэрэгтэй.
Энэ нь ихэнх тохиолдолд сервергүй платформуудыг тооцоолол их шаарддаг ажлуудыг гүйцэтгэхийн тулд арын серверүүдэд нэмэлт болгон ашигладаг гэсэн үг юм. Энэ нь тэдгээрийг алсын тооцоолол хийх цогц арга замыг санал болгодог үүл технологийн бусад хоёр хэлбэр болох контейнер ба виртуал машинуудаас эрс ялгаатай болгодог. Энэ нь микро үйлчилгээнээс сервергүй үйлчилгээ рүү шилжихэд тулгарч буй бэрхшээлүүдийн нэгийг харуулж байна.
Мэдээжийн хэрэг, энэ нь үргэлж асуудал биш юм. Өөрийнхөө техник хангамжийг худалдаж авахгүйгээр их хэмжээний тооцоолох нөөцийг үе үе ашиглах чадвар нь олон байгууллагад бодит, урт хугацааны ашиг тусыг авчрах болно. Гэхдээ зарим програмууд дотоод серверүүд дээр, зарим нь сервергүй үүлэн архитектур дээр байрладаг бол менежмент нь шинэ төвөгтэй түвшинд хүрдэг.
Хувьсгал урт удаан наслах уу?
Эдгээр бүх гомдлыг үл харгалзан би сервергүй шийдлүүдийн эсрэг биш юм. Үнэнийг хэлэхэд. Хөгжүүлэгчид, ялангуяа сервергүй програмыг анх удаа судалж байгаа бол энэ технологи нь серверийг шууд орлох зүйл биш гэдгийг ойлгох хэрэгтэй. Оронд нь манай зөвлөмж, эх сурвалжийг үзээрэй мөн загварыг хэрхэн хамгийн сайн хэрэглэхээ шийднэ.
Эх сурвалж: www.habr.com