Senservilo ne temas pri la fizika foresto de serviloj. Ĉi tio ne estas ujo-murdinto aŭ preterpasanta tendenco. Ĉi tio estas nova aliro al konstruado de sistemoj en la nubo. En la hodiaŭa artikolo ni tuŝos la arkitekturon de Serverless-aplikoj, ni vidu, kian rolon ludas la Serverless-servoprovizanto kaj malfermfontaj projektoj. Fine, ni parolu pri la problemoj pri uzado de Serverless.
Mi volas skribi servilon parton de aplikaĵo (aŭ eĉ reta vendejo). Ĉi tio povus esti babilejo, enhava eldonservo aŭ ŝarĝbalancilo. Ĉiukaze, estos multaj kapdoloroj: vi devos prepari la infrastrukturon, determini la aplikajn dependecojn kaj pensi pri la mastruma mastruma sistemo. Tiam vi devos ĝisdatigi malgrandajn komponantojn, kiuj ne influas la funkciadon de la resto de la monolito. Nu, ni ne forgesu pri grimpi sub ŝarĝo.
Kio se ni prenos efemerajn ujojn, en kiuj la postulataj dependecoj jam estas antaŭinstalitaj, kaj la ujoj mem estas izolitaj unu de la alia kaj de la gastiga OS? Ni dividos la monoliton en mikroservojn, ĉiu el kiuj povas esti ĝisdatigita kaj skalita sendepende de la aliaj. Metante la kodon en tian ujon, mi povas ruli ĝin sur ajna infrastrukturo. Jam pli bone.
Kio se vi ne volas agordi ujojn? Mi ne volas pensi pri skalado de la aplikaĵo. Mi ne volas pagi por neaktivaj ujoj kiam la ŝarĝo de la servo estas minimuma. Mi volas skribi kodon. Fokusu pri komerca logiko kaj alportu produktojn al la merkato kun la lumrapideco.
Tiaj pensoj kondukis min al senservila komputado. Senservilo en ĉi tiu kazo signifas ne la fizika foresto de serviloj, sed la foresto de infrastrukturadministrado kapdoloroj.
La ideo estas, ke aplika logiko estas dividita en sendependajn funkciojn. Ili havas aranĝan strukturon. Ĉiu funkcio plenumas unu "mikrotaskon". Ĉio, kio postulas de la programisto, estas ŝarĝi la funkciojn en la konzolon provizitan de la nuba provizanto kaj korelacii ilin kun okazaĵfontoj. La kodo estos plenumita laŭpeto en aŭtomate preta ujo, kaj mi pagos nur por la ekzekuttempo.
Ni vidu, kiel aspektos nun la aplikaĵa disvolva procezo.
De la flanko de la programisto
Antaŭe ni komencis paroli pri aplikaĵo por reta vendejo. En la tradicia aliro, la ĉefa logiko de la sistemo estas farita per monolita apliko. Kaj la servilo kun la aplikaĵo konstante funkcias, eĉ se ne estas ŝarĝo.
Por moviĝi al senservilo, ni disigas la aplikaĵon en mikrotaskojn. Ni skribas nian propran funkcion por ĉiu el ili. La funkcioj estas sendependaj unu de la alia kaj ne konservas ŝtatinformojn (sennaciaj). Ili eĉ povas esti skribitaj en malsamaj lingvoj. Se unu el ili "falos", la tuta aplikaĵo ne ĉesos. La aplika arkitekturo aspektos jene:
La divido en funkcioj en Serverless similas labori kun mikroservoj. Sed mikroservo povas plenumi plurajn taskojn, kaj funkcio ideale devus plenumi unu. Ni imagu, ke la tasko estas kolekti statistikojn kaj montri ilin laŭ la peto de la uzanto. En la mikroserva aliro, tasko estas farita de unu servo kun du enirpunktoj: skribo kaj legado. En senservila komputado, ĉi tiuj estos du malsamaj funkcioj, kiuj ne rilatas unu al la alia. La programisto ŝparas komputikajn rimedojn se, ekzemple, statistikoj estas ĝisdatigitaj pli ofte ol ili estas elŝutitaj.
Senservilaj funkcioj devas esti ekzekutitaj en mallonga tempodaŭro (timeout), kiu estas determinita de la servoprovizanto. Ekzemple, por AWS la tempodaŭro estas 15 minutoj. Ĉi tio signifas, ke longdaŭraj funkcioj devos esti ŝanĝitaj laŭ la postuloj - jen kio distingas Serverless de aliaj popularaj teknologioj hodiaŭ (ujoj kaj Platform as a Service).
Ni atribuas eventon al ĉiu funkcio. Okazaĵo estas ellasilo por ago:
Evento
La ago kiun la funkcio faras
Produkta bildo estis alŝutita al la deponejo.
Kunpremu la bildon kaj alŝutu al dosierujo
La fizika vendeja adreso estis ĝisdatigita en la datumbazo
Ŝarĝu novan lokon en mapoj
La kliento pagas por la varoj
Komencu pagpretigon
Okazaĵoj povas esti HTTP-petoj, fluaj datumoj, mesaĝvostoj, ktp. Eventfontoj estas ŝanĝoj aŭ okazoj de datumoj. Krome, funkcioj povas esti ekigitaj per tempigilo.
La arkitekturo estis ellaborita, kaj la aplikaĵo preskaŭ iĝis senservila. Poste ni iru al la servoprovizanto.
De la flanko de la provizanto
Tipe, senservila komputado estas ofertita de nubaj servaj provizantoj. Ili nomiĝas malsame: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Ni uzos la servon per la konzolo aŭ persona konto de la provizanto. Funkcia kodo povas esti elŝutita laŭ unu el la sekvaj manieroj:
- skribi kodon en enkonstruitaj redaktiloj per la interreta konzolo,
- elŝutu la arkivon kun la kodo,
- labori kun publikaj aŭ privataj git-deponejoj.
Ĉi tie ni starigas la eventojn, kiuj nomas la funkcion. La aroj de eventoj povas malsami laŭ malsamaj provizantoj.
La provizanto konstruis kaj aŭtomatigis la sistemon Funkcio kiel Servo (FaaS) sur ĝia infrastrukturo:
- La funkciokodo finiĝas en stokado ĉe la provizanto.
- Kiam okazaĵo okazas, ujoj kun preta medio estas aŭtomate deplojitaj sur la servilo. Ĉiu funkciokazaĵo havas sian propran izolitan ujon.
- De la stokado, la funkcio estas sendita al la ujo, kalkulita, kaj resendas la rezulton.
- La nombro da paralelaj eventoj kreskas - la nombro da ujoj kreskas. La sistemo aŭtomate grimas. Se uzantoj ne aliras la funkcion, ĝi estos neaktiva.
- La provizanto fiksas la neaktivan tempon por ujoj - se dum ĉi tiu tempo funkcioj ne aperas en la ujo, ĝi estas detruita.
Tiel ni eltiras Serverless el la skatolo. Ni pagos por la servo uzante la pagmodelon kaj nur por tiuj funkcioj kiuj estas uzataj, kaj nur por la tempo kiam ili estis uzitaj.
Por prezenti programistojn al la servo, provizantoj ofertas ĝis 12 monatojn da senpaga testado, sed limigas la totalan komputadtempon, nombron da petoj monate, financon aŭ elektran konsumon.
La ĉefa avantaĝo labori kun provizanto estas la kapablo ne zorgi pri infrastrukturo (serviloj, virtualaj maŝinoj, ujoj). Siaflanke, la provizanto povas efektivigi FaaS kaj uzante siajn proprajn evoluojn kaj uzante malfermfontajn ilojn. Ni parolu pri ili plu.
De la malferma fonto flanko
La malfermfonta komunumo aktive laboras pri Senservilaj iloj dum la lastaj du jaroj. La plej grandaj merkataj ludantoj ankaŭ kontribuas al la disvolviĝo de senservilaj platformoj:
- google ofertas al programistoj sian malfermfontan ilon - . IBM, RedHat, Pivotal kaj SAP partoprenis ĝian evoluon;
- IBM laboris sur Senservila platformo , kiu tiam iĝis projekto de la Apache Foundation;
- microsoft parte malfermis la platformkodon .
Evoluoj ankaŭ okazas en la direkto de senservilaj kadroj. и deplojita ene de antaŭpreparitaj Kubernetes-aretoj, funkcias kun kaj Kubernetes kaj Docker Swarm. La kadro funkcias kiel speco de regilo - laŭ peto, ĝi preparas rultempan medion ene de la areto, poste lanĉas funkcion tie.
Kadroj lasas spacon por agordi la ilon laŭ viaj bezonoj. Do, en Kubeless, programisto povas agordi la funkcian ekzekuttempon (la defaŭlta valoro estas 180 sekundoj). Fisio, en provo solvi la problemon de malvarma starto, sugestas teni iujn ujojn funkcii la tutan tempon (kvankam tio kunportas resursajn malfunkciajn kostojn). Kaj OpenFaaS ofertas aron da ellasiloj por ĉiu gusto kaj koloro: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs kaj aliaj.
Instrukcioj por komenci troveblas en la oficiala dokumentado de la kadroj. Labori kun ili postulas havi iom pli da kapabloj ol kiam oni laboras kun provizanto - ĉi tio estas almenaŭ la kapablo lanĉi Kubernetes-grupon per la CLI. Maksimume, inkludu aliajn malfermfontajn ilojn (ekzemple, la Kafka vostomanaĝero).
Sendepende de kiel ni laboras kun Serverless - per provizanto aŭ uzante malfermfontan, ni ricevos kelkajn avantaĝojn kaj malavantaĝojn de la Serverless-aliro.
El la vidpunkto de avantaĝoj kaj malavantaĝoj
Serverless disvolvas la ideojn de kontenera infrastrukturo kaj mikroserva aliro, en kiu teamoj povas labori en plurlingva reĝimo sen esti ligitaj al unu platformo. Konstruado de sistemo estas simpligita kaj eraroj estas pli facile korekteblaj. Mikroserva arkitekturo permesas vin aldoni novajn funkciojn al la sistemo multe pli rapide ol en la kazo de monolita aplikaĵo.
Senservilo reduktas evoluotempon eĉ plu, permesante al la programisto temigi sole la komerclogikon kaj kodigon de la aplikaĵo. Kiel rezulto, la tempo por surmerkatigi evoluojn estas reduktita.
Kiel gratifiko, ni ricevas aŭtomatan skalon por ŝarĝo, kaj ni pagas nur por la uzataj rimedoj kaj nur en la momento, kiam ili estas uzataj.
Kiel ĉiu teknologio, Serverless havas malavantaĝojn.
Ekzemple, tia malavantaĝo povas esti la malvarma komenca tempo (averaĝe ĝis 1 sekundo por lingvoj kiel JavaScript, Python, Go, Java, Ruby).
Unuflanke, en la realo, la malvarma starttempo dependas de multaj variabloj: la lingvo en kiu la funkcio estas skribita, la nombro da bibliotekoj, la kvanto de kodo, komunikado kun pliaj rimedoj (la samaj datumbazoj aŭ aŭtentigaj serviloj). Ĉar la programisto kontrolas ĉi tiujn variablojn, li povas redukti ektempon. Sed aliflanke, la programisto ne povas kontroli la ektempon de la ujo - ĉio dependas de la provizanto.
Malvarma komenco povas iĝi varma komenco kiam funkcio reuzas ujon lanĉitan de antaŭa evento. Ĉi tiu situacio aperos en tri kazoj:
- se klientoj ofte uzas la servon kaj la nombro da vokoj al la funkcio pliiĝas;
- se la provizanto, platformo aŭ kadro permesas vin konservi iujn ujojn la tutan tempon;
- se la programisto funkcias funkciojn per tempigilo (diru ĉiujn 3 minutojn).
Por multaj aplikoj, malvarma ekfunkciigo ne estas problemo. Ĉi tie vi devas konstrui sur la tipo kaj taskoj de la servo. Komenca prokrasto de sekundo ne ĉiam estas kritika por komerca aplikaĵo, sed ĝi povas fariĝi kritika por medicinaj servoj. En ĉi tiu kazo, la senservila aliro verŝajne ne plu taŭgas.
La sekva malavantaĝo de Serverless estas la mallonga vivdaŭro de funkcio (tempiĝo dum kiu la funkcio devas esti efektivigita).
Sed, se vi devas labori kun longdaŭraj taskoj, vi povas uzi hibridan arkitekturon - kombini Senservilo kun alia teknologio.
Ne ĉiuj sistemoj povos funkcii per la Senservila skemo.
Iuj aplikoj ankoraŭ stokos datumojn kaj staton dum ekzekuto. Iuj arkitekturoj restos monolitaj kaj iuj trajtoj estos longedaŭraj. Tamen (kiel nubaj teknologioj kaj poste ujoj), Serverless estas teknologio kun bonega estonteco.
En ĉi tiu vejno, mi ŝatus glate pluiri al la temo de uzado de la Senservila aliro.
De la aplika flanko
Por 2018, la procento de Senservila uzado . Inter la kompanioj, kiuj jam efektivigis la teknologion en siaj servoj, estas tiaj merkataj gigantoj kiel Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Samtempe, vi devas kompreni, ke Serverless ne estas panaceo, sed ilo por solvi certan gamon da problemoj:
- Redukti la malfunkcion de la rimedoj. Ne necesas konstante konservi virtualan maŝinon por servoj, kiuj havas malmultajn vokojn.
- Prilaboru datumojn sur la flugo. Kunpremu bildojn, eltranĉu fonojn, ŝanĝu videokodigon, laboru per IoT-sensiloj, faru matematikajn operaciojn.
- "Gluu" aliajn servojn kune. Git-deponejo kun internaj programoj, babilejo en Slack kun Jira kaj kalendaro.
- Ekvilibro la ŝarĝo. Ni rigardu pli detale ĉi tie.
Ni diru, ke ekzistas servo, kiu allogas 50 homojn. Sub ĝi estas virtuala maŝino kun malforta aparataro. De tempo al tempo, la ŝarĝo sur la servo pliiĝas signife. Tiam malforta aparataro ne povas elteni.
Vi povas inkluzivi ekvilibron en la sistemon, kiu distribuos la ŝarĝon, ekzemple, tra tri virtualaj maŝinoj. En ĉi tiu etapo, ni ne povas precize antaŭdiri la ŝarĝon, do ni konservas certan kvanton da rimedoj funkciante "en rezervo". Kaj ni tropagas por malfunkcio.
En tia situacio, ni povas optimumigi la sistemon per hibrida aliro: ni lasas unu virtualan maŝinon malantaŭ la ŝarĝbalancilo kaj metas ligon al la Senservila Finpunkto kun funkcioj. Se la ŝarĝo superas la sojlon, la ekvilibristo lanĉas funkciokazojn kiuj transprenas parton de la peto-prilaborado.
Tiel, Serverless povas esti uzata kie necesas prilabori grandan nombron da petoj ne tro ofte, sed intense. En ĉi tiu kazo, ruli plurajn funkciojn dum 15 minutoj estas pli enspeziga ol konservi virtualan maŝinon aŭ servilon la tutan tempon.
Kun ĉiuj avantaĝoj de senservila komputado, antaŭ efektivigo, vi unue devas taksi la aplikan logikon kaj kompreni kiajn problemojn Serverless povas solvi en aparta kazo.
Senservilo kaj Selectel
Ĉe Selectel ni jam estas per nia kontrolpanelo. Nun ni konstruas nian propran platformon FaaS. Ni volas, ke programistoj povu solvi siajn problemojn uzante Serverless per oportuna, fleksebla interfaco.
Se vi havas ideojn pri kio devus esti la ideala platformo FaaS kaj kiel vi volas uzi Serverless en viaj projektoj, dividu ilin en la komentoj. Ni konsideros viajn dezirojn dum disvolvado de la platformo.
Materialoj uzataj en la artikolo:
fonto: www.habr.com