Serverless haihusu kutokuwepo kwa seva. Huu sio muuaji wa vyombo au mtindo wa kupita. Hii ni mbinu mpya ya kujenga mifumo katika wingu. Katika makala ya leo tutagusa usanifu wa maombi ya Serverless, hebu tuone ni jukumu gani mtoa huduma wa Serverless na miradi ya chanzo-wazi hucheza. Hatimaye, hebu tuzungumze kuhusu masuala ya kutumia Serverless.
Ninataka kuandika sehemu ya seva ya programu (au hata duka la mtandaoni). Hii inaweza kuwa gumzo, huduma ya uchapishaji wa maudhui, au kusawazisha upakiaji. Kwa hali yoyote, kutakuwa na maumivu ya kichwa mengi: utakuwa na kuandaa miundombinu, kuamua utegemezi wa maombi, na kufikiri juu ya mfumo wa uendeshaji wa mwenyeji. Kisha utahitaji kusasisha vipengele vidogo ambavyo haviathiri uendeshaji wa wengine wa monolith. Naam, tusisahau kuhusu kuongeza chini ya mzigo.
Je, ikiwa tunachukua vyombo vya ephemeral, ambavyo utegemezi unaohitajika tayari umewekwa, na vyombo vyenyewe vimetengwa kutoka kwa kila mmoja na kutoka kwa OS mwenyeji? Tutagawanya monolith katika huduma ndogo, ambayo kila moja inaweza kusasishwa na kupunguzwa bila kujali zingine. Kwa kuweka nambari kwenye chombo kama hicho, naweza kuiendesha kwenye miundombinu yoyote. Tayari bora.
Je, ikiwa hutaki kusanidi vyombo? Sitaki kufikiria juu ya kuongeza programu. Sitaki kulipia vyombo vinavyoendesha bila kazi wakati mzigo kwenye huduma ni mdogo. Nataka kuandika kanuni. Zingatia mantiki ya biashara na ulete bidhaa sokoni kwa kasi ya mwanga.
Mawazo kama haya yaliniongoza kwenye kompyuta isiyo na seva. Serverless katika kesi hii ina maana sio kutokuwepo kwa seva, lakini kutokuwepo kwa maumivu ya kichwa ya usimamizi wa miundombinu.
Wazo ni kwamba mantiki ya programu imegawanywa katika vitendaji huru. Wana muundo wa tukio. Kila kazi hufanya "microtask" moja. Kinachohitajika tu kutoka kwa msanidi programu ni kupakia vitendaji kwenye kiweko kilichotolewa na mtoa huduma wa wingu na kuviunganisha na vyanzo vya matukio. Nambari itatekelezwa kwa mahitaji katika chombo kilichoandaliwa kiotomatiki, na nitalipa tu wakati wa utekelezaji.
Wacha tuone jinsi mchakato wa ukuzaji wa programu utakavyoonekana sasa.
Kutoka upande wa msanidi programu
Hapo awali tulianza kuzungumza juu ya maombi ya duka la mtandaoni. Katika mbinu ya jadi, mantiki kuu ya mfumo inafanywa na maombi ya monolithic. Na seva iliyo na programu inafanya kazi kila wakati, hata ikiwa hakuna mzigo.
Ili kuhamia bila seva, tunavunja programu kuwa kazi ndogo ndogo. Tunaandika kazi yetu wenyewe kwa kila mmoja wao. Kazi zinajitegemea na hazihifadhi habari za serikali (isiyo na utaifa). Wanaweza hata kuandikwa katika lugha tofauti. Ikiwa mmoja wao "ataanguka", programu nzima haitaacha. Usanifu wa maombi utaonekana kama hii:
Mgawanyiko katika kazi katika Serverless ni sawa na kufanya kazi na huduma ndogo. Lakini huduma ndogo inaweza kufanya kazi kadhaa, na kazi inapaswa kufanya moja. Hebu fikiria kwamba kazi ni kukusanya takwimu na kuzionyesha kwa ombi la mtumiaji. Katika mbinu ya microservice, kazi inafanywa na huduma moja na pointi mbili za kuingia: kuandika na kusoma. Katika kompyuta isiyo na seva, hizi zitakuwa kazi mbili tofauti ambazo hazihusiani na kila mmoja. Msanidi programu huhifadhi rasilimali za kompyuta ikiwa, kwa mfano, takwimu zinasasishwa mara nyingi zaidi kuliko zinapakuliwa.
Kazi zisizo na seva lazima zitekelezwe kwa muda mfupi (wakati wa kuisha), ambayo imedhamiriwa na mtoa huduma. Kwa mfano, kwa AWS muda wa kuisha ni dakika 15. Hii inamaanisha kuwa vitendaji vilivyodumu kwa muda mrefu vitalazimika kubadilishwa ili kuendana na mahitaji - hii ndiyo inayotofautisha Serverless kutoka kwa teknolojia zingine maarufu leo ββ(vyombo na Jukwaa kama Huduma).
Tunagawa tukio kwa kila kipengele. Tukio ni kichochezi cha kitendo:
Tukio
Kitendo ambacho kitendakazi hufanya
Picha ya bidhaa imepakiwa kwenye hifadhi.
Finyaza picha na upakie kwenye saraka
Anwani halisi ya duka imesasishwa katika hifadhidata
Pakia eneo jipya kwenye ramani
Mteja hulipia bidhaa
Anza kuchakata malipo
Matukio yanaweza kuwa maombi ya HTTP, data ya kutiririsha, foleni za ujumbe, na kadhalika. Vyanzo vya matukio ni mabadiliko au matukio ya data. Kwa kuongeza, kazi zinaweza kuanzishwa na kipima muda.
Usanifu ulifanyiwa kazi, na programu karibu ikawa haina seva. Ifuatayo, tunaenda kwa mtoa huduma.
Kutoka upande wa mtoaji
Kwa kawaida, kompyuta isiyo na seva hutolewa na watoa huduma wa wingu. Zinaitwa tofauti: Kazi za Azure, AWS Lambda, Kazi za Wingu la Google, Kazi za Wingu la IBM.
Tutatumia huduma kupitia kiweko cha mtoa huduma au akaunti ya kibinafsi. Nambari ya kazi inaweza kupakuliwa kwa mojawapo ya njia zifuatazo:
- andika nambari katika wahariri waliojumuishwa kupitia koni ya wavuti,
- pakua kumbukumbu na nambari,
- fanya kazi na hazina za umma au za kibinafsi za git.
Hapa tunaanzisha matukio ambayo huita kazi. Seti za matukio zinaweza kutofautiana kwa watoa huduma tofauti.
Mtoa huduma aliunda na kufanyia kazi mfumo wa Kazi kama Huduma (FaaS) kwenye miundombinu yake:
- Nambari ya utendakazi huishia kwenye hifadhi kwenye upande wa mtoa huduma.
- Wakati tukio linatokea, vyombo vilivyo na mazingira yaliyotayarishwa hutumwa kiotomatiki kwenye seva. Kila mfano wa utendaji una chombo chake cha pekee.
- Kutoka kwenye hifadhi, kazi inatumwa kwenye chombo, imehesabiwa, na inarudi matokeo.
- Idadi ya matukio sambamba inakua - idadi ya vyombo inakua. Mfumo huweka mizani kiatomati. Ikiwa watumiaji hawatafikia chaguo la kukokotoa, halitatumika.
- Mtoa huduma huweka muda wa kutofanya kazi kwa vyombo - ikiwa wakati huu utendaji hauonekani kwenye chombo, huharibiwa.
Kwa njia hii tunapata Serverless nje ya boksi. Tutalipia huduma kwa kutumia mtindo wa kulipa-kama-wewe-go na tu kwa kazi hizo zinazotumiwa, na kwa wakati tu zilipotumiwa.
Ili kuwatambulisha wasanidi huduma, watoa huduma hutoa hadi miezi 12 ya majaribio bila malipo, lakini punguza muda wa kukokotoa jumla, idadi ya maombi kwa mwezi, fedha au matumizi ya nishati.
Faida kuu ya kufanya kazi na mtoaji ni uwezo wa kutokuwa na wasiwasi juu ya miundombinu (seva, mashine za kawaida, vyombo). Kwa upande wake, mtoa huduma anaweza kutekeleza FaaS kwa kutumia maendeleo yake mwenyewe na kutumia zana huria. Hebu tuzungumze juu yao zaidi.
Kutoka upande wa chanzo wazi
Jumuiya ya programu huria imekuwa ikifanya kazi kwa bidii kwenye zana zisizo na seva kwa miaka kadhaa iliyopita. Wachezaji wakubwa wa soko pia huchangia katika ukuzaji wa majukwaa yasiyo na seva:
- google inawapa watengenezaji zana yake ya chanzo-wazi - . IBM, RedHat, Pivotal na SAP walishiriki katika maendeleo yake;
- IBM ilifanya kazi kwenye jukwaa lisilo na seva , ambayo baadaye ikawa mradi wa Wakfu wa Apache;
- microsoft ilifungua msimbo wa jukwaa .
Maendeleo pia yanaendelea katika mwelekeo wa mifumo isiyo na seva. ΠΈ iliyotumwa ndani ya nguzo za Kubernetes zilizotayarishwa awali, inafanya kazi na Kubernetes na Docker Swarm. Mfumo hufanya kama aina ya mtawala - inapoombwa, huandaa mazingira ya wakati wa kukimbia ndani ya nguzo, kisha huzindua kazi huko.
Mifumo huacha nafasi ya kusanidi zana ili kukidhi mahitaji yako. Kwa hivyo, katika Kubeless, msanidi programu anaweza kusanidi muda wa utekelezaji wa kazi (thamani ya chaguo-msingi ni sekunde 180). Fission, katika jaribio la kusuluhisha shida ya kuanza kwa baridi, inapendekeza kuweka vyombo vingine vikiendelea kila wakati (ingawa hii inajumuisha gharama za upunguzaji wa rasilimali). Na OpenFaaS inatoa seti ya vichochezi kwa kila ladha na rangi: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs na zingine.
Maagizo ya kuanza yanaweza kupatikana katika nyaraka rasmi za mifumo. Kufanya kazi nao kunahitaji kuwa na ujuzi zaidi kidogo kuliko wakati wa kufanya kazi na mtoa huduma - hii ni angalau uwezo wa kuzindua nguzo ya Kubernetes kupitia CLI. Zaidi, jumuisha zana zingine za chanzo-wazi (kwa mfano, kidhibiti cha foleni cha Kafka).
Bila kujali jinsi tunavyofanya kazi na Serverless - kupitia mtoa huduma au kutumia chanzo huria, tutapokea manufaa na hasara kadhaa za mbinu isiyo na seva.
Kutoka kwa mtazamo wa faida na hasara
Serverless huendeleza mawazo ya muundo msingi wa kontena na mbinu ya huduma ndogo, ambapo timu zinaweza kufanya kazi katika hali ya lugha nyingi bila kuunganishwa kwenye jukwaa moja. Kuunda mfumo hurahisishwa na makosa ni rahisi kusahihisha. Usanifu wa Microservice inakuwezesha kuongeza utendaji mpya kwenye mfumo kwa kasi zaidi kuliko katika kesi ya maombi ya monolithic.
Serverless inapunguza wakati wa maendeleo hata zaidi, kuruhusu msanidi programu kuzingatia tu mantiki ya biashara ya programu na usimbaji. Matokeo yake, muda wa soko kwa ajili ya maendeleo umepunguzwa.
Kama bonasi, tunapata kuongeza otomatiki kwa mzigo, na tunalipa tu kwa rasilimali zinazotumiwa na wakati tu zinapotumiwa.
Kama teknolojia yoyote, Serverless ina hasara.
Kwa mfano, shida kama hiyo inaweza kuwa wakati wa baridi wa kuanza (kwa wastani hadi sekunde 1 kwa lugha kama JavaScript, Python, Go, Java, Ruby).
Kwa upande mmoja, kwa kweli, wakati wa kuanza kwa baridi hutegemea vigezo vingi: lugha ambayo kazi imeandikwa, idadi ya maktaba, kiasi cha kanuni, mawasiliano na rasilimali za ziada (database sawa au seva za uthibitishaji). Kwa kuwa msanidi hudhibiti vigeu hivi, anaweza kupunguza muda wa kuanza. Lakini kwa upande mwingine, msanidi hawezi kudhibiti wakati wa kuanza kwa chombo - yote inategemea mtoa huduma.
Kuanza kwa baridi kunaweza kugeuka kuwa mwanzo wa joto wakati chaguo la kukokotoa linatumia tena kontena lililozinduliwa na tukio la awali. Hali hii itatokea katika kesi tatu:
- ikiwa wateja hutumia huduma mara kwa mara na idadi ya simu kwenye kazi huongezeka;
- ikiwa mtoaji, jukwaa au mfumo hukuruhusu kuweka vyombo vingine vikiendelea kila wakati;
- ikiwa msanidi programu anaendesha kazi kwenye kipima muda (sema kila dakika 3).
Kwa maombi mengi, kuanza kwa baridi sio tatizo. Hapa unahitaji kujenga juu ya aina na kazi za huduma. Kuchelewa kuanza kwa sekunde sio muhimu kila wakati kwa programu ya biashara, lakini inaweza kuwa muhimu kwa huduma za matibabu. Katika kesi hii, mbinu isiyo na seva labda haitafaa tena.
Ubaya unaofuata wa Serverless ni maisha mafupi ya chaguo la kukokotoa (muda wa kukokotoa ambapo utendakazi lazima utekelezwe).
Lakini, ikiwa unapaswa kufanya kazi na kazi za muda mrefu, unaweza kutumia usanifu wa mseto - kuchanganya Serverless na teknolojia nyingine.
Sio mifumo yote itaweza kufanya kazi kwa kutumia mpango wa Serverless.
Baadhi ya programu bado zitahifadhi data na hali wakati wa utekelezaji. Baadhi ya usanifu utabaki monolithic na vipengele vingine vitakuwa vya muda mrefu. Hata hivyo (kama vile teknolojia za wingu na kisha vyombo), Serverless ni teknolojia yenye mustakabali mzuri.
Kwa mshipa huu, ningependa kuendelea vizuri kwenye suala la kutumia mbinu ya Serverless.
Kutoka upande wa maombi
Kwa mwaka wa 2018, asilimia ya matumizi ya Bila Seva . Miongoni mwa makampuni ambayo tayari yametumia teknolojia katika huduma zao ni makampuni makubwa ya soko kama Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Wakati huo huo, unahitaji kuelewa kuwa Serverless sio panacea, lakini chombo cha kutatua shida fulani:
- Kupunguza muda wa rasilimali. Hakuna haja ya kuweka mashine pepe kila wakati kwa huduma ambazo zina simu chache.
- Mchakato wa data kwenye nzi. Shinikiza picha, kata asili, badilisha usimbaji video, fanya kazi na vihisi vya IoT, fanya shughuli za hisabati.
- "Gundi" huduma zingine pamoja. Hifadhi ya Git na programu za ndani, bot ya gumzo katika Slack na Jira na kalenda.
- Sawazisha mzigo. Hebu tuangalie kwa makini hapa.
Wacha tuseme kuna huduma inayovutia watu 50. Chini yake kuna mashine ya kawaida yenye vifaa dhaifu. Mara kwa mara, mzigo kwenye huduma huongezeka kwa kiasi kikubwa. Kisha vifaa dhaifu haviwezi kukabiliana.
Unaweza kujumuisha kusawazisha kwenye mfumo ambao utasambaza mzigo, tuseme, kwenye mashine tatu za mtandaoni. Katika hatua hii, hatuwezi kutabiri mzigo kwa usahihi, kwa hivyo tunaweka kiasi fulani cha rasilimali kikiendelea "katika hifadhi." Na tunalipa zaidi kwa wakati wa kupumzika.
Katika hali kama hii, tunaweza kuboresha mfumo kupitia mbinu ya mseto: tunaacha mashine moja pepe nyuma ya kisawazisha cha mzigo na kuweka kiungo cha Endpoint Isiyo na Seva na vitendaji. Iwapo mzigo unazidi kizingiti, sawazishaji huzindua matukio ya utendakazi ambayo huchukua sehemu ya uchakataji wa ombi.
Kwa hivyo, Serverless inaweza kutumika ambapo ni muhimu kusindika idadi kubwa ya maombi si mara nyingi sana, lakini kwa bidii. Katika kesi hii, kuendesha kazi kadhaa kwa dakika 15 ni faida zaidi kuliko kudumisha mashine au seva ya kawaida wakati wote.
Pamoja na faida zote za kompyuta isiyo na seva, kabla ya utekelezaji, unapaswa kwanza kutathmini mantiki ya programu na kuelewa ni shida gani Serverless inaweza kutatua katika kesi fulani.
Serverless na Selectel
Katika Selectel tayari tuko kupitia paneli yetu ya kudhibiti. Sasa tunaunda jukwaa letu la FaaS. Tunataka wasanidi programu waweze kutatua matatizo yao kwa kutumia Serverless kupitia kiolesura rahisi na rahisi.
Ikiwa una maoni juu ya jukwaa bora la FaaS linapaswa kuwa na jinsi ungependa kutumia Serverless katika miradi yako, yashiriki kwenye maoni. Tutazingatia matakwa yako wakati wa kuunda jukwaa.
Nyenzo zinazotumiwa katika makala:
Chanzo: mapenzi.com