Habilidades avanzadas en diseño de arquitectura de sistemas · Teoría y práctica del diseño de arquitectura nativa de la nube

Índice de contenidos de los artículos de la serie.

Habilidades avanzadas en diseño de arquitectura de sistemas · Conceptos de arquitectura de software, estilos arquitectónicos, ABSD, reutilización de arquitectura, DSSA (1) [Arquitecto de sistemas] Habilidades avanzadas en diseño de arquitectura de sistemas · Atributos de calidad del sistema
y evaluación de arquitectura (2) [Arquitecto de sistemas]
Habilidades avanzadas en diseño de arquitectura de sistemas · Análisis y diseño de confiabilidad del software (3) [Diseñador de arquitectura de sistemas]

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

1. La connotación de arquitectura nativa de la nube

1.1 Definición

La arquitectura nativa de la nube es una colección de principios arquitectónicos y patrones de diseño basados ​​en la tecnología nativa de la nube. Su objetivo es maximizar la eliminación de partes de código no comerciales en aplicaciones en la nube, permitiendo que las instalaciones de la nube asuman una gran cantidad de características no funcionales originales en aplicaciones (como elasticidad, resiliencia, seguridad y partes del código se eliminan al máximo, de modo que las instalaciones de la nube puedan asumir una gran cantidad de características no funcionales originales (como elasticidad, resiliencia, seguridad, observabilidad, escala de grises, etc.) .) en la aplicación, para que la empresa ya no tenga problemas con interrupciones comerciales no funcionales, es liviana, ágil y altamente automatizada.

1.2 Características

Las características de la aplicación basadas en la arquitectura nativa de la nube incluyen:

(1) La estructura del código ha experimentado cambios tremendos : ya no es necesario dominar los archivos y su tecnología de procesamiento distribuido, y ya no es necesario dominar varias tecnologías de red complejas. La simplificación hace que el desarrollo empresarial sea más ágil y rápido.
(2) Se confía la solución de una gran cantidad de características no funcionales a la arquitectura nativa de la nube : como alta disponibilidad, recuperación ante desastres, características de seguridad, operatividad, facilidad de uso, capacidad de prueba, capacidades de lanzamiento en escala de grises, etc.
(3) Entrega de software altamente automatizada : la entrega de software automatizada basada en la nube nativa puede implementar automáticamente aplicaciones en miles de nodos.

1.3 Principios de la nube nativa

El nativo de la nube tiene los siguientes principios:

(1) Principio de servitización : Separe módulos de diferentes ciclos de vida a través de una arquitectura de servitización y realice iteraciones comerciales por separado.
(2) Principio de elasticidad : La elasticidad significa que la escala de implementación del sistema puede expandirse y contraerse automáticamente a medida que cambia el volumen de negocios.
(3) Principio de observabilidad : a través de registros, seguimiento y medición de enlaces, los valores de retorno y los parámetros que consumen mucho tiempo de múltiples llamadas de servicio son claramente visibles.
(4) Principio de resiliencia : la capacidad del software para resistir cuando ocurren diversas anomalías en los componentes de software y hardware de los que depende el software.
(5) Principios de automatización de todos los procesos : permita que las herramientas de automatización comprendan los objetivos de entrega y las diferencias ambientales para realizar la automatización de toda la entrega, operación y mantenimiento del software.
(6) Principio de confianza cero : no se debe confiar en ninguna persona/dispositivo/sistema dentro o fuera de la red, y la base de confianza del control de acceso debe reconstruirse basándose en la autenticación y la autorización.
(7) Principio de evolución continua de la arquitectura : La arquitectura tiene la capacidad de seguir evolucionando.

1.4 Principales patrones arquitectónicos

Los principales patrones arquitectónicos involucrados en la nube nativa.

1.4.1 Modelo de arquitectura basada en servicios

