Sen servidor non se trata da ausencia física de servidores. Este non é un asasino de contedores nin unha tendencia pasaxeira. Este é un novo enfoque para construír sistemas na nube. No artigo de hoxe imos tocar a arquitectura das aplicacións sen servidor, imos ver que papel xogan o provedor de servizos sen servidor e os proxectos de código aberto. Finalmente, imos falar sobre os problemas de usar Serverless.
Quero escribir unha parte do servidor dunha aplicación (ou incluso unha tenda en liña). Pode ser un chat, un servizo de publicación de contido ou un equilibrador de carga. En calquera caso, haberá moitos quebradizos de cabeza: haberá que preparar a infraestrutura, determinar as dependencias da aplicación e pensar no sistema operativo host. A continuación, terás que actualizar pequenos compoñentes que non afectan o funcionamento do resto do monolito. Ben, non nos esquezamos de escalar baixo carga.
E se tomamos contedores efémeros, nos que as dependencias requiridas xa están preinstaladas e os propios contedores están illados entre si e do sistema operativo host? Dividiremos o monolito en microservizos, cada un dos cales se pode actualizar e escalar independentemente dos outros. Ao colocar o código nun contedor deste tipo, podo executalo en calquera infraestrutura. Xa mellor.
E se non queres configurar contedores? Non quero pensar en escalar a aplicación. Non quero pagar por contedores inactivos cando a carga do servizo é mínima. Quero escribir código. Concéntrase na lóxica empresarial e saca produtos ao mercado á velocidade da luz.
Tales pensamentos leváronme á informática sen servidor. Sen servidor neste caso significa non a ausencia física de servidores, senón a ausencia de dores de cabeza de xestión de infraestruturas.
A idea é que a lóxica de aplicación se descomponga en funcións independentes. Teñen unha estrutura de eventos. Cada función realiza unha "microtarefa". Todo o que se require do programador é cargar as funcións na consola proporcionada polo provedor da nube e correlacionalas coas fontes de eventos. O código executarase baixo demanda nun contedor preparado automaticamente e só pagarei polo tempo de execución.
Vexamos como será agora o proceso de desenvolvemento de aplicacións.
Do lado do desenvolvedor
Antes comezamos a falar dunha aplicación para unha tenda en liña. No enfoque tradicional, a lóxica principal do sistema realízase mediante unha aplicación monolítica. E o servidor coa aplicación está en execución constantemente, aínda que non haxa carga.
Para pasar a sen servidor, dividimos a aplicación en microtarefas. Escribimos a nosa propia función para cada un deles. As funcións son independentes entre si e non almacenan información de estado (sen estado). Incluso poden estar escritos en diferentes idiomas. Se un deles "cae", toda a aplicación non parará. A arquitectura da aplicación terá o seguinte aspecto:
A división en funcións en Serverless é semellante ao traballo con microservizos. Pero un microservizo pode realizar varias tarefas e, idealmente, unha función debería realizar unha. Imaxinemos que a tarefa é recoller estatísticas e mostralas a petición do usuario. No enfoque de microservizos, unha tarefa é realizada por un servizo con dous puntos de entrada: escritura e lectura. Na computación sen servidor, estas serán dúas funcións diferentes que non están relacionadas entre si. O programador aforra recursos informáticos se, por exemplo, as estatísticas se actualizan con máis frecuencia da que se descargan.
As funcións sen servidor deben executarse nun curto período de tempo (tempo de espera), que é determinado polo fornecedor de servizos. Por exemplo, para AWS o tempo de espera é de 15 minutos. Isto significa que as funcións de longa duración terán que cambiarse para adaptalas aos requisitos; isto é o que distingue a Serverless doutras tecnoloxías populares na actualidade (contedores e Platform as a Service).
Asignamos un evento a cada función. Un evento é o desencadenante dunha acción:
Evento
A acción que realiza a función
Cargouse unha imaxe de produto ao repositorio.
Comprime a imaxe e carga a un directorio
Actualizouse o enderezo da tenda física na base de datos
Carga unha nova localización nos mapas
O cliente paga a mercancía
Comezar a procesar o pagamento
Os eventos poden ser solicitudes HTTP, datos en tempo real, filas de mensaxes, etc. As fontes dos eventos son cambios ou ocorrencias de datos. Ademais, as funcións pódense activar mediante un temporizador.
Elaborouse a arquitectura e a aplicación case quedou sen servidor. A continuación imos ao provedor de servizos.
Do lado do provedor
Normalmente, a informática sen servidor é ofrecida polos provedores de servizos na nube. Chámanse de forma diferente: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Usaremos o servizo a través da consola ou da conta persoal do provedor. O código de función pódese descargar dunha das seguintes formas:
- escribir código en editores integrados a través da consola web,
- descarga o arquivo co código,
- traballar con repositorios git públicos ou privados.
Aquí configuramos os eventos que chaman á función. Os conxuntos de eventos poden diferir segundo os distintos provedores.
O provedor construíu e automatizou o sistema Function as a Service (FaaS) na súa infraestrutura:
- O código de función acaba almacenado no lado do provedor.
- Cando se produce un evento, os contedores cun ambiente preparado despréganse automaticamente no servidor. Cada instancia de función ten o seu propio recipiente illado.
- Desde o almacenamento, a función envíase ao contedor, calcúlase e devolve o resultado.
- O número de eventos paralelos está crecendo - o número de contedores está crecendo. O sistema escala automaticamente. Se os usuarios non acceden á función, esta estará inactiva.
- O provedor establece o tempo de inactividade dos contedores; se durante este tempo non aparecen funcións no contedor, este destrúese.
Deste xeito saímos sen servidor da caixa. Pagaremos o servizo mediante o modelo de pago por uso e só para aquelas funcións que se utilicen, e só polo momento en que se utilizaron.
Para introducir os desenvolvedores no servizo, os provedores ofrecen ata 12 meses de probas gratuítas, pero limitan o tempo total de cálculo, o número de solicitudes ao mes, os fondos ou o consumo de enerxía.
A principal vantaxe de traballar cun provedor é a posibilidade de non preocuparse pola infraestrutura (servidores, máquinas virtuais, contedores). Pola súa banda, o provedor pode implementar FaaS tanto utilizando os seus propios desenvolvementos como utilizando ferramentas de código aberto. Falemos máis deles.
Desde o lado do código aberto
A comunidade de código aberto estivo traballando activamente en ferramentas sen servidor durante os últimos dous anos. Os maiores actores do mercado tamén contribúen ao desenvolvemento de plataformas sen servidor:
- Google ofrece aos desenvolvedores a súa ferramenta de código aberto - . No seu desenvolvemento participaron IBM, RedHat, Pivotal e SAP;
- IBM traballou nunha plataforma sen servidor , que logo se converteu nun proxecto da Fundación Apache;
- Microsoft abriu parcialmente o código da plataforma .
Tamén están en marcha desenvolvementos na dirección de marcos sen servidor. и despregado dentro de clústeres de Kubernetes previamente preparados, funciona tanto con Kubernetes como con Docker Swarm. O marco actúa como unha especie de controlador: previa solicitude, prepara un ambiente de execución dentro do clúster e, a continuación, lanza unha función alí.
Os marcos deixan espazo para configurar a ferramenta segundo as túas necesidades. Así, en Kubeless, un desenvolvedor pode configurar o tempo de espera de execución da función (o valor predeterminado é de 180 segundos). Fision, nun intento de resolver o problema do arranque en frío, suxire manter algúns contedores funcionando todo o tempo (aínda que isto implica custos de inactividade dos recursos). E OpenFaaS ofrece un conxunto de disparadores para todos os gustos e cor: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT e outros.
As instrucións para comezar pódense atopar na documentación oficial dos frameworks. Traballar con eles require ter un pouco máis de habilidades que cando se traballa cun provedor; esta é polo menos a capacidade de lanzar un clúster de Kubernetes a través da CLI. Como máximo, inclúe outras ferramentas de código aberto (por exemplo, o xestor de colas de Kafka).
Independentemente de como traballemos con Serverless (a través dun provedor ou usando código aberto), recibiremos unha serie de vantaxes e desvantaxes do enfoque Serverless.
Dende o punto de vista de vantaxes e inconvenientes
Serverless desenvolve as ideas dunha infraestrutura de contedores e un enfoque de microservizos, no que os equipos poden traballar nun modo multilingüe sen estar ligados a unha plataforma. A construción dun sistema é simplificada e os erros son máis fáciles de corrixir. A arquitectura de microservizos permítelle engadir novas funcionalidades ao sistema moito máis rápido que no caso dunha aplicación monolítica.
Sen servidor reduce aínda máis o tempo de desenvolvemento, permitindo que o programador se centre unicamente na lóxica empresarial e na codificación da aplicación. Como resultado, o tempo de comercialización dos desenvolvementos redúcese.
Como extra, temos a escala automática para a carga, e pagamos só polos recursos empregados e só no momento en que se utilizan.
Como calquera tecnoloxía, Serverless ten desvantaxes.
Por exemplo, tal desvantaxe pode ser o tempo de inicio en frío (de media ata 1 segundo para linguaxes como JavaScript, Python, Go, Java, Ruby).
Por unha banda, en realidade, o tempo de inicio en frío depende de moitas variables: a linguaxe na que está escrita a función, o número de bibliotecas, a cantidade de código, a comunicación con recursos adicionais (as mesmas bases de datos ou servidores de autenticación). Dado que o programador controla estas variables, pode reducir o tempo de inicio. Pero, por outra banda, o desenvolvedor non pode controlar o tempo de inicio do contedor: todo depende do provedor.
Un arranque en frío pode converterse nun arranque en quente cando unha función reutiliza un contedor lanzado por un evento anterior. Esta situación darase en tres casos:
- se os clientes usan o servizo con frecuencia e aumenta o número de chamadas á función;
- se o provedor, plataforma ou marco permite manter algúns contedores funcionando todo o tempo;
- se o programador executa funcións nun temporizador (por exemplo, cada 3 minutos).
Para moitas aplicacións, un arranque en frío non é un problema. Aquí cómpre construír sobre o tipo e as tarefas do servizo. Un atraso de inicio dun segundo non sempre é fundamental para unha aplicación empresarial, pero pode chegar a ser crítico para os servizos médicos. Neste caso, o enfoque sen servidor probablemente xa non sexa adecuado.
A seguinte desvantaxe de Serverless é a curta vida útil dunha función (tempo de espera durante o cal a función debe ser executada).
Pero, se tes que traballar con tarefas de longa duración, podes usar unha arquitectura híbrida: combina sen servidor con outra tecnoloxía.
Non todos os sistemas poderán funcionar usando o esquema sen servidor.
Algunhas aplicacións aínda almacenarán datos e estado durante a execución. Algunhas arquitecturas seguirán sendo monolíticas e algunhas características serán de longa duración. Non obstante (como tecnoloxías en nube e despois contedores), Serverless é unha tecnoloxía con moito futuro.
Neste sentido, gustaríame pasar sen problemas á cuestión do uso do enfoque sen servidor.
Dende o lado da aplicación
Para 2018, a porcentaxe de uso sen servidor . Entre as empresas que xa implantaron a tecnoloxía nos seus servizos atópanse xigantes do mercado como Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Ao mesmo tempo, cómpre entender que Serverless non é unha panacea, senón unha ferramenta para resolver unha determinada gama de problemas:
- Reducir o tempo de inactividade dos recursos. Non é necesario manter constantemente unha máquina virtual para os servizos que teñen poucas chamadas.
- Procesar datos sobre a marcha. Comprimir imaxes, recortar fondos, cambiar a codificación de vídeo, traballar con sensores IoT, realizar operacións matemáticas.
- "Cola" outros servizos. Repositorio Git con programas internos, chat bot en Slack con Jira e calendario.
- Equilibrar a carga. Vexamos aquí máis de cerca.
Digamos que hai un servizo que atrae a 50 persoas. Baixo ela hai unha máquina virtual cun hardware débil. De cando en vez, a carga do servizo aumenta significativamente. Entón o hardware débil non pode facer fronte.
Pode incluír un equilibrador no sistema que distribuirá a carga, por exemplo, en tres máquinas virtuais. Neste momento, non podemos predecir con precisión a carga, polo que mantemos unha certa cantidade de recursos funcionando "en reserva". E pagamos de máis polo tempo de inactividade.
En tal situación, podemos optimizar o sistema mediante un enfoque híbrido: deixamos unha máquina virtual detrás do equilibrador de carga e poñemos unha ligazón ao punto final sen servidor con funcións. Se a carga supera o limiar, o equilibrador inicia instancias de funcións que se encargan de parte do procesamento da solicitude.
Así, sen servidor pódese usar onde sexa necesario procesar un gran número de solicitudes non con demasiada frecuencia, pero de forma intensiva. Neste caso, executar varias funcións durante 15 minutos é máis rendible que manter unha máquina virtual ou un servidor todo o tempo.
Con todas as vantaxes da computación sen servidor, antes da implementación, primeiro debes avaliar a lóxica da aplicación e comprender que problemas pode resolver sen servidor nun caso particular.
Sen servidor e Selectel
En Selectel xa estamos a través do noso panel de control. Agora estamos construíndo a nosa propia plataforma FaaS. Queremos que os desenvolvedores poidan resolver os seus problemas usando Serverless a través dunha interface cómoda e flexible.
Se tes ideas sobre cal debería ser a plataforma FaaS ideal e como queres usar Serverless nos teus proxectos, compárteas nos comentarios. Teremos en conta os teus desexos ao desenvolver a plataforma.
Materiais utilizados no artigo:
Fonte: www.habr.com