Introducción: Con el desarrollo de la arquitectura del sistema de software, hemos pasado de una sola aplicación a un sistema distribuido, y gradualmente pasar a la nube nativa. Entre ellas, la arquitectura de microservicios es la más representativa, pero existen varios tipos de diseño de microservicios. todo tipo de problemas, espero que este artículo pueda ayudarlo a brindar ideas y orientación en el diseño de la arquitectura de microservicios.
Prólogo y antecedentes
Antes de que comience la historia, permítanme contarles una historia. En los últimos años, con el desarrollo de la arquitectura del sistema de software, hemos experimentado desde una sola aplicación hasta un sistema distribuido, y gradualmente avanzamos hacia la nube nativa. Entre ellas, la arquitectura de microservicios es el más representativo., Pero existen varios problemas en el diseño de microservicios. Por ejemplo, si la granularidad de los microservicios es demasiado fina y la profundidad de las llamadas entre servicios es demasiado larga, puede ser necesario reorganizar el negocio y considerar el fusión de servicios. En este momento, alguien preguntará: " ¿Por qué desmanteló y recombinó microservicios? " Le dijo que estamos " Construyendo una Estación Central "; luego, con la rápida expansión del negocio, el uso de recursos ya no puede mantener, y debemos considerar desmantelar el sistema. A veces alguien pregunta: " ¿Por qué combinaste y desmantelaste los microservicios nuevamente? " Le dices que estamos " desmantelando la estación intermedia "; luego, por supuesto, después del desmantelamiento, es Descubrió que algunos servicios están desmantelados irrazonablemente, tal vez está a punto de fusionarse nuevamente. En este momento alguien pregunta: " ¿Qué diablos estás haciendo? " Puedes responderle como un anciano: "El mundo está en la tendencia general. Si nos dividimos durante mucho tiempo, debemos unirnos. Si estamos juntos durante mucho tiempo, debemos dividirnos. Qin. Después de la extinción de Qin, Chu y Han se dividieron y se fusionaron en Han. El emperador de Han gobernó el mundo, y luego Guangwu Zhongxing se dividió en tres estaciones intermedias ... "
Muchas personas pueden sentir lo mismo en la aplicación real del diseño de microservicios en los escenarios similares anteriores. ¿Cómo dividir y diseñar microservicios de manera razonable? Si existen estándares y normas relevantes para referencia, la respuesta es sí, pero solo la metodología. Desde un punto de vista filosófico, no existe una solución universal, pero algunos métodos se pueden resumir y abstraer como una guía basada en la experiencia, pero después de una abstracción excesiva, es muy oscuro y difícil de entender, y la implementación no es una tarea fácil.
Una breve historia del desarrollo de microservicios
En primer lugar, revisemos el proceso de desarrollo de la arquitectura del sistema de software: Arquitectura monolítica -> Arquitectura distribuida / de clúster -> Arquitectura orientada a servicios (SOA orientada a servicios) -> Arquitectura de microservicios -> Arquitectura de gridización / unificación
En general, la arquitectura de microservicios incluye todas las características de la arquitectura anterior, la implementación de clústeres distribuidos, el diseño orientado a servicios y los microservicios prestan más atención a la granularidad de la división de servicios, es decir, en qué tamaño se debe dividir un servicio . Sin embargo, con el aumento en el volumen de negocios del sistema, la escala de servicios también se ha vuelto cada vez más grande, y han surgido nuevos problemas correspondientes, como problemas de recursos del sistema subyacentes, problemas de comunicación y gobernanza entre servicios y problemas generales de operación y mantenimiento del servicio. SpringCloud, los marcos de microservicios como Dubbo solo pueden resolver problemas a nivel de desarrollo de software. En los primeros días de los microservicios, las personas se centraban en el nivel de desarrollo de software. En los últimos años, con la madurez y la promoción de las tecnologías de operación y mantenimiento, como la tecnología de gestión en contenedores Docker y la tecnología de orquestación de contenedores Kubernetes, el sistema de microservicios ha cambiado desde el enfoque original En desarrollo, evolucionó gradualmente hasta convertirse en un modelo de gestión de DevOps que integra diseño, desarrollo, operación y mantenimiento.
A través del proceso de desarrollo de la arquitectura de servicios, podemos ver que los microservicios logran el desacoplamiento entre servicios, pero también causan muchos problemas no comerciales. Por ejemplo: descubrimiento de servicios, limitación de la corriente del servicio, supervisión del servicio, control de permisos del servicio, control de la versión del servicio, etc. Spring Cloud y otros marcos de microservicios, aunque nos brindan, por ejemplo: Eurek, un registro para resolver problemas de descubrimiento de servicios, Hystrix, un disyuntor para resolver problemas de limitación de corriente, y Ribbon, Fegin y otras tecnologías para resolver el servicio. problemas de invocación, pero veamos si son ¿Cómo se usa? Importe dependencias de dependencia, empaquételas e impleméntelas con nuestro código comercial, lo que significa que Spring Cloud es una solución "intrusiva". Aunque simplifica la dificultad de lidiar con problemas no comerciales, los desarrolladores aún deben lidiar con esta parte La función debe ser entendido.
Esperamos que los desarrolladores de negocios solo se preocupen por el desarrollo de códigos comerciales, en lugar de gastar su energía en el desarrollo de códigos no comerciales. La tecnología Service Mesh (malla de servicios) es la encarnación de esta idea, que puede ayudar a eliminar las funciones no comerciales del El proceso de eliminación del medio elimina toda la comunicación de red entre los servicios y la sumerge en el nivel de infraestructura, como: descubrimiento de servicios, equilibrio de carga, control de versiones, implementación azul-verde y otros problemas.
Volvamos al problema fundamental a resolver en el diseño de microservicios, a saber: cómo diseñar y dividir microservicios. A continuación, se muestran algunos principios y metodología que se utilizan comúnmente en el diseño de arquitectura de microservicios:
- Principio de división de AKF
- Principios de separación comercial
- Diseño controlado por dominio
- Diseño de arquitectura en capas
Principio de división de AKF
Primero hablemos de los principios más básicos del diseño de microservicios : AKF Scalability Cube
AKF Scalability Cube es un modelo escalable propuesto en el libro "La arquitectura es el futuro". Este cubo tiene tres ejes, y cada eje describe la extensión. Una dimensión de sexo . En teoría, de acuerdo con estos tres modos de expansión, un solo sistema se puede expandir infinitamente.
- Eje X: se refiere a la copia horizontal. Es fácil entender que se trata de ejecutar algunas instancias más del sistema único para hacer un clúster más el modo de equilibrio de carga. Para respaldar mejor esta escalabilidad horizontal, el sistema está mejor diseñado para separar los extremos frontal y posterior y proporcionar servicios sin estado. Este tipo de capacidad de expansión tiene el costo más bajo y la implementación más simple. Es adecuada para la etapa inicial de desarrollo y tiene una baja complejidad comercial. El aumento de la capacidad del sistema puede resolver la mayoría de los problemas.
- Eje Y: se refiere a la división de responsabilidades en la aplicación. Esta parte es lo que a menudo llamamos el modo dividido de microservicios, que se divide en función de diferentes negocios. Este tipo de capacidad de expansión que pertenece al desacoplamiento empresarial puede hacer que el equipo esté más concentrado y resolver el problema de la complejidad del código, pero inevitablemente implicará el aislamiento y la transmisión de los datos subyacentes, por lo que el grado de dificultad es relativamente grande, lo cual es adecuado. para volumen de datos y negocios complejos. Escena de equipos a gran escala.
- Eje Z: se refiere al particionamiento basado en servicios o datos, como el particionamiento por región. Este es el método de expansión más costoso. En general, los sistemas muy grandes tienen requisitos similares. Por ejemplo, cuando un sistema de Internet aumenta repentinamente en volumen de usuarios y es posible que un solo modelo de clúster no pueda llevarlo a cabo, debe ser atendido de acuerdo con el región del usuario y partición de datos. A diferencia de la tabla de subbase de datos tradicional o lógicamente de múltiples inquilinos, las particiones múltiples deben estar separadas físicamente, similar a la arquitectura unificada de la industria financiera en los últimos años, y la idea de múltiples centros de datos. Es adecuado para el rápido crecimiento exponencial de usuarios y se puede dividir de acuerdo con ciertas reglas.
Mientras prestamos atención a la división de los tres ejes de AKF, también debemos pensar en los principios de 3S, a saber: seguridad (seguridad), escala (escala), velocidad (velocidad)
Principios de separación comercial
A continuación, desde la perspectiva del negocio del sistema, hable sobre los principios de división y diseño de los microservicios.
Aclarar la separación de microservicios y principios de diseño; realizar microservicios con las necesidades comerciales como el centro, la alta autonomía y la evolución continua como el objetivo.
Para las llamadas de servicios cruzados, primero considere desde una perspectiva comercial, logre una alta cohesión, un bajo acoplamiento y minimice la ocurrencia de dicho acoplamiento a través del principio de división.
Diseño controlado por dominio
El diseño basado en dominios (DDD: Domain-Driven Design) es un conjunto de métodos de modelado orientados a objetos más avanzados para el análisis y el diseño de sistemas de software. Es muy diferente de la arquitectura tradicional centrada en el diseño basado en datos. El diseño basado en dominios presta más atención al modelo de dominio, entonces, ¿qué es un dominio? Para decirlo sin rodeos, un campo en realidad se refiere a un área de negocios . El diseño impulsado por el dominio tiene como objetivo construir la relación entre el negocio y el negocio, así como la lógica interna del negocio .
En el diseño impulsado por dominios, el primer paso y el más importante es llegar a un consenso. El equipo, que incluye a técnicos, expertos en dominios, gerentes de productos, etc., puede llegar a un consenso sobre el conocimiento comercial relacionado con el campo, de modo que todos puedan ser simples, claro y preciso Describe el significado comercial y las reglas de este campo, este es el lenguaje unificado (lenguaje ubicuo) . Es una forma eficaz de resolver la complejidad empresarial en algunos sistemas de software medianos y grandes al llegar a ese consenso.
Después de tener un lenguaje común, cómo organizar e implementar el modelo de negocio, esta parte es la etapa de Diseño basado en modelos (Diseño basado en modelos) . DDD divide este proceso de diseño de modelos en dos etapas:
- Diseño estratégico
- Diseño táctico
El llamado diseño estratégico, también conocido como diseño de alto nivel, se refiere a la separación del sistema en diferentes dominios, en otras palabras: cuáles son los dominios centrales (competitividad central), cuáles son los dominios generales (no-core compartido , disponible externamente), y que es el dominio de soporte (no es exclusivo del núcleo y puede subcontratarse).
El llamado diseño táctico se refiere a cómo organizar diferentes modelos de negocio de forma específica, es decir: ¿qué roles (entidades, objetos de valor) son estos modelos? ¿Cuál es la relación entre estos modelos (agregación, raíz de agregación)? ¿Cómo colaboran y evolucionan estos modelos (eventos de dominio, servicios de dominio, fábricas, almacenes, servicios de aplicaciones)?
Luego, el modelo de dominio se divide en contextos de límites, y las dependencias entre ellos se identifican para formar un diseño de modelo de dominio similar a la figura anterior, y finalmente el contexto de límites o el modelo de dominio en él se mapea en microservicios.
El diseño impulsado por dominios, un método de diseño orientado a los negocios, encaja de forma natural con los sistemas ágiles de arquitectura de microservicios y desarrollo de hoy.
Diseño de arquitectura en capas
Finalmente, basándonos en los principios y métodos de diseño anteriores, echemos un vistazo al diseño de la arquitectura en capas. Creo que todos deberían estar familiarizados con el diseño en capas, pero cómo aplicar capas en la arquitectura de microservicios, puede consultar la siguiente construcción de etapa intermedia escenarios:
聚合域：聚合中台业务完成业务流程
业务域：提供中台业务能力接口
通用域：提供数据的原子操作接口
La ventaja de la arquitectura en capas es que puede hacer que la relación entre los servicios sea más clara. Trate de no llamarse entre sí al mismo nivel y evite las llamadas entre niveles. La profundidad de toda la cadena de llamadas también debe controlarse dentro de un rango determinado. .
Observaciones finales
No existe el mejor modo de diseño y esquema de arquitectura, solo optimización y evolución continuas del sistema. Es necesario encontrar el cuello de botella del rendimiento del sistema, encontrar el lugar corrupto en el diseño de la arquitectura, encontrar el método factible y luego optimizar y mejorar continuamente la calidad del sistema., El encanto de la arquitectura reside aquí.
"Cada línea de código que escribe es su tarjeta de presentación, y cada error que corrige se cuenta. Esta no es una técnica de programación, este es el arte de programar". - Tributo a "Flying Life"