Es necesario dividir un software de aplicación en la granularidad de los módulos de la aplicación, definir relaciones comerciales mutuas con contratos de interfaz (como IDL), garantizar la interconexión mutua con protocolos estándar (HTTP, gRPC, etc.) y combinarlo con el diseño impulsado por dominio. (DDD), el diseño basado en pruebas (TDD) y la implementación en contenedores mejoran la calidad del código y la velocidad de iteración de cada interfaz.

1.4.2 Modelo de arquitectura de malla

La arquitectura de malla separa el marco de middleware (como RPC, caché, mensajes asincrónicos, etc.) del proceso comercial, desvinculando aún más el SDK de middleware del código comercial, de modo que la actualización del middleware no tenga impacto en el proceso comercial e incluso migre. El middleware de otra plataforma también es transparente para el negocio.

1.4.3 Modo sin servidor

Cuando llega el tráfico comercial o ocurre un evento comercial, la nube iniciará o programará un proceso comercial iniciado para su procesamiento. Una vez completado el procesamiento, la nube cerrará/programará automáticamente el proceso comercial y esperará el siguiente desencadenante. Los desarrolladores no necesitan preocuparse por la ubicación de ejecución de la aplicación, el sistema operativo, la configuración de la red, el rendimiento de la CPU, etc., y confían todo el funcionamiento de la aplicación a la nube. El modo sin servidor es adecuado para tareas informáticas de datos basadas en eventos, aplicaciones de solicitud/respuesta con un tiempo de cálculo corto y tareas de ciclo largo sin llamadas mutuas complejas.

1.4.4 Modo de separación de almacenamiento y cálculo

La dificultad de CAP en un entorno distribuido es principalmente para aplicaciones con estado. Dado que la coherencia (Consistencia, C), la disponibilidad (Disponible, A) y la tolerancia de partición (Partition Tolerance, P) no se pueden satisfacer al mismo tiempo, como máximo dos de ellos pueden estar satisfechos. . Por lo tanto, las aplicaciones sin estado no tienen la dimensión de coherencia y pueden lograr una buena disponibilidad y tolerancia a fallas de partición, logrando así una mejor elasticidad.

1.4.5 Modelo de transacciones distribuidas

Dado que la empresa necesita acceder a múltiples microservicios, surgirán problemas de transacciones distribuidas; de lo contrario, los datos serán inconsistentes. Por lo tanto, los arquitectos deben elegir modos de transacciones distribuidas apropiados de acuerdo con diferentes escenarios. Los más utilizados son:
(1) Modo XA: dado que la especificación XA es el estándar para realizar el procesamiento de transacciones distribuidas, la confirmación en dos etapas (2 preparación de confirmación, 2PC) Generalmente se usa El método tiene una gran consistencia, pero requiere dos interacciones de red, por lo que el rendimiento es deficiente.
(2) Coherencia eventual basada en mensajes (BASE): cuando la disponibilidad y la coherencia entran en conflicto, para sopesar las dos, BASE propone que, siempre que se cumplan la disponibilidad básica (BA) y la coherencia eventual (E), el software que acepta datos estado o estado indeterminado (S) para priorizar el rendimiento, por lo que este tipo de sistemas suele tener un alto rendimiento. Sin embargo, debido a las características de la aplicación, se elige un compromiso entre disponibilidad y consistencia, lo que resulta en una pobre versatilidad.
(3) Modelo TCC: al utilizar el modelo de dos etapas Try-Confirm-Cancel, el aislamiento de transacciones es controlable y eficiente, pero requiere código de aplicación para dividir el modelo de negocio en dos etapas, por lo que es muy intrusivo para el negocio y el costo. El nivel de diseño, desarrollo y mantenimiento es alto.
(4) Modo SAGA: cada transacción a plazo corresponde a una transacción de compensación. Si la transacción a plazo no se ejecuta, la transacción de compensación se ejecutará para revertirla. Por tanto, los costes de desarrollo y mantenimiento son elevados.
(5) Modo AT del proyecto de código abierto SEATA: delega la segunda fase del modo TCC al marco de código subyacente y cancela los bloqueos de fila, por lo que tiene un rendimiento muy alto, no tiene carga de trabajo de desarrollo de código y puede realizar una reversión automáticamente. operaciones, pero existen algunas restricciones en los escenarios de uso.

