Escribir en frente
Para comenzar un recorrido periférico (en adelante denominado partida) es un conocido sitio de viajes en línea en China que se enfoca en "recorridos periféricos". Para reducir el acoplamiento de varios módulos de negocios dentro de la compañía y mejorar la eficiencia del desarrollo, entrega y operación y mantenimiento, nos basamos en 2017 Spring Cloud completó la transformación de los microservicios comerciales internos de la compañía y, en 2019, se dio cuenta de la migración de Spring Cloud a la plataforma UK8S.
Este artículo presenta nuestras prácticas de transformación Spring Cloud basadas en UK8S en términos de arquitectura empresarial, monitoreo de Prometheus JVM, escalamiento elástico máximo basado en HPA, seguimiento de enlaces APM basado en Elastic e gobierno de servicio Istio.
Por qué K8S y por qué UK8S
Como marco actual de microservicios convencionales, Spring Cloud define una serie de estándares para el gobierno de servicios, como enrutamiento inteligente, mecanismo de fusibles, registro y descubrimiento de servicios a nivel funcional, y proporciona las bibliotecas y componentes correspondientes para implementar estas características estándar. Servir al medio ambiente circundante proporciona el mayor apoyo.
Antes de la transformación, la arquitectura empresarial de Spring Cloud es la siguiente: la parte de descubrimiento del servicio usa el componente Eureka de Spring Cloud, el componente fusible usa Hystrix, la puerta de enlace de servicio usa Zuul y Spring Cloud Gateway (razones históricas), y la configuración distribuida usa principalmente Spring Cloud Config (parte del equipo usó Apollo) y logró el equilibrio de carga en el lado del servicio al cliente a través de Feign.
Pero Spring Cloud también tiene algunas deficiencias inevitables, como el alto umbral de aplicación y el costo de aprendizaje aportados por diferentes componentes basados en diferentes marcos, y la necesidad de controlar muchos componentes a nivel de código, lo que va en contra del objetivo de la colaboración multilingüe de microservicios.
Internamente, debido a razones históricas, la arquitectura de la puerta de enlace API utilizada por diferentes grupos no es uniforme, y hay varios conjuntos de Spring Cloud, lo que causa inconvenientes para la gestión unificada; Spring Cloud no puede lograr el lanzamiento en escala de grises, y también trae cierta seguridad al lanzamiento comercial de la compañía. Inconveniencia Más importante aún, como un sitio web de viajes periférico, a menudo realizamos algunas actividades promocionales, enfrentamos la demanda de expansión elástica y reducción de recursos durante los períodos pico de negocios, y depender solo de Spring Cloud no puede lograr la programación de recursos para satisfacer las necesidades de expansión y reducción automática de negocios. .
Cuando decidimos hacer la transición a UK8S, también consideramos el uso de Kubespray para construir un clúster K8S y conectar el clúster K8S a los recursos de la nube a través de Cloud Provider, como el uso de Equilibrio de carga, Clase de almacenamiento, Cluster Autoscaler (CA), etc. En este caso, el Nodo recién agregado requiere la implementación e instalación por separado de Cloud Provider, lo que aporta cierta complejidad al trabajo de operación y mantenimiento.
UK8S realiza una conexión perfecta con el host interno de la nube UHost, el equilibrio de carga ULB, el disco de la nube UDisk y otros productos. Podemos crear y llamar fácilmente a los productos anteriores dentro del clúster UK8S. En el escenario de máxima resistencia, el complemento CA dentro del UK8S también se puede utilizar para expandir y reducir automáticamente los recursos a nivel de nodo, lo que mejora en gran medida la eficiencia de la operación y el mantenimiento. A través de su complemento CNI, UK8S está conectado a la propia red VPC de UCloud, eliminando la necesidad de otras soluciones de red de código abierto, reduciendo la complejidad de la red; y la naturaleza única de la no encapsulación de UK8S, que también da más espacio para la transformación y puede fallar Cuando comprueba y resuelve el problema usted mismo rápidamente.
Arquitectura empresarial general
El proceso desde Spring Cloud hasta UK8S también es un proceso de reorganización y unificación de módulos de servicio interno. En este proceso, realizamos los siguientes cambios en la arquitectura general del negocio:
1. Elimine el Eureka original y use Discovery en el proyecto Spring Cloud Kubernetes. El proyecto lanzado oficialmente de Spring Cloud Spring Cloud Kubernetes proporciona una interfaz común para llamar a los servicios de Kubernetes, lo que permite que los programas Spring Cloud y Spring Boot funcionen mejor en el entorno de Kubernetes. En el entorno de Kubernetes, ETCD ya tiene la información necesaria para el descubrimiento de servicios. No es necesario usar Eureka. A través de Discovery, puede obtener la lista de servicios registrados en Kubernetes ETCD para el descubrimiento de servicios.
2. Elimine el equilibrio de carga de Feign y utilice en su lugar la cinta Spring Cloud Kubernetes. Hay dos tipos de modos de equilibrio de carga de la cinta: Servicio / Pod. En el modo Servicio, puede usar el equilibrio de carga nativo de Kubernetes e implementar la gestión de servicios a través de Istio.
3. Marginación del portal. La puerta de enlace se utiliza como entrada original. Toda eliminación requiere una transformación a gran escala del código original. Implementamos la puerta de enlace original como un microservicio en Kubernetes y utilizamos Istio para administrar la entrada de tráfico. Al mismo tiempo, también eliminamos fusibles y enrutamiento inteligente, e implementamos la gestión de servicios basada en Istio en su conjunto.
4. La configuración distribuida Config está unificada en Apollo. Apollo puede gestionar de forma centralizada la configuración de aplicaciones en diferentes entornos y diferentes clústeres. Después de la modificación, se transfiere al lado de la aplicación en tiempo real y tiene las características de permisos estandarizados y gobierno de procesos.
5. Incrementar el monitoreo de Prometeo. En particular, monitorea algunos parámetros y algunos indicadores definidos de la JVM, e implementa la escala elástica HPA basada en los indicadores monitoreados.
Después de Kubernetes, la arquitectura empresarial separa el plano de control del plano de datos. Kubernetes Master se usa naturalmente como el plano de control para realizar el control de todo el conjunto de negocios sin implementar ningún negocio real. El plano de datos contiene proyectos basados en diferentes lenguajes o arquitecturas como Java, PHP, Swoole y .NET Core. Debido a que los diferentes idiomas tienen diferentes requisitos para el rendimiento de la máquina, implementamos varios proyectos en nodos de nodo con diferentes configuraciones a través de la etiqueta de nodo en Kubernetes, para que las aplicaciones no interfieran entre sí.
Monitoreo JVM basado en Prometheus
Después de que Spring Cloud se migre a Kubernetes, aún necesitamos obtener una serie de parámetros de bajo nivel de la JVM para monitorear el estado de ejecución del servicio en tiempo real. Prometheus es un complemento de monitoreo relativamente maduro, y Prometheus también proporciona un complemento de Spring Cloud, que puede obtener los parámetros subyacentes de la JVM para el monitoreo en tiempo real.
Establecemos una serie de parámetros detallados, como el tiempo de respuesta, el número de solicitudes, la memoria JVM, la miscelánea JVM, la recolección de basura, etc., para proporcionar una base confiable para la resolución de problemas y la optimización comercial.
Escala elástica máxima basada en HPA
Para comenzar como una plataforma de pedidos de servicios turísticos periféricos, en el proceso comercial, a menudo involucra paisajes que requieren una elasticidad máxima, como lugares pintorescos y la compra de boletos de hotel. La función HPA de Kubernetes proporciona una buena manera de lograr escenarios de escalado elástico.
En Kubernetes, HPA generalmente se implementa mediante la CPU de Pod, la utilización de memoria, etc., pero en Java, JVM implementa el control de memoria. Cuando el uso de memoria es demasiado alto, JVM recuperará la memoria, pero JVM no volverá al host o Contenedores, no es razonable expandir y reducir el clúster basándose únicamente en los indicadores Pod / CPU. Utilizamos Prometheus para obtener el parámetro http_server_requests_seconds_count (solicitudes) en Java, convertirlo en un parámetro reconocido por el Servidor API de Kubernetes a través del adaptador y ajustar dinámicamente el número de Pods en tiempo real según este indicador.
El producto UK8S también proporciona su propio complemento de escalado de clúster. Al establecer el grupo de escalado y hacer coincidir las condiciones de escalado correspondientes, puede crear el host de nube correspondiente como un nodo Nodo a tiempo, lo cual es conveniente para que extraigamos recursos de manera más rápida y eficiente durante las horas pico de negocios.
Seguimiento de enlaces APM basado en elástico
Bajo el marco de microservicios, una solicitud a menudo involucra múltiples servicios, por lo que la supervisión del rendimiento del servicio y la resolución de problemas se vuelven complicados; diferentes servicios pueden ser desarrollados por diferentes equipos o incluso implementados en diferentes lenguajes de programación; los servicios pueden implementarse en varios Miles de servidores en múltiples centros de datos diferentes.
Por lo tanto, necesita herramientas que puedan ayudarlo a comprender el comportamiento del sistema y analizar los problemas de rendimiento para que pueda localizar y resolver problemas rápidamente cuando ocurra una falla.
Hay muchos componentes APM de código abierto en el mercado, Zipkin, Pinpoint, Skywalking, etc. Finalmente elegimos un servidor apm basado en el código abierto Elastic. Esto se debe a que hay demasiados proyectos de monitoreo de código abierto en el mercado, pero los proyectos no pueden comunicarse bien. Elastic recopila registros de negocios a través de filebeat, monitorea el rendimiento del servicio de aplicaciones a través de metricbeat, implementa el seguimiento entre servicios a través de apm-server y almacena datos en es de manera uniforme. Integra el registro, las métricas y el seguimiento juntos, rompiendo proyectos. Las barreras entre ellos pueden ayudar a O&M y al desarrollo y localizar fallas más rápidamente para garantizar la estabilidad del sistema.
Gobierno de servicio de Istio
Con base en la seguridad de la aplicación, la observabilidad, la implementación continua, el escalado elástico y el rendimiento, la integración de herramientas de código abierto, el soporte del plano de control de código abierto y la madurez del programa, finalmente elegimos a Istio como el programa de gobierno del servicio, que implica principalmente lo siguiente Varias partes:
1. Pasarela Istio-gateway: Ingress Gateway es lógicamente equivalente a un equilibrador de carga en el borde de la red. Se utiliza para recibir y procesar conexiones de red entrantes y salientes en el borde de la red, incluidos los puertos abiertos y la configuración TLS. , Para lograr la gestión del tráfico norte-sur dentro del clúster.
2. Mesh Gateway: el Gateway virtual dentro de Istio representa todos los Sidecars dentro de la red, y realiza la comunicación entre todos los servicios dentro de la red, es decir, la gestión del tráfico este-oeste.
3. Gestión del tráfico: después de eliminar los componentes originales de Spring Cloud, como el fusible y el enrutamiento inteligente, nos dimos cuenta de la función de la gestión del tráfico http a través de una serie de configuraciones y gestión dentro del clúster de Kubernetes. Incluyendo el uso de etiquetas Pod para agrupar procesos de servicio específicos (como las aplicaciones de versión V1 / V2) e implementar la programación del tráfico, definir individualmente estrategias de equilibrio de carga de servicio a través de la regla de destino en Istio y redireccionar en función de los servicios de origen y las URL para lograr la descarga de enrutamiento objetivo, etc. , A través de MenQuota, RedisQuota para limitar el flujo, etc.
4. Telemetría: Obtenga datos de telemetría a través de Prometheus para realizar el monitoreo de la tasa de éxito del proyecto gris, la diferenciación del tráfico este-oeste, el tráfico pico del servicio y la topología dinámica del servicio.
Resumen
En la actualidad, hemos migrado todas nuestras aplicaciones de comercio electrónico social "alabanza de los invitados en la nube" a UK8S, y los lenguajes de desarrollo incluyen Java, PHP-FPM, NodeJS, etc. En combinación con CI / CD, puede realizar rápidamente la iteración del servicio y los nuevos proyectos se ponen en línea, mejorando en gran medida la eficiencia del desarrollo, la operación y el mantenimiento; a través de un sistema perfecto de registro, monitoreo, seguimiento de enlaces y alarma, puede localizar rápidamente fallas y en función de los datos de telemetría Prejuzgue el pico de antemano, logre la ampliación automática del servicio a través de HPA y asigne recursos científicamente, lo que reduce en gran medida el costo de los recursos informáticos; a través del gobierno del servicio Istio, la gestión del tráfico se logra bien y la liberación en escala de grises se logra fácilmente en función de esto.
A continuación, enriqueceremos aún más la canalización de CI / CD, agregando pruebas unitarias, escaneo de códigos, pruebas de rendimiento, etc. para mejorar la eficiencia de las pruebas; introduciendo computadoras para enriquecer los medios de operación y mantenimiento; usando Istio para lograr una gestión de múltiples nubes para garantizar aún más la estabilidad empresarial.
◆ El autor de este artículo: Wang Qiong, "Arquitecto de operaciones y mantenimiento y Gerente de operaciones y mantenimiento" de "To Be Around", es responsable de la implementación nativa de la empresa en la nube y la transformación de la contenedorización empresarial. En 2016, comenzó a contactar a K8S y continuó cultivándose en el campo de K8S y Service Mesh. Está comprometido a construir una plataforma de servicio de contenedores a nivel de producción.