Introducción: No hay almuerzo gratis en el mundo. Si bien la tecnología de microservicio hace que los sistemas de TI sean más ágiles, robustos y de mayor rendimiento, también aumenta la complejidad de la arquitectura. Para los desarrolladores, si quieren controlar mejor la arquitectura de microservicios, necesitan resolver una serie de problemas como la integración continua, el descubrimiento de servicios, la comunicación de aplicaciones, la gestión de la configuración y la protección del tráfico.
Prefacio
En el campo de la arquitectura de TI distribuida a gran escala, los microservicios son una tecnología esencial. En esencia, los microservicios son un estilo arquitectónico que divide un gran sistema en múltiples aplicaciones con ciclos de vida independientes y utiliza mecanismos de comunicación livianos para la comunicación entre aplicaciones. Estas aplicaciones se crean en torno a empresas específicas y se pueden implementar de forma independiente, iterar de forma independiente o escalar de forma independiente en función de la carga empresarial.
La idea de microservicios y tecnologías relacionadas ha traído una serie de cambios profundos al desarrollo de la arquitectura de TI:
Fácil de desarrollar y mantener: una aplicación solo se enfocará en un conjunto específico de funciones comerciales. A través de la división de servicios, el acoplamiento entre aplicaciones se puede reducir, facilitando el desarrollo y el mantenimiento.
Pila de tecnología sin restricciones: en la arquitectura de microservicio, puede seleccionar la pila de tecnología razonablemente en función de las características del negocio y el equipo del proyecto.
Acelere la evolución del sistema: cada aplicación se puede actualizar de forma independiente, y el funcionamiento estable de todo el sistema se puede garantizar a través de medios técnicos como la liberación gris.
Cuellos de botella de rendimiento revolucionarios: cada aplicación se puede escalar de forma independiente de forma horizontal, de modo que el rendimiento del sistema se puede expandir linealmente de acuerdo con el aumento de los recursos informáticos.
El desafío de los microservicios
No hay almuerzo gratis en el mundo. Si bien la tecnología de microservicio hace que los sistemas de TI sean más ágiles, robustos y de mayor rendimiento, también aumenta la complejidad de la arquitectura. Para los desarrolladores, si quieren controlar mejor la arquitectura de microservicios, necesitan resolver una serie de problemas como la integración continua, el descubrimiento de servicios, la comunicación de aplicaciones, la gestión de la configuración y la protección del tráfico. Afortunadamente, en respuesta a estos problemas comunes, ha surgido en la industria una serie de excelentes componentes y herramientas de tecnología de código abierto, que permiten a los desarrolladores crear aplicaciones de microservicio con mayor facilidad. Los marcos técnicos como Spring Cloud y Dubbo, después de años de desarrollo, se han convertido en un estándar común en el campo de los microservicios, reduciendo en gran medida el umbral de los microservicios, pero estos marcos técnicos aún no tienen forma de resolver los dos mayores desafíos. Dos desafíos se han convertido en dos grandes montañas ante los desarrolladores.
Desafío 1: Se necesita urgentemente un plan completo de gestión del ciclo de vida y gobernanza del servicio
En un sistema que se repite con frecuencia, cada aplicación a menudo se enfrentará a la necesidad de nuevas versiones. Debe realizar una gestión centralizada de los procesos en línea, fuera de línea, de actualización y de reversión de la aplicación, y cooperar con métodos de liberación detallados en escala de grises. , Para reducir el impacto de la iteración de versiones en el negocio.
En una arquitectura de microservicio simple, si una aplicación se encuentra en el punto de entrada de todo el enlace, su interfaz generalmente estará conectada con un componente de equilibrio de carga (aplicación A en la figura anterior) para aceptar solicitudes comerciales de los usuarios finales. Este tipo de aplicación será más complicado a la hora de realizar la gestión del ciclo de vida, para garantizar el equilibrio y la estabilidad de la aplicación durante el lanzamiento de la nueva versión se seguirán los siguientes pasos:
En este proceso, la solución de escala de grises avanzada para el control detallado del tráfico no ha estado involucrada, pero es suficiente para reflejar su complejidad y dificultad operativa. Si solo confía en scripts de lanzamiento simples para la administración, no solo la eficiencia es muy baja, sino que también es fácil hacer que uno pierda de vista al otro, lo que representa un gran riesgo para la estabilidad del sistema.
Reto 2: Se necesita urgentemente un plan completo de expansión y contracción horizontal
Cuando hay un cuello de botella en el rendimiento de una aplicación y es necesario mejorar el rendimiento aumentando el número de instancias, es necesario introducir nuevos recursos informáticos.
¿De dónde proceden los nuevos recursos informáticos?
Para IDC fuera de línea, los recursos informáticos deben planificarse con anticipación. La expansión no es un asunto simple y es posible que la expansión no se realice debido a diversas limitaciones. Por supuesto, este tipo de problema ya no existe en la era de la computación en la nube. Es fácil expandir los recursos informáticos para una aplicación, pero los recursos informáticos por sí solos no son suficientes. Hay que implementar aplicaciones en ella e incluirlas en un sistema de microservicio.
Según este proceso, si es necesario expandir una instancia de aplicación, una estimación conservadora es que tomará más de 20 minutos. La compra, la inicialización del sistema y la implementación de la aplicación toman mucho tiempo. Suponiendo un aumento repentino del tráfico del sistema y una expansión de emergencia en 2 minutos, esta solución es inútil.
Una buena medicina: tecnología de contenerización
Para resolver estos dos problemas, los desarrolladores han probado varias soluciones y han surgido incesantemente nuevas ideas y marcos técnicos en los últimos cinco años. Después de una ronda de supervivencia de los más aptos, la tecnología de contenedores representada por Docker, respaldada por el ecosistema de Kubernetes, se ha convertido en la corriente principal de la industria y es un elemento esencial para crear aplicaciones Cloud Native. Las tecnologías relacionadas con la contenerización pueden aprovechar el valor de más programas de computación en la nube y, hasta cierto punto, ayudar a los desarrolladores a resolver estos dos problemas.
En términos de gestión del ciclo de vida de las aplicaciones y gobierno del servicio, Kubernetes proporciona un mecanismo de implementación relativamente completo. Al construir recursos de implementación, junto con los scripts proStop y postStart, es más fácil implementar versiones continuas y elegantes aplicaciones en línea y fuera de línea. Aunque en el proceso de lanzamiento gris, todavía no hay forma de realizar directamente un control detallado del tráfico (la introducción de la tecnología Service Mesh puede mejorar el control del tráfico, que está más allá del alcance de este artículo), pero en comparación con los scripts de lanzamiento simples, ha sido un salto adelante Promover.
En términos de expansión horizontal y reducción de aplicaciones, la tecnología de contenedorización puede reducir en gran medida la instalación del sistema operativo y el tiempo de inicialización a nivel del sistema, pero la operación de compra de máquinas virtuales es inevitable, por lo que el sistema encuentra un aumento repentino en el tráfico. En ese momento, todavía no había forma de lograr una rápida expansión horizontal. Podemos reservar parte de los recursos informáticos y ponerlos en el grupo de recursos. Cuando la aplicación necesite expandirse, solicite recursos del grupo de recursos. Cuando la carga empresarial disminuya, devuelva el exceso de recursos informáticos al grupo de recursos.
En realidad, esta no es una buena idea. Cada recurso informático necesita un costo. Aunque el conjunto de recursos puede resolver el problema de la rápida utilización de los recursos informáticos, genera un gran desperdicio. Además, es muy problemático planificar el tamaño de la reserva de recursos. Cuanto más grande sea la reserva, mayor será el desperdicio, pero la reserva es demasiado pequeña y es posible que no pueda satisfacer las necesidades de expansión.
Un análisis más profundo de los costos de los recursos
Algunos desarrolladores pueden pensar que la operación comercial actual es muy estable y que no hay un aumento repentino obvio en el tráfico de usuarios, por lo que la expansión y la contracción son una pseudodemanda y no habrá tal demanda en el futuro. Esto puede ser un malentendido del negocio de Internet, porque no hay ninguna necesidad de expansión.
Primero, mientras un sistema sirva a las personas, debe haber crestas y valles. Para un sistema que funciona 7 * 24 horas, es imposible mantener el mismo tráfico de usuarios para siempre. El principio 28 todavía es aplicable a muchos sistemas empresariales (el 80% del tráfico de usuarios se concentra en el 20% del período de tiempo). Incluso para un sistema con tráfico de usuarios relativamente equilibrado, hay un punto muerto en el tráfico temprano en la mañana. Si puede liberar aún más los recursos informáticos inactivos y mejorar la utilización de recursos, puede reducir significativamente los costos de uso de recursos.
Además, en comparación con el entorno de producción, los entornos de desarrollo y prueba tienen requisitos más urgentes para la expansión y contracción de la capacidad. Diferentes equipos desarrollan un conjunto de aplicaciones de microservicio. Idealmente, varios equipos compartirán un conjunto de entornos de prueba:
Sin embargo, cada equipo tendrá su propio ritmo para la iteración de la aplicación y, al mismo tiempo, quieren tener un entorno de prueba independiente de extremo a extremo para lograr el aislamiento entre los entornos y evitar la influencia mutua entre los equipos. En este caso, es probable que se formen varios entornos de prueba:
Con el aumento en la cantidad de aplicaciones, equipos y puntos de función empresarial, la cantidad de entornos de desarrollo y prueba requeridos aumentará exponencialmente, lo que resultará en una gran pérdida de recursos. Para los recursos informáticos del entorno de prueba, la tasa de utilización de recursos es mucho menor que la del entorno de producción. A veces es solo una simple verificación de puntos de función. Para ejecutar funciones comerciales de un extremo a otro y evitar la interacción entre equipos, se abrirá un nuevo entorno que incluye todas las aplicaciones de microservicio. Este desperdicio de recursos es un problema que muchas empresas llevan muchos años sin resolver.
Por lo tanto, la arquitectura de microservicio tiene una fuerte demanda de escalado elástico. En el proceso de escalado elástico, ya sea el escalado elástico horizontal de una sola aplicación o el inicio y finalización de todo el entorno, la tasa de utilización de recursos afectará el costo final del recurso. Juega un papel decisivo. Si puede pensar en formas de mejorar la utilización de los recursos, puede ahorrar muchos costos de recursos para su empresa. Lo que merece nuestra atención es que la utilización de recursos de la mayoría de las aplicaciones de microservicio es muy baja.
Podemos hacer una estadística simple: exportar la utilización de CPU de todos los servidores cada 5 minutos y calcular el promedio de acuerdo con la dimensión de días, y luego podemos entender los datos de utilización de recursos del sistema en su conjunto. Si los recursos del servidor del entorno de desarrollo y prueba también se incluyen en las estadísticas, es probable que la tasa de utilización de recursos sea menor.
Exploración sin servidor
La causa principal de la baja utilización de recursos es que en la arquitectura de la aplicación basada en servidor, los desarrolladores necesitan implementar el paquete de programa construido en el servidor para responder a múltiples eventos de usuario. Para garantizar la puntualidad de la respuesta a incidentes, es necesario permitir que el programa resida en el servidor durante un tiempo prolongado y planificar los recursos de la forma más conservadora posible para evitar la sobrecarga y provocar caídas del servicio. En este proceso, la carga real no se distribuye uniformemente en el tiempo, lo que resulta en una baja utilización general de los recursos.
La aparición de la tecnología sin servidor proporciona nuevas ideas para mejorar la utilización de recursos. Serverless es un proceso completo para crear y administrar una arquitectura de microservicio, lo que permite a los desarrolladores implementar aplicaciones directamente sin recursos del servidor. Se diferencia de la arquitectura tradicional en que está completamente administrada por un tercero, desencadenada por un evento y existe en un contenedor informático sin estado. La creación de aplicaciones sin servidor significa que los desarrolladores pueden concentrarse en el código del producto sin tener que administrar y operar los recursos del servidor, y es realmente posible implementar aplicaciones sin involucrar la construcción de infraestructura.
La tecnología sin servidor tiene muchas formas, la más típica es FaaS (Function as a Service), como los productos Function Compute (FC) de Alibaba Cloud. En el campo de la computación funcional, todas las aplicaciones y la programación de los recursos informáticos se desencadenan por eventos comerciales específicos.Cuando se completen las tareas correspondientes a los eventos comerciales, los recursos informáticos se liberarán de inmediato. Este método realmente logra la distribución bajo demanda de los recursos informáticos y puede mejorar significativamente la utilización de los recursos. Es la última forma de tecnología sin servidor.
La otra es la tecnología de contenedor sin servidor. La instancia del contenedor sin servidor se ejecuta en un entorno de caso aislado. Cada nodo informático está completamente aislado a través de una tecnología de espacio aislado de seguridad virtualizada y ligera. Para los usuarios, las aplicaciones de contenedor se pueden implementar directamente sin comprar recursos del servidor, el mantenimiento de nodos y la planificación de la capacidad no son necesarios para los clústeres, y se pueden pagar a pedido según la cantidad de recursos de CPU y memoria configurados por la aplicación. Cuando se necesita expandir una aplicación de microservicio, los recursos informáticos se pueden obtener rápidamente, sin la necesidad de comprar servidores. Esto puede ayudar a los desarrolladores a reducir los costos informáticos, reducir el desperdicio de recursos inactivos y responder sin problemas a los picos repentinos de tráfico. Serverless Kubernetes (ASK) de Alibaba Cloud es un producto representativo de la tecnología de contenedores sin servidor.
Descubra más a fondo las demandas de los desarrolladores
La tecnología sin servidor es la dirección de desarrollo de la computación en la nube y la arquitectura de aplicaciones nativas en la nube, pero para los desarrolladores de aplicaciones de microservicio, ya sea en forma de FaaS o Kubernetes sin servidor, existen ciertas limitaciones.
No todas las empresas son adecuadas para la construcción mediante FaaS, especialmente para aplicaciones con enlaces largos y dependencias obvias ascendentes y descendentes, no hay forma de transformar FaaS. Incluso si se demuestra que la transformación FaaS de algunos sistemas comerciales es factible, la transformación de la arquitectura de microservicio existente en una arquitectura FaaS requiere una cierta cantidad de trabajo y no se puede trasplantar sin problemas.
Aunque la arquitectura de Kubernetes sin servidor puede adaptarse a todos los escenarios empresariales, para que los desarrolladores creen un sistema Kubernetes completo, necesitan dominar una serie de conceptos complejos relacionados con Kubernetes, que tiene una curva de aprendizaje muy pronunciada. Además, la construcción de varios componentes en el ecosistema de Kubernetes, junto con la adaptación de la capa de red y la capa de almacenamiento, implica un trabajo muy complicado.
La razón de esta limitación es simple. En el campo de la tecnología de microservicios representado por Spring Cloud, la construcción del sistema se basa en la aplicación (también puede entenderse como un servicio único), ya sea actualización de versión o expansión horizontal. , Todo por la propia aplicación. El núcleo de la arquitectura Serverless Kubernetes es Pod, que se inclina más hacia la parte inferior del sistema que la aplicación, por lo que los usuarios deben invertir más energía en la gestión de los recursos de nivel inferior de la aplicación. El núcleo de la arquitectura FaaS radica en la función, que se inclina más a la capa superior del sistema que a la aplicación, por lo que la flexibilidad se reducirá y no podrá adaptarse a todos los escenarios empresariales.
Para los desarrolladores que utilizan el sistema principal Spring Cloud o el sistema Dubbo para crear aplicaciones de microservicio, si necesitan introducir una solución para reducir los costos de recursos, su atractivo final debe incluir dos aspectos:
(1) ¿Puede ser cero o un costo de reconstrucción cercano a cero?
(2) ¿Puede adaptarse a todos los escenarios comerciales?
Tecnología sin servidor de capa de aplicación
¿Existe una tecnología entre FaaS y los contenedores sin servidor que pueda lograr las importantes demandas mencionadas anteriormente? Por supuesto, esta es la tecnología sin servidor de la capa de aplicación representada por Alibaba Cloud Serverless Application Engine (SAE).
(Imagen: tecnología sin servidor en diferentes niveles)
SAE se da cuenta de la perfecta integración de arquitectura sin servidor + arquitectura de microservicio. Para arquitecturas de microservicio convencionales como Spring Cloud y Dubbo, puede ser perfectamente compatible con prácticamente ningún costo de transformación, y se usa realmente bajo demanda y se factura por volumen, ahorrando inactividad. Recursos informáticos, al tiempo que se elimina el trabajo de operación y mantenimiento de la capa IaaS, lo que mejora efectivamente la eficiencia de la operación de desarrollo y el mantenimiento.
Tomando la aplicación Spring Cloud como ejemplo, si necesita implementar una nueva aplicación, solo se requieren 2 pasos:
(1) Indique a SAE cuántas instancias requiere esta aplicación y especifique las especificaciones de CPU / memoria requeridas por cada instancia.
(2) Cargue el paquete JAR / paquete WAR de la aplicación e inicie la aplicación.
Descubrimos que estos dos pasos no implican la evaluación de la capacidad, la compra del servidor, la instalación del sistema operativo, la inicialización de recursos, etc., por lo que se pueden ejecutar aplicaciones de microservicio que contienen múltiples instancias de igual a igual. Esto se debe a que en el mundo sin servidor, ya no existe el concepto de recursos del servidor. El portador de la aplicación es el contenedor sandbox programado por SAE. Cada instancia se facturará de acuerdo con la duración del uso solo después de que se ponga en uso.
Los desarrolladores no necesitan preocuparse por si la aplicación se implementa en una máquina física, una máquina virtual o un contenedor. No necesitan saber qué versión del sistema operativo subyacente es. Solo necesitan prestar atención a la cantidad de computación que ocupa cada instancia de aplicación. Los recursos servirán. Si la aplicación necesita expandirse de 4 instancias a 6 instancias, o reducirse a 2 instancias, se puede completar con una sola instrucción, e incluso la relación de enlace con SLB se puede establecer o liberar automáticamente. Esta es la tecnología sin servidor para El gran valor que aportan los desarrolladores.
El uso de SAE para implementar aplicaciones de microservicio solo cambia el operador de la aplicación, por lo que puede ser 100% compatible con la arquitectura técnica existente y las funciones comerciales, y el costo de migración es insignificante.
La máxima elasticidad de SAE
Además de las instrucciones manuales de expansión y contracción, SAE también admite dos mecanismos elásticos automáticos, que pueden expandir de manera flexible las aplicaciones de microservicio horizontalmente y ejercer aún más la elasticidad de la computación en la nube.
Mecanismo de elasticidad temporal : para los comportamientos periódicos que se espera que ocurran, se puede establecer una estrategia de elasticidad temporal. Ejemplo: si el pico comercial es a las 9 en punto de la mañana todos los días, puede aumentar el número de instancias a las 8:30 todos los días y disminuir el número de instancias a las 9:30 todos los días.
Mecanismo de elasticidad basado en el umbral del indicador: para un aumento repentino del tráfico empresarial que supere las expectativas, se puede establecer una estrategia elástica basada en los umbrales del indicador. De acuerdo con los indicadores de recursos como CPU, memoria e indicadores comerciales como QPS, las aplicaciones pueden lograr una contracción elástica automática.
A través de una variedad de mecanismos elásticos, la capacidad del sistema se puede administrar con una granularidad fina, de modo que el uso de recursos se puede ajustar con los cambios en el tráfico comercial, lo que aumenta en gran medida la utilización de recursos y reduce los costos de recursos.
En cuanto a la programación y puesta en marcha de los recursos informáticos, SAE ha realizado una serie de optimizaciones. Para las nuevas instancias que se expanden, pueden retirarse en solo unos segundos. Esta capacidad es útil para escenarios de emergencia que requieren una expansión urgente y rápida. Significativamente.
Para el entorno de desarrollo y prueba, la flexibilidad del mecanismo de SAE puede reflejarse más vívidamente Gracias a las excelentes capacidades de programación de recursos de SAE, se puede iniciar y detener un conjunto completo de aplicaciones de microservicio con un solo clic. Incluso si solo se prueba una nueva función simple para detectar humo, se puede iniciar un entorno de prueba completo y aislado. El nuevo entorno puede construirse en segundos, ponerse en uso rápidamente y puede liberarse inmediatamente después de la prueba. En términos de costo, el tiempo real para poner en uso un nuevo entorno es muy corto, por lo que solo consumirá muy pocos gastos. Este es un gran cambio para la colaboración de varios equipos en el desarrollo de aplicaciones de microservicio.
análisis de costos
SAE paga en función del uso real de los recursos. La tarifa se compone de dos partes. Cada parte se utiliza para liquidar las tarifas en función de los resultados estadísticos y métodos de cálculo, y las facturas se deducen por hora. El método de medición de recursos utilizado por cada aplicación es el siguiente:
Uso de recursos de CPU de la aplicación = ∑ Especificaciones de CPU de instancia × tiempo de ejecución del mes (en minutos), es decir, la suma de las especificaciones de CPU de todas las instancias de la aplicación multiplicada por el tiempo de ejecución del mes.
Uso de recursos de memoria de la aplicación = ∑ Especificaciones de memoria de instancia × tiempo de ejecución del mes (en minutos), es decir, la suma de las especificaciones de memoria de todas las instancias de la aplicación multiplicada por el tiempo de ejecución del mes.
El precio de la parte de la CPU es de 0,0021605 yuanes / minuto / Core, y el precio de la parte de la memoria es de 0,0005401 yuanes / minuto / GiB. SAE también proporciona paquetes de recursos prepagos, lo que equivale a la compra anticipada de recursos informáticos al por mayor. Siempre que se consuman dentro del período válido, puede ahorrar más costos de uso. Cuando se deducen los paquetes de recursos, el sistema cambiará automáticamente a pago por uso. modo.
Usemos un caso práctico para comprender mejor cómo SAE ayuda a las aplicaciones de microservicio a reducir los costos de recursos. Suponga que un sistema de microservicio contiene 87 instancias de aplicación. El tiempo de ejecución promedio por día en cada momento es de 8 horas y la configuración de la instancia es de 2 núcleos + 4 GiB + 20 G de disco.
- Implementación de aplicaciones con ECS con suscripciones anuales y mensuales: se deben comprar 87 c5 de computación. El costo mensual de una sola unidad es de 186 yuanes y el costo mensual total es de 16.146 yuanes.
- Utilice ECS con pago por uso para implementar aplicaciones: una sola unidad tiene un precio de 0,63 yuanes / hora, con un uso acumulado de 20,880 horas por mes, y el costo total es de 13,154 yuanes.
- Utilice SAE para implementar la aplicación: compre un paquete de recursos anual de 75.000 yuanes, 87 instancias que funcionan 8 horas al día, solo use la cuota del paquete de recursos, equivalente al costo mensual total de 6.250 yuanes.
A partir de esta comparación, podemos concluir que siempre que la flexibilidad de SAE se pueda ejecutar de manera razonable, los costos de recursos se pueden reducir considerablemente para las aplicaciones de microservicio.
Capacidad adicional
Además de simplificar las cargas de trabajo de operación y mantenimiento y reducir los costos de recursos, SAE también mejora una serie de funciones adicionales para las aplicaciones de microservicio. Este es el valor adicional que la tecnología sin servidor de la capa de aplicación brinda a los desarrolladores. Podemos usar estos desarrollos tanto como sea posible. La función box-to-use facilita la creación de aplicaciones de microservicio.
Gestión completa del ciclo de vida de la aplicación: una vez que la aplicación se aloja en SAE, puede realizar operaciones de gestión del ciclo de vida de la aplicación, como actualizar, escalar, iniciar y detener, eliminar, supervisar el inicio y la detención de la aplicación.
Centro de registro listo para usar : SAE viene con una versión comercial del centro de registro de Nacos, que se puede usar de forma gratuita y no es necesario que lo construya usted mismo. Si tiene requisitos especiales, como permitir que las aplicaciones implementadas en SAE y otras aplicaciones se descubran entre sí, también puede utilizar el registro proporcionado por el producto de motor de microservicio (MSE) o un registro de creación propia.
Centro de administración de configuración listo para usar : SAE integra las funciones de administración de configuración en ACM (Administración de configuración de aplicaciones), y ACM se puede usar en SAE para administrar de forma centralizada la configuración de aplicaciones.
Protección del tráfico a nivel de aplicación: SAE integra AHAS para lograr capacidades de degradación y control de flujo a nivel de aplicación, y garantiza de manera integral una alta disponibilidad de la aplicación.
Capacidades de monitoreo: una vez que la aplicación está alojada en SAE, puede obtener recursos básicos (incluida la CPU, memoria, carga y red) y capacidades de monitoreo en la capa de la aplicación (incluido el análisis de JVM, análisis de llamadas de interfaz, etc.) de forma gratuita. Si necesita análisis SQL más avanzados, análisis de excepciones, enlaces ascendentes y descendentes e instantáneas de interfaz, puede integrar los productos de monitoreo de tiempo de aplicaciones (ARMS) de Alibaba en la nube.
Capacidades de integración CI / CD: SAE tiene una integración profunda con productos como CloudEfficiency, CloudEfficiency 2020, Jenkins, etc., que pueden facilitar la implementación rápida de aplicaciones creadas por los desarrolladores.
Soporte multilenguaje
Para aplicaciones escritas en lenguajes que no sean Java, o aplicaciones Java que no utilizan marcos de microservicios como Spring Cloud, ¿puede SAE proporcionar un soporte perfecto y ayudar a las empresas a reducir los costos de recursos?
Por supuesto que es posible. SAE proporciona un método de implementación de imágenes de contenedor, lo que significa que no importa qué lenguaje de programación se utilice, siempre que la aplicación final se pueda publicar como una imagen de contenedor, se puede implementar en SAE.
Para las aplicaciones de microservicio basadas en Java, las aplicaciones generales de los sistemas Java y las aplicaciones no basadas en Java, no existe una diferencia esencial en la extrema flexibilidad de SAE, que puede proporcionar la utilización de los recursos del sistema a través de la tecnología sin servidor. Es solo que parte del valor agregado proporcionado por SAE, como un registro de microservicio gratuito, solo puede servir para aplicaciones Spring Cloud o Dubbo.
para resumir
Usemos esta imagen para revisar el gran valor de la tecnología sin servidor:
Problema común :
1. Pregunta: La instancia de la aplicación no tiene un recurso de máquina fijo o incluso una dirección IP fija ¿Cómo hacer SSH a un servidor para solucionar problemas?
Respuesta: No es necesario tener recursos de máquina fijos y direcciones IP fijas para solucionar problemas. En la era de la computación en la nube, no es una buena práctica iniciar sesión en una máquina a través de SSH para solucionar problemas. Por el contrario, SAE proporciona capacidades de monitoreo completas y también se puede integrar fácilmente con productos de diagnóstico y monitoreo de nueva generación, como monitoreo en la nube y ARMS, lo que brinda una mayor comodidad para la resolución de problemas. Por supuesto, si debe iniciar sesión en una determinada máquina, SSH seguirá siendo compatible y también puede utilizar la herramienta Webshell proporcionada por SAE para simplificar este proceso.
2. P: ¿No es el disco una dimensión de facturación? ¿Qué pasa si la aplicación necesita un disco de gran capacidad? ¿Los datos en la unidad flash permanecerán después de que se reinicie la aplicación?
Respuesta: En el campo de los microservicios, las aplicaciones generalmente no tienen estado y no necesitan guardar grandes cantidades de datos locales. Si no puede prescindir de este requisito en escenarios especiales, puede integrar NAS y utilizar almacenamiento centralizado.
3. P: ¿Cómo comprobar el registro de la aplicación?
Respuesta: La interfaz de la consola SAE proporciona acceso en tiempo real a los registros de archivos, lo que equivale a proporcionar una plataforma de recopilación de registros distribuida de forma gratuita. Por supuesto, se recomienda encarecidamente conectarse a los productos de Alibaba Cloud Log Service (SLS) para desarrollar aún más el valor de los registros de aplicaciones.
Recomendación del curso
Para que más desarrolladores disfruten de los beneficios de Serverless, esta vez, hemos reunido a más de 10 expertos técnicos de Alibaba Serverless para crear un curso público Serverless que sea más adecuado para que los desarrolladores comiencen. Adopte el nuevo paradigma de la computación en la nube sin servidor. Haga clic en el enlace para aprender el curso de forma gratuita: https://developer.aliyun.com/learning/roadmap/serverless
La cuenta oficial de Serverless publica la información más reciente sobre la tecnología Serverless, recopila el contenido más completo de la tecnología Serverless, presta atención a la tendencia sin servidor y presta más atención a la confusión y los problemas que encuentra en su práctica.
Enlace original: https://developer.aliyun.com/article/776579?
Declaración de derechos de autor: el contenido de este artículo es aportado espontáneamente por usuarios registrados de nombre real de Alibaba Cloud. Los derechos de autor pertenecen al autor original. La comunidad de desarrolladores de Alibaba Cloud no posee sus derechos de autor y no asume las responsabilidades legales correspondientes. Consulte el "Acuerdo de servicio al usuario de la comunidad de desarrolladores de Alibaba Cloud" y las "Directrices de protección de propiedad intelectual de la comunidad de desarrolladores de Alibaba Cloud" para conocer las reglas específicas. Si encuentra que existe una sospecha de plagio en esta comunidad, complete el formulario de queja por infracción para informarlo. Una vez verificado, la comunidad eliminará inmediatamente el contenido sospechoso de infracción.