Sense servidor no es tracta de l'absència física de servidors. Això no és un assassí de contenidors ni una tendència passatgera. Aquest és un nou enfocament per construir sistemes al núvol. A l'article d'avui parlarem de l'arquitectura de les aplicacions sense servidor, veurem quin paper tenen el proveïdor de serveis sense servidor i els projectes de codi obert. Finalment, parlem dels problemes relacionats amb l'ús de Serverless.
Vull escriure una part del servidor d'una aplicació (o fins i tot una botiga en línia). Pot ser un xat, un servei de publicació de contingut o un equilibrador de càrrega. En qualsevol cas, hi haurà molts maldecaps: hauràs de preparar la infraestructura, determinar les dependències de l'aplicació i pensar en el sistema operatiu amfitrió. Aleshores, haureu d'actualitzar petits components que no afectin el funcionament de la resta del monòlit. Bé, no ens oblidem d'escalar sota càrrega.
Què passa si prenem contenidors efímers, en els quals les dependències necessàries ja estan preinstal·lades i els propis contenidors estan aïllats entre si i del sistema operatiu amfitrió? Dividirem el monòlit en microserveis, cadascun dels quals es pot actualitzar i escalar independentment dels altres. En col·locar el codi en un contenidor així, puc executar-lo en qualsevol infraestructura. Ja millor.
Què passa si no voleu configurar contenidors? No vull pensar en escalar l'aplicació. No vull pagar pels contenidors en funcionament inactiu quan la càrrega del servei és mínima. Vull escriure codi. Centra't en la lògica empresarial i porta productes al mercat a la velocitat de la llum.
Aquests pensaments em van portar a la informàtica sense servidor. Sense servidor en aquest cas significa no l'absència física de servidors, sinó l'absència de maldecaps de gestió d'infraestructures.
La idea és que la lògica de l'aplicació es desglossa en funcions independents. Tenen una estructura d'esdeveniments. Cada funció realitza una "microtasca". Tot el que es requereix del desenvolupador és carregar les funcions a la consola proporcionada pel proveïdor del núvol i correlacionar-les amb les fonts d'esdeveniments. El codi s'executarà sota demanda en un contenidor preparat automàticament i només pagaré pel temps d'execució.
Vegem ara com serà el procés de desenvolupament d'aplicacions.
Per part del desenvolupador
Abans vam començar a parlar d'una aplicació per a una botiga en línia. En l'enfocament tradicional, la lògica principal del sistema es realitza mitjançant una aplicació monolítica. I el servidor amb l'aplicació està en execució constant, encara que no hi hagi càrrega.
Per passar a sense servidor, dividim l'aplicació en microtasques. Escrivim la nostra pròpia funció per a cadascun d'ells. Les funcions són independents les unes de les altres i no emmagatzemen informació d'estat (sense estat). Fins i tot poden estar escrits en diferents idiomes. Si un d'ells "cau", tota l'aplicació no s'aturarà. L'arquitectura de l'aplicació serà així:
La divisió en funcions a Serverless és similar a treballar amb microserveis. Però un microservei pot realitzar diverses tasques i, idealment, una funció n'ha de fer una. Imaginem que la tasca és recopilar estadístiques i mostrar-les a petició de l'usuari. En l'enfocament del microservei, una tasca la realitza un servei amb dos punts d'entrada: escriptura i lectura. En la informàtica sense servidor, aquestes seran dues funcions diferents que no estan relacionades entre si. El desenvolupador estalvia recursos informàtics si, per exemple, les estadístiques s'actualitzen més sovint del que es descarreguen.
Les funcions sense servidor s'han d'executar en un període de temps curt (temps d'espera), que el determina el proveïdor de serveis. Per exemple, per a AWS el temps d'espera és de 15 minuts. Això vol dir que les funcions de llarga durada s'hauran de canviar per adaptar-se als requisits; això és el que distingeix Serverless d'altres tecnologies populars actuals (contenidors i Platform as a Service).
Assignem un esdeveniment a cada funció. Un esdeveniment és el desencadenant d'una acció:
Esdeveniment
L'acció que realitza la funció
S'ha penjat una imatge de producte al repositori.
Comprimiu la imatge i carregueu-la a un directori
L'adreça de la botiga física s'ha actualitzat a la base de dades
Carregueu una ubicació nova als mapes
El client paga la mercaderia
Inicieu el processament del pagament
Els esdeveniments poden ser sol·licituds HTTP, dades en temps real, cues de missatges, etc. Les fonts d'esdeveniments són canvis o ocurrències de dades. A més, les funcions es poden activar mitjançant un temporitzador.
Es va elaborar l'arquitectura i l'aplicació gairebé es va quedar sense servidor. A continuació anem al proveïdor de serveis.
Per part del proveïdor
Normalment, la informàtica sense servidor l'ofereixen proveïdors de serveis al núvol. S'anomenen de manera diferent: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Utilitzarem el servei a través de la consola o el compte personal del proveïdor. El codi de funció es pot descarregar d'una de les maneres següents:
- escriure codi en editors integrats mitjançant la consola web,
- descarregar l'arxiu amb el codi,
- treballar amb repositoris git públics o privats.
Aquí configurem els esdeveniments que criden a la funció. Els conjunts d'esdeveniments poden variar segons els diferents proveïdors.
El proveïdor va crear i automatitzar el sistema Function as a Service (FaaS) a la seva infraestructura:
- El codi de funció acaba emmagatzemat al costat del proveïdor.
- Quan es produeix un esdeveniment, els contenidors amb un entorn preparat es despleguen automàticament al servidor. Cada instància de funció té el seu propi contenidor aïllat.
- Des de l'emmagatzematge, la funció s'envia al contenidor, es calcula i retorna el resultat.
- El nombre d'esdeveniments paral·lels està creixent - el nombre de contenidors està creixent. El sistema escala automàticament. Si els usuaris no accedeixen a la funció, estarà inactiva.
- El proveïdor estableix el temps d'inactivitat per als contenidors; si durant aquest temps les funcions no apareixen al contenidor, es destrueix.
D'aquesta manera sortim sense servidor de la caixa. Pagarem el servei mitjançant el model de pagament i només per aquelles funcions que s'utilitzin, i només pel moment en què es van utilitzar.
Per introduir els desenvolupadors al servei, els proveïdors ofereixen fins a 12 mesos de proves gratuïtes, però limiten el temps total de còmput, el nombre de sol·licituds al mes, els fons o el consum d'energia.
El principal avantatge de treballar amb un proveïdor és la capacitat de no preocupar-se per la infraestructura (servidors, màquines virtuals, contenidors). Per la seva banda, el proveïdor pot implementar FaaS tant utilitzant els seus propis desenvolupaments com utilitzant eines de codi obert. Parlem d'ells més enllà.
Des del costat del codi obert
La comunitat de codi obert ha estat treballant activament en eines sense servidor durant els últims dos anys. Els principals actors del mercat també contribueixen al desenvolupament de plataformes sense servidor:
- google ofereix als desenvolupadors la seva eina de codi obert: . IBM, RedHat, Pivotal i SAP van participar en el seu desenvolupament;
- IBM va treballar en una plataforma sense servidor , que després es va convertir en un projecte de la Fundació Apache;
- Microsoft va obrir parcialment el codi de la plataforma .
També hi ha desenvolupaments en la direcció de marcs sense servidor. и desplegat dins de clústers Kubernetes preparats prèviament, funciona tant amb Kubernetes com amb Docker Swarm. El marc actua com una mena de controlador: a petició, prepara un entorn d'execució dins del clúster i, a continuació, llança una funció allà.
Els marcs deixen espai per configurar l'eina segons les vostres necessitats. Així, a Kubeless, un desenvolupador pot configurar el temps d'espera d'execució de la funció (el valor predeterminat és de 180 segons). Fission, en un intent de resoldre el problema de l'arrencada en fred, suggereix mantenir alguns contenidors en funcionament tot el temps (tot i que això comporta costos d'inactivitat dels recursos). I OpenFaaS ofereix un conjunt d'activadors per a tots els gustos i colors: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT i altres.
Les instruccions per començar es poden trobar a la documentació oficial dels frameworks. Treballar amb ells requereix tenir una mica més d'habilitats que quan es treballa amb un proveïdor; aquesta és almenys la capacitat de llançar un clúster de Kubernetes mitjançant la CLI. Com a màxim, inclou altres eines de codi obert (per exemple, el gestor de cues de Kafka).
Independentment de com treballem amb Serverless, a través d'un proveïdor o utilitzant codi obert, rebrem una sèrie d'avantatges i desavantatges de l'enfocament Serverless.
Des del punt de vista dels avantatges i desavantatges
Serverless desenvolupa les idees d'una infraestructura de contenidors i un enfocament de microserveis, en què els equips poden treballar en un mode multilingüe sense estar lligats a una plataforma. La construcció d'un sistema es simplifica i els errors són més fàcils de corregir. L'arquitectura de microservei us permet afegir noves funcionalitats al sistema molt més ràpidament que en el cas d'una aplicació monolítica.
Sense servidor redueix encara més el temps de desenvolupament, permetent al desenvolupador centrar-se únicament en la lògica de negoci i la codificació de l'aplicació. Com a resultat, es redueix el temps de comercialització dels desenvolupaments.
Com a avantatge, obtenim una escala automàtica per a la càrrega, i paguem només pels recursos utilitzats i només en el moment en què s'utilitzen.
Com qualsevol tecnologia, Serverless té desavantatges.
Per exemple, aquest desavantatge pot ser el temps d'inici en fred (de mitjana fins a 1 segon per a idiomes com JavaScript, Python, Go, Java, Ruby).
D'una banda, en realitat, el temps d'inici en fred depèn de moltes variables: l'idioma en què s'escriu la funció, el nombre de biblioteques, la quantitat de codi, la comunicació amb recursos addicionals (les mateixes bases de dades o servidors d'autenticació). Com que el desenvolupador controla aquestes variables, pot reduir el temps d'inici. Però, d'altra banda, el desenvolupador no pot controlar el temps d'inici del contenidor: tot depèn del proveïdor.
Un inici en fred pot convertir-se en un inici calent quan una funció reutilitza un contenidor llançat per un esdeveniment anterior. Aquesta situació es produirà en tres casos:
- si els clients utilitzen el servei amb freqüència i augmenta el nombre de trucades a la funció;
- si el proveïdor, la plataforma o el marc permet mantenir alguns contenidors en funcionament tot el temps;
- si el desenvolupador executa funcions amb un temporitzador (per exemple, cada 3 minuts).
Per a moltes aplicacions, un arrencada en fred no és un problema. Aquí heu de basar-vos en el tipus i les tasques del servei. Un retard d'inici d'un segon no sempre és fonamental per a una aplicació empresarial, però pot esdevenir fonamental per als serveis mèdics. En aquest cas, probablement l'enfocament sense servidor ja no serà adequat.
El següent desavantatge de Serverless és la curta vida útil d'una funció (temps d'espera durant el qual s'ha d'executar la funció).
Però, si heu de treballar amb tasques de llarga durada, podeu utilitzar una arquitectura híbrida: combinar sense servidor amb una altra tecnologia.
No tots els sistemes podran funcionar amb l'esquema Serverless.
Algunes aplicacions encara emmagatzemaran dades i estat durant l'execució. Algunes arquitectures continuaran sent monolítices i algunes característiques seran de llarga vida. Tanmateix (com les tecnologies al núvol i després els contenidors), Serverless és una tecnologia amb un gran futur.
En aquest sentit, m'agradaria passar sense problemes a la qüestió de l'ús de l'enfocament sense servidor.
Des del costat de l'aplicació
Per al 2018, el percentatge d'ús sense servidor . Entre les empreses que ja han implementat la tecnologia als seus serveis hi ha gegants del mercat com Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Al mateix temps, cal entendre que Serverless no és una panacea, sinó una eina per resoldre una sèrie de problemes:
- Redueix el temps d'inactivitat dels recursos. No cal mantenir constantment una màquina virtual per als serveis que tenen poques trucades.
- Processar dades sobre la marxa. Comprimiu imatges, retalleu fons, canvieu la codificació de vídeo, treballeu amb sensors IoT, feu operacions matemàtiques.
- "Enganxeu" altres serveis. Repositori Git amb programes interns, bot de xat a Slack amb Jira i calendari.
- Equilibra la càrrega. Fem una ullada més de prop aquí.
Diguem que hi ha un servei que atreu 50 persones. A sota hi ha una màquina virtual amb un maquinari feble. De tant en tant, la càrrega del servei augmenta significativament. Aleshores, el maquinari feble no pot fer front.
Podeu incloure un equilibrador al sistema que distribuirà la càrrega, per exemple, entre tres màquines virtuals. En aquesta etapa, no podem predir amb precisió la càrrega, de manera que mantenim una certa quantitat de recursos en funcionament "en reserva". I paguem de més pel temps d'inactivitat.
En aquesta situació, podem optimitzar el sistema mitjançant un enfocament híbrid: deixem una màquina virtual darrere de l'equilibrador de càrrega i posem un enllaç al punt final sense servidor amb funcions. Si la càrrega supera el llindar, l'equilibrador llança instàncies de funció que es fan càrrec de part del processament de la sol·licitud.
Per tant, Serverless es pot utilitzar quan cal processar un gran nombre de sol·licituds no massa sovint, però de manera intensiva. En aquest cas, executar diverses funcions durant 15 minuts és més rendible que mantenir una màquina virtual o un servidor tot el temps.
Amb tots els avantatges de la informàtica sense servidor, abans de la implementació, primer hauríeu d'avaluar la lògica de l'aplicació i comprendre quins problemes pot resoldre sense servidor en un cas concret.
Sense servidor i Selectel
A Selectel ja estem mitjançant el nostre panell de control. Ara estem construint la nostra pròpia plataforma FaaS. Volem que els desenvolupadors puguin resoldre els seus problemes utilitzant Serverless mitjançant una interfície còmoda i flexible.
Si teniu idees sobre quina hauria de ser la plataforma FaaS ideal i com voleu utilitzar Serverless en els vostres projectes, compartiu-les als comentaris. A l'hora de desenvolupar la plataforma tindrem en compte els vostres desitjos.
Materials utilitzats en l'article:
Font: www.habr.com