Tabla de contenido
La evolución de los patrones de arquitectura de software
El dilema del diseño y la separación de microservicios
¿Por qué DDD es adecuado para microservicios?
DDD incluye dos partes: diseño estratégico y diseño táctico.
Podemos utilizar tres pasos para delinear el límite entre el modelo de dominio y los microservicios.
Sabemos que el proceso de diseño de microservicios a menudo enfrenta el problema de cómo delimitar los límites. A menudo veo equipos de proyecto discutiendo sobre cómo desmantelar los microservicios pequeños. Diferentes personas dividirán diferentes microservicios según su propia comprensión de los microservicios, por lo que todos insisten en sus propias opiniones, nadie puede convencer a nadie y todos sienten que son muy razonables.
En el proceso de implementación real, de hecho he visto que muchos proyectos se completan dándose palmaditas en la cabeza cuando se enfrentan a este tipo de confusión en el diseño de microservicios. Se puede imaginar la presión de operación y mantenimiento después de estar en línea. ¿Existe una teoría o método de diseño adecuado para guiar el diseño de microservicios? Cuando veas el título de esta conferencia, creo que ya sabes la respuesta.
Así es, es DDD. Así que hoy les daré una explicación detallada: "¿Por qué debería elegirse el diseño basado en dominios para el diseño de microservicios?"
La evolución de los patrones de arquitectura de software
A lo largo de los años, con el desarrollo de equipos y nuevas tecnologías, el modelo arquitectónico del software ha cambiado mucho. En términos generales, el patrón de arquitectura de software ha experimentado tres etapas de evolución desde una arquitectura de microservicio independiente y centralizada hasta una arquitectura de microservicio distribuida. Con el rápido aumento de la tecnología distribuida, hemos entrado en la era de la arquitectura de microservicios.
Primero analicemos las tres etapas de la evolución de los patrones de arquitectura de software.
La primera etapa es una arquitectura independiente : utilizando un método de diseño orientado a procesos, el sistema incluye dos capas de capa de interfaz de usuario del cliente y base de datos, utilizando el modo de arquitectura C/S, todo el sistema está diseñado y desarrollado alrededor del controlador de la base de datos y siempre comienza. desde el diseño de base de datos y campos.
La segunda etapa es la arquitectura centralizada: utilizando un método de diseño orientado a objetos, el sistema incluye una capa de acceso empresarial, una capa de lógica empresarial y una capa de base de datos, utilizando la arquitectura clásica de tres niveles, y algunas aplicaciones adoptan la arquitectura SOA tradicional. Esta arquitectura tiende a inflar el sistema, con poca escalabilidad y escalabilidad elástica.
La tercera etapa es la arquitectura de microservicios distribuidos : con la introducción del concepto de arquitectura de microservicios, la arquitectura centralizada está evolucionando hacia la arquitectura de microservicios distribuidos. La arquitectura de microservicios puede lograr el desacoplamiento entre aplicaciones y resolver el problema de la escalabilidad insuficiente y la escalabilidad elástica de aplicaciones individuales.
Sabemos que en la era de las arquitecturas independientes y centralizadas, el análisis, el diseño y el desarrollo de sistemas a menudo se llevan a cabo de forma independiente y por etapas.
Por ejemplo, en el proceso de construcción de un sistema, a menudo vemos una situación de este tipo: A es responsable de proponer requisitos, B es responsable del análisis de requisitos, C es responsable del diseño del sistema y D es responsable de la implementación del código. provocar pérdida de información. Al final, es fácil causar inconsistencias entre los requisitos, el diseño y la implementación del código. A menudo, después de iniciar el software, encontramos que muchas funciones no son lo que queremos o que las funciones que creamos se desvían demasiado de nuestros propios requisitos.
Además, bajo los dos modos de arquitectura independiente y centralizada, el software no puede responder rápidamente a los cambios rápidos en la demanda y el negocio y, en última instancia, pierde la oportunidad de desarrollo. En este momento, la aparición de microservicios distribuidos es un poco en el momento adecuado.
El dilema del diseño y la separación de microservicios
Después de ingresar a la era de la arquitectura de microservicios, los microservicios de hecho han resuelto muchos problemas de la aplicación única original con arquitectura centralizada, como escalabilidad, escalabilidad elástica, desarrollo ágil de equipos a pequeña escala, etc.
Pero al ver estos beneficios, también ha habido muchos debates y dudas en la práctica de los microservicios: ¿Qué tan grande debe ser la granularidad de los microservicios? ¿Cómo deberían dividirse y diseñarse los microservicios? ¿Dónde deberían estar los límites de los microservicios?
Se puede decir que durante mucho tiempo no ha existido un conjunto de teorías y métodos sistemáticos para guiar la división de microservicios, incluido Martin Fowler, el proponente del modelo de arquitectura de microservicios, cuando propuso la arquitectura de microservicios, no dijo Cuéntenos cómo dividir los microservicios.
Por lo tanto, durante este largo período de tiempo, muchas personas han entendido mal la comprensión de los microservicios. Algunas personas piensan: "Los microservicios son muy simples, pero es solo dividir el paquete único original en múltiples paquetes de implementación o reemplazar la arquitectura de aplicación única original con un conjunto de marcos técnicos que admitan la arquitectura de microservicios, incluso si es un microservicio. " Algunas personas dijeron: "Microservicios, es decir, deben ser micro y pequeños. Cuanto menor sea la demolición, mejor será el efecto".
Pero creo que en los últimos dos años, debe haber oído hablar de algunos proyectos en el círculo tecnológico debido a la división excesiva de los microservicios en la etapa inicial, lo que hizo que el proyecto fuera demasiado complejo e incapaz de conectarse, operar y mantener.
En general, creo que la causa fundamental del dilema de la división de microservicios es no saber dónde están los límites de los negocios o los microservicios. En otras palabras, una vez que se determinen los límites comerciales y de aplicación, este dilema se resolverá.
Entonces, ¿cómo determinar si existe un respaldo relevante de una teoría o un sistema de conocimiento? Antes de responder estas preguntas, echemos un vistazo al pasado y al presente del diseño y los microservicios basados en dominios.
En 2004, Eric Evans (Eric Evans) publicó el libro "Domain-Driven Design - Tackling Complexity in the Heart of Software", del cual nació Domain Driven Design (DDD para abreviar). La idea central de DDD es definir el modelo de dominio a través del método de diseño impulsado por el dominio, para determinar los límites del negocio y la aplicación y garantizar la coherencia entre el modelo de negocio y el modelo de código.
Sin embargo, después de que se propuso DDD, ¡siempre ha sido "atronador, pero lluvioso" en el campo del desarrollo de software! No fue hasta que Martin Fowler propuso la arquitectura de microservicios que DDD realmente marcó el comienzo de su propia era.
Algunos ingenieros de software que están familiarizados con el método de diseño DDD descubren que pueden utilizar el método de diseño DDD para establecer un modelo de dominio al diseñar microservicios, dividir los límites del dominio y luego dividir los límites del microservicio desde una perspectiva empresarial basada en estos límites de dominio. Sin embargo, los límites comerciales y de aplicación de los microservicios diseñados según el método DDD son muy razonables, lo que bien puede lograr "alta cohesión y bajo acoplamiento" dentro y fuera de los microservicios. Por eso, cada vez más personas comenzaron a utilizar DDD como ideología rectora del diseño de microservicios.
Ahora, muchas grandes empresas de Internet han adoptado el método de diseño DDD como método de diseño principal para microservicios. DDD también ha comenzado a calentarse mucho debido al pasado "grandes truenos, poca lluvia".
¿Por qué DDD es adecuado para microservicios?
"Lo busqué miles de veces entre la multitud. Al mirar atrás, de repente, el hombre estaba en un lugar con poca luz. "Después de años de confusión y disputas, Microservice finalmente encontró a su amada.
Entonces, ¿dónde es sagrado el DDD y qué artefacto tiene?
DDD es una idea de diseño para abordar campos altamente complejos, intenta separar la complejidad de la implementación técnica y construye un modelo de dominio en torno a conceptos comerciales para controlar la complejidad del negocio, a fin de resolver el problema de que el software es difícil de entender. y difícil de evolucionar. DDD no es una arquitectura, sino una metodología de diseño de arquitectura que simplifica dominios comerciales complejos a través de la división de límites, nos ayuda a diseñar límites claros de dominios y aplicaciones y puede realizar fácilmente la evolución de la arquitectura.
DDD incluye dos partes: diseño estratégico y diseño táctico.
El diseño estratégico comienza principalmente desde la perspectiva empresarial, establece un modelo de dominio empresarial, divide los límites del dominio y establece un contexto acotado para un lenguaje común, que se puede utilizar como límite de referencia para el diseño de microservicios.
El diseño táctico comienza desde una perspectiva técnica, se centra en la realización técnica del modelo de dominio y completa el desarrollo y la implementación del software, incluido el diseño y la implementación de la lógica del código para raíces agregadas, entidades, objetos de valor, servicios de dominio, servicios de aplicaciones y recursos. bibliotecas.
Echemos un vistazo a cómo DDD realiza el diseño estratégico.
El diseño estratégico de DDD establecerá un modelo de dominio que se puede utilizar para guiar el diseño y la división de microservicios. La tormenta de eventos es el método principal para construir un modelo de dominio, es un proceso de divergencia a convergencia. Por lo general, utiliza análisis de casos de uso, análisis de escenarios y análisis del recorrido del usuario para descomponer el dominio empresarial de la manera más completa posible y ordenar la relación entre los objetos del dominio, lo que constituye un proceso divergente. El proceso de tormenta de eventos generará muchos objetos de dominio, como entidades, comandos y eventos. Agrupamos estos objetos de dominio de diferentes dimensiones para formar límites como agregación y contexto acotado, y establecemos modelos de dominio. Este es un proceso convergente.
Podemos utilizar tres pasos para delinear el límite entre el modelo de dominio y los microservicios.
Paso 1: clasifique las operaciones del usuario, los eventos y las dependencias externas en el proceso de negocio en la tormenta de eventos y clasifique los objetos de dominio, como las entidades de dominio, en función de estos elementos.
Paso 2: De acuerdo con la correlación comercial entre las entidades de dominio, combine entidades estrechamente relacionadas con el negocio para formar una agregación y determine la raíz de la agregación, el objeto de valor y la entidad en la agregación. En esta figura, el límite entre agregados es el límite de la primera capa, se ejecutan en la misma instancia de microservicio, este límite es un límite lógico, por lo que está representado por una línea de puntos.
Paso 3: De acuerdo con factores como los límites comerciales y semánticos, defina uno o más agregados en un contexto acotado para formar un modelo de dominio. En esta figura, el límite entre contextos acotados es el límite de la segunda capa, que puede ser el límite de futuros microservicios. La lógica de dominio en diferentes contextos acotados está aislada y se ejecuta en diferentes instancias de microservicios, interactuando físicamente entre sí. Aislamiento, por lo que es un límite físico y el límite está representado por una línea continua.
Con estas dos capas de límites, el diseño de microservicios no es difícil.
En el diseño estratégico, establecimos el modelo de dominio, delineamos los límites del dominio comercial, establecimos un lenguaje común y un contexto delimitado, y determinamos la relación entre varios objetos de dominio en el modelo de dominio. En este punto, el diseño del modelo de dominio del lado empresarial está básicamente completado, y este proceso también determina básicamente los límites de los microservicios en el lado de la aplicación. En el proceso de pasar del modelo de negocio al microservicio, es decir, del diseño estratégico al diseño táctico, estableceremos una relación de mapeo entre los objetos de dominio en el modelo de dominio y los objetos de código en el modelo de código, e integraremos la arquitectura empresarial y sistema El esquema está vinculado. Cuando ajustamos la arquitectura empresarial y el modelo de dominio en respuesta a los cambios comerciales, la arquitectura del sistema también se ajustará al mismo tiempo y se establecerá una nueva relación de mapeo simultáneamente.
La relación entre DDD y microservicios es
Con la explicación anterior, ahora también podríamos resumir nuevamente la relación entre DDD y los microservicios.
DDD es un método de diseño arquitectónico y el microservicio es un estilo arquitectónico. Ambos son esencialmente medios para lograr una alta capacidad de respuesta y separar la complejidad de la construcción del sistema de aplicaciones desde una perspectiva empresarial. Ambos enfatizan comenzar desde el negocio, y su esencia central es enfatizar la división racional de los límites del dominio de acuerdo con el desarrollo del negocio, ajustar continuamente la arquitectura existente y optimizar el código existente para mantener la vitalidad de la arquitectura y el código, que es lo que hacemos. A menudo se le llama arquitectura evolutiva.
DDD se centra principalmente en dividir los límites del dominio desde la perspectiva del dominio empresarial, construir un lenguaje común para una comunicación eficiente, establecer modelos de dominio a través de la abstracción empresarial y mantener la coherencia lógica entre el negocio y el código.
Los microservicios se centran principalmente en: comunicación entre procesos, tolerancia a fallos y aislamiento de fallos en tiempo de ejecución, realización de gestión de datos descentralizada y gobernanza de servicios descentralizada, y se centran en el desarrollo, las pruebas, la construcción y la implementación independientes de microservicios. Establezca un modelo de dominio para mantener la coherencia lógica del negocio y el código. Los microservicios se centran principalmente en: comunicación entre procesos, tolerancia a fallos y aislamiento de fallos en tiempo de ejecución, realización de gestión de datos descentralizada y gobernanza de servicios descentralizada, y se centran en el desarrollo, las pruebas, la construcción y la implementación independientes de microservicios.
Resumir
En general, DDD puede brindarle los siguientes beneficios:
1. DDD es un método de diseño completo y sistemático, que puede brindarle un proceso de diseño estándar desde el diseño estratégico hasta el diseño táctico, haciendo que sus ideas de diseño sean más claras y el proceso de diseño más estandarizado.
2. DDD es bueno para abordar el desarrollo de productos relacionados con dominios en negocios de alta complejidad y, a través de él, puede establecer un modelo de dominio central y estable que favorezca la transferencia y herencia del conocimiento del dominio.
3. DDD enfatiza la cooperación entre el equipo y los expertos en el dominio, lo que puede ayudar a su equipo a establecer una buena atmósfera de comunicación y construir un sistema de arquitectura consistente.
4. Las ideas, principios y patrones de diseño de DDD ayudan a mejorar sus capacidades de diseño arquitectónico.
5. Ya sea que esté diseñando microservicios en un nuevo proyecto o haciendo evolucionar el sistema de una arquitectura única a microservicios, puede seguir los principios arquitectónicos de DDD.
6. DDD no solo es aplicable a microservicios, sino también a aplicaciones monolíticas tradicionales.