1.4.6 Arquitectura observable

La arquitectura observable incluye registro, seguimiento y métricas. El registro proporciona múltiples niveles de seguimiento, como INFORMACIÓN/DEPURACIÓN/ADVERTENCIA/ERROR; el seguimiento recopila la agregación de registros de acceso desde el extremo frontal hasta el final de una solicitud para formar un completo seguimiento del enlace de llamada; las métricas proporcionan mediciones multidimensionales de la cuantificación del sistema, incluida la concurrencia, el consumo de tiempo, el tiempo disponible, la capacidad, etc.

1.4.7 Arquitectura basada en eventos

La arquitectura basada en eventos (EDA) es un patrón de arquitectura integrada entre aplicaciones/componentes. Adecuado para mejorar la resiliencia del servicio, notificación de cambios de datos, creación de interfaces abiertas, procesamiento de flujo de eventos y separación de responsabilidad de consultas de comandos (Command Query Responsibility Segregation, CQRS). Los comandos que afectan el estado del servicio se inician utilizando eventos sin afectar el estado del servicio. Solo utiliza la interfaz API que se llama sincrónicamente.

1.5 Antipatrones típicos de la arquitectura nativa de la nube

El diseño de la arquitectura a veces requiere elegir diferentes métodos según diferentes escenarios comerciales. Los antipatrones nativos de la nube comunes incluyen:

(1) Aplicación única enorme : falta de aislamiento de dependencias, acoplamiento de código, límites poco claros entre responsabilidades y módulos, falta de gobernanza de las interfaces entre módulos, difusión de cambios, dificultad para coordinar el progreso del desarrollo y el tiempo de lanzamiento entre diferentes módulos e inestabilidad de uno submódulo Como resultado, toda la aplicación se ralentiza. Al expandirse, la capacidad solo se puede expandir en su conjunto y los módulos que alcanzan el cuello de botella no se pueden expandir individualmente.
(2) "División completa" de aplicaciones monolíticas en microservicios : divide a la fuerza módulos con alto grado de acoplamiento y baja calidad de código en servicios; después de la división, los datos del servicio están estrechamente acoplados; después de la diferenciación, se convierten en llamadas distribuidas, lo que afecta gravemente el rendimiento .
(3) Microservicios que carecen de capacidades de automatización : aumenta el número de módulos por persona responsable, aumenta la carga de trabajo por persona y también aumenta el costo de desarrollo de software.

2. Tecnologías relacionadas con la arquitectura nativa de la nube

1.1 Tecnología de contenedores

Como unidad básica de software estandarizado, los contenedores empaquetan y liberan aplicaciones y sus dependencias. Debido a que las dependencias están completas, las aplicaciones ya no están restringidas por el entorno y pueden leerse rápidamente y ejecutarse de manera confiable en diferentes entornos informáticos .

Comparación del modo de implementación de contenedores con otros modos, como se muestra en la figura, comparación de los modos tradicional, de virtualización y de implementación de contenedores:

1.2 Tecnología de orquestación de contenedores

La tecnología de orquestación de contenedores incluye programación de recursos, implementación y administración de aplicaciones, reparación automática, descubrimiento de servicios y equilibrio de carga, escalamiento elástico, API declarativa, arquitectura de escalabilidad y portabilidad .

1.3 Microservicios

El modelo de microservicio divide la aplicación monolítica back-end en múltiples subaplicaciones débilmente acopladas, cada subaplicación es responsable de un conjunto de subfunciones. Estas subaplicaciones se convierten en "microservicios" y múltiples "microservicios" juntos forman un sistema de microservicios distribuido físicamente independiente pero lógicamente completo. Este microservicio es relativamente independiente y mejora la eficiencia general de la iteración al desacoplar los procesos de desarrollo, prueba e implementación.

Las restricciones de diseño de microservicios son las siguientes:

(1) Restricciones individuales de microservicio: para
una aplicación de microservicio bien diseñada, las funciones completadas deben ser independientes entre sí en términos de división del dominio comercial. En comparación con una sola aplicación que está vinculada por la fuerza a un lenguaje y una pila de tecnología, la ventaja de esto es que diferentes dominios comerciales tienen diferentes opciones tecnológicas. Por ejemplo, el sistema de recomendación que usa Python puede ser mucho más eficiente que Java. Desde un punto de vista organizacional, los microservicios corresponden a equipos más pequeños y una mayor eficiencia de desarrollo. "Un equipo de microservicios puede comer dos pizzas en una comida" y "una aplicación de microservicios debería poder completar una iteración al menos cada dos semanas" son metáforas y estándares sobre cómo dividir correctamente los límites de los microservicios en los dominios empresariales. En resumen, el "micro" de los microservicios no es ser micro por ser micro, sino dividir razonablemente una sola aplicación según el dominio del problema. Además, los microservicios también deben tener características de descomposición ortogonal, centrándose en negocios específicos y haciéndolos bien en términos de división de responsabilidades, que es el Principio de Responsabilidad Única (SRP) en el principio SOLID. Si un microservicio se modifica o lanza, no debería afectar la interacción comercial de otro microservicio en el mismo sistema.

(2) Relaciones horizontales entre microservicios:
después de dividir razonablemente los límites entre microservicios, las relaciones horizontales entre servicios se tratan principalmente desde la capacidad de descubrimiento y la interactividad de los microservicios. La capacidad de descubrimiento de los microservicios significa que cuando el servicio A se lanza, se expande o se reduce, ¿cómo puede el servicio B, que depende del servicio A, detectar automáticamente los cambios en el servicio A sin volver a lanzarlo? Aquí es necesario introducir un servicio de terceros. Centro de registro para cumplir con la capacidad de descubrimiento de servicios; especialmente para grupos de microservicios a gran escala, las capacidades de impulso y expansión del centro de registro de servicios son particularmente críticas. La interactividad de los microservicios se refiere a la forma en que el servicio A puede llamar al servicio B. Debido a las limitaciones de la autonomía del servicio, las llamadas entre servicios deben utilizar protocolos de llamadas remotas independientes del idioma. Por ejemplo, el protocolo REST satisface bien los dos factores importantes de "independiente del idioma" y "estandarización". En algunos escenarios, un protocolo binario basado en IDL podría ser una mejor opción. Además, la mayoría de las prácticas de microservicios actuales en la industria a menudo no alcanzan la llamada REST heurística de HATEOAS, y los servicios deben completar la llamada a través de una interfaz acordada previamente. Para lograr aún más el desacoplamiento entre servicios, el sistema de microservicio necesita un centro de metadatos independiente para almacenar la información de metadatos del servicio, y el servicio consulta al centro para comprender los detalles de la llamada. A medida que los enlaces de servicios continúan creciendo, todo el sistema de microservicios se vuelve cada vez más frágil, por lo que
el principio del diseño orientado a fallas es particularmente importante en los sistemas de microservicios. Para aplicaciones de microservicios individuales, los mecanismos para mejorar la resiliencia del servicio, como la limitación de corriente, el disyuntor, el aislamiento y el equilibrio de carga, se han convertido en estándar. Para mejorar aún más el rendimiento del sistema y aprovechar al máximo los recursos de la máquina, esto se puede lograr mediante corrutinas, modelos Rx, llamadas asincrónicas, contrapresión y otros medios.

(3) Restricciones verticales entre microservicios y capa de datos

En el campo de los microservicios, se adopta el principio de segregación de almacenamiento de datos (DSS), es decir, los datos son el activo privado del microservicio y el acceso a los datos debe realizarse a través de la API proporcionada por el microservicio actual. De lo contrario, provocará un acoplamiento en la capa de datos, violando el principio de alta cohesión y bajo acoplamiento. Al mismo tiempo, por razones de rendimiento, generalmente se adopta la separación de lectura y escritura (CQRS). De manera similar, debido al impacto impredecible de la programación de contenedores en la estabilidad de las instalaciones subyacentes, el diseño de microservicios debe intentar seguir el principio de diseño sin estado, lo que significa que la aplicación superior y la infraestructura subyacente están desacopladas, y los microservicios se pueden programar libremente entre diferentes contenedores. . Para los microservicios que tienen acceso a datos (es decir, con estado), la separación de computación y almacenamiento generalmente se usa para hundir los datos en un almacenamiento distribuido, de esta manera se puede lograr un cierto grado de apatridia.

(4) Restricciones distribuidas de microservicios desde una perspectiva global.Desde
el comienzo del diseño del sistema de microservicios, se deben considerar los siguientes factores: operación y mantenimiento eficientes de todo el sistema y preparación técnica de una canalización de CI/CD totalmente automatizada para satisfacer la demanda. para la eficiencia del desarrollo., y sobre esta base admite diferentes estrategias de lanzamiento, como azul-verde y canario, para satisfacer la demanda de estabilidad de lanzamiento comercial. Frente a sistemas complejos, las capacidades de observabilidad multidimensional, en tiempo real y de enlace completo se han convertido en estándar. Para prevenir diversos riesgos de operación y mantenimiento de manera oportuna y efectiva, es necesario recopilar y analizar datos relevantes de múltiples fuentes de eventos en el sistema de microservicios y luego mostrarlos de manera multidimensional en un sistema de monitoreo centralizado. A medida que los microservicios continúan dividiéndose, la puntualidad en la detección de fallas y la precisión de las causas raíz siempre han sido las demandas principales del personal de desarrollo, operación y mantenimiento.

1.4 Tecnología sin servicio

Características de la tecnología sin servicio:

(1) Servicios informáticos totalmente administrados, los clientes solo necesitan escribir código para crear aplicaciones y no necesitan prestar atención al desarrollo, operación y mantenimiento, seguridad, alta disponibilidad y otros trabajos homogéneos y engorrosos basados ​​​​en servidores y otras infraestructuras;

(2) La versatilidad, combinada con las capacidades de la API BaaS en la nube, puede admitir todos los tipos importantes de aplicaciones en la nube;

(3) El escalamiento elástico automático elimina la necesidad de que los usuarios planifiquen la capacidad con anticipación para el uso de recursos;

(4) La facturación de pago por uso permite a las empresas reducir eficazmente los costos de uso sin tener que pagar por recursos inactivos.

1.5 Red de servicios

Service Mesh es una nueva tecnología desarrollada para aplicaciones distribuidas basadas en una arquitectura de software de microservicios. Su objetivo es integrar funciones comunes como conexión, seguridad, control de flujo y observabilidad entre microservicios en la infraestructura de la plataforma. Lograr el desacoplamiento de las aplicaciones y la infraestructura de la plataforma . Este desacoplamiento significa que los desarrolladores no necesitan prestar atención a los problemas de gobernanza relacionados con los microservicios y centrarse en la lógica empresarial en sí, lo que mejora la eficiencia del desarrollo de aplicaciones y acelera la exploración e innovación empresarial. En otras palabras, la malla de servicios permite aligerar las aplicaciones de una manera no intrusiva porque una gran cantidad de no funcionalidad se elimina de los procesos de negocio hacia otros procesos.

Como se muestra en la figura, la arquitectura típica de la red de servicios:

En este diagrama de arquitectura, todas las solicitudes del servicio A para llamar al servicio B son interceptadas por el proxy de servicio debajo de él. El servicio proxy A completa el descubrimiento del servicio, el disyuntor, la limitación de corriente y otras estrategias para el servicio B. El control general de estas estrategias es Configurar en el plano de control.