Flor de marco de microservicio reactivo

Flower es a la vez un marco de programación reactivo y un marco de microservicios distribuidos.

El marco Flower permite a los desarrolladores obtener un sistema reactivo sin prestar atención a los detalles de la programación reactiva.

Inicio rápido

Los elementos principales del marco floral incluyen: servicio floral, flujo floral y contenedor de flujo. El servicio implementa una función de servicio detallada y el servicio está asociado a través de mensajes. El valor de retorno (Mensaje) del servicio anterior debe ser el parámetro de entrada (Mensaje) del último servicio. Los servicios se editan en flujos (procesos) de acuerdo con la lógica empresarial, y el contenedor de flores es responsable de pasar el mensaje de retorno del servicio anterior al siguiente servicio.

Fijo

Experto

Gradler

SBT

Ivy

Inicialización de flores

Flower debe inicializarse antes de poder usarse. Aquí se demuestra el método más simple.

Inicialización de Flower

Definir el servicio de Flower

El desarrollo de clases de servicio debe implementar la interfaz de servicio del framework Flower o heredar la clase base AbstractService y completar el servicio. negocio dentro del método de proceso Procesamiento lógico.

Servicio de usuario a

Servicio de usuario b

Servicio de usuario C1

Registro de servicio

Flor proporciona dos Tres Métodos de registro del servicio: método de archivo de configuración y método programático.

Disposición del proceso de servicio

El marco Flower proporciona dos métodos de disposición del proceso de servicio: método de archivo de configuración y método de programación.

Los resultados de los dos arreglos son los mismos:

El proceso llamado flor

Se definen tres servicios Flower y se organiza un flujo de servicio llamado flower_test. Entonces, ¿cómo usarlo?

Ejemplo completo

En Flower, los mensajes son ciudadanos de primera clase y los sistemas de aplicaciones basados ​​en Flower son sistemas de aplicaciones orientados a mensajes. El mensaje es generado por el servicio y es el valor de retorno del servicio; al mismo tiempo, el mensaje también es la entrada del servicio. El mensaje de retorno del servicio anterior es el mensaje de entrada del siguiente servicio. Los servicios desacoplados se asocian mediante mensajes para formar un proceso de servicio y, finalmente, se construye un sistema de aplicación con capacidades de procesamiento completas. Ejemplo de proceso:

Término

Patrón de procesamiento de información de flores

Además de encadenar servicios para formar un proceso en serie simple, los mensajes también se pueden combinar para crear más Función poderosa.

Bifurcación de mensajes

Bifurcación de mensajes significa que los mensajes generados por un servicio pueden bifurcarse y distribuirse a uno o más servicios. Hay dos métodos de procesamiento para mensajes después de la bifurcación: distribución completa y distribución condicional.

Distribuir todo

Distribuir el mensaje de salida a todos los servicios de seguimiento del proceso. Después de recibir el mensaje, los servicios posteriores lo ejecutan en paralelo. Este modo se utiliza principalmente para múltiples subtareas que se pueden ejecutar en paralelo. Por ejemplo, después de que un usuario se registra exitosamente, es necesario 1. escribir los datos del usuario en la base de datos; 2. enviar un correo electrónico de activación al usuario; 3. enviar un mensaje de notificación al usuario; 4. enviar el registro del nuevo usuario; información al producto relevante para la apertura de cuenta. Los cuatro servicios anteriores pueden adoptar el modo de distribución de mensajes para aceptar mensajes de registro de usuario y completar las cuatro tareas anteriores al mismo tiempo.

Para lograr una distribución completa de mensajes, la configuración debe realizarse en el proceso. Todos los servicios que necesitan aceptar mensajes salientes del servicio predecesor deben configurarse en el proceso. p>Service1 es el servicio predecesor, el servicio 2 y el servicio3 son servicios sucesores.

Si se especifican genéricos en la declaración de la interfaz de servicio en la definición de clase que implementa servicio2 y servicio3, el tipo genérico debe ser el tipo de salida de servicio1 o su clase principal.

Servicio 1

Servicio 2

Servicio 3

Distribución condicional

A veces, según el contenido del mensaje y negocios Lógicamente, los mensajes generados por el primer servicio pueden entregarse al segundo servicio para su procesamiento, pero no todos los servicios. Por ejemplo, cuando un usuario solicita un préstamo, después de que el servicio actual calcula la calificación crediticia del usuario, necesita determinar qué tipo de método de préstamo utilizar o rechazar el préstamo según la calificación crediticia. Los diferentes métodos de préstamo y los rechazos de préstamos son servicios diferentes. Estos servicios deben configurarse como servicios sucesores del servicio predecesor durante la configuración del proceso, pero en tiempo de ejecución deciden distribuir mensajes a servicios sucesores específicos según las condiciones.

La distribución condicional es igual que todas las distribuciones en la configuración del proceso. Todos los posibles servicios posteriores deben configurarse en el proceso. Hay tres formas de implementar la distribución condicional.

Asignación basada en genéricos

Cuando un servicio posterior implementa la interfaz, declara un tipo genérico diferente. El servicio predecesor construye diferentes tipos de mensajes según la lógica empresarial. Hua buscará el servicio correspondiente según el tipo de mensaje y solo se enviarán los mensajes que coincidan correctamente. Por ejemplo:

Proceso de construcción

Declarar que el tipo de mensaje aceptado por ServicioB es MensajeB.

Servicio a

ServicioB es el servicio de seguimiento del ServicioA. Si el mensaje recibido por ServiceA es la cadena "b", se devuelve el tipo de mensaje b. En este momento, el marco enviará el mensaje a ServiceB en lugar de a ServiceC.

Especifique el ID del servicio posterior en el mensaje a distribuir.

El mensaje de preámbulo implementa la interfaz condicional y especifica la identificación del servicio posterior, por ejemplo:

En términos generales, los servicios son reutilizables y se pueden reutilizar en diferentes procesos, pero los servicios posteriores Puede ser diferente en diferentes procesos y los ID de servicios posteriores también pueden ser diferentes. Obviamente, escribir la identificación de servicios posteriores en el servicio no favorece la reutilización del servicio. Hay dos soluciones. Una es escribir un servicio específicamente para distribución en un proceso diferente, es decir, el servicio que maneja la lógica empresarial no se preocupa por la distribución de mensajes y solo devuelve el contenido del mensaje, pero su servicio sucesor es un servicio específicamente para la distribución de mensajes. Este servicio no tiene lógica empresarial y solo implementa interfaces condicionales para especificar servicios posteriores según el contenido del mensaje.

La otra es utilizar el servicio integrado ConditionService del marco para la distribución de mensajes.

Utilice el servicio de condiciones de servicio integrado del marco para la distribución de mensajes.

ConditionService es un servicio de distribución de mensajes generales.

El servicio serviceE distribuye mensajes a serviceF o serviceG según las condiciones. La configuración del proceso es la anterior, con serviceCondition agregado en el medio para su adaptación. El método de registro del servicio de serviceCondition es

El servicio de condición mon Com.ly.train.flower.com es un servicio integrado en el marco.

De esta manera, aún necesita configurar las condiciones para devolver mensajes en el servicio front-end Serviceee de serviceCondition, pero no necesita configurar la identificación del servicio posterior. el número de serie del servicio posterior.

Para ver varios ejemplos de código de distribuciones condicionales, consulte /flower.sample/src/main/Java/com/ly/train/flower/common/sample/condition/sample.Java.

Agregación de mensajes

Para todas las ramas de mensajes distribuidos, el propósito común es permitir que múltiples servicios se ejecuten en paralelo y acelerar el procesamiento.

A menudo es necesario obtener todos los resultados de estos servicios de procesamiento paralelo para su posterior procesamiento. En Flower, obtener los mensajes resultantes de múltiples servicios de procesamiento paralelo se denomina agregación de mensajes. El método de implementación es el siguiente: en el proceso, configure el servicio posterior de múltiples mensajes para agregarlo como servicio agregado com.ly.train.flower.com, que es un servicio integrado en el marco. responsable de agregar múltiples generación de servicios paralelos. El mensaje se encapsula en un objeto de colección y se devuelve. Como el proceso

Aquí, el servicio5 es un servicio de agregación de mensajes, responsable de agregar los mensajes generados por el servicio2 y el servicio3 paralelos, y enviar el mensaje Set agregado al servicio4. La configuración del servicio es la siguiente: service5 está configurado como el servicio AggregateService integrado del marco.

Service4 es responsable de recibir y procesar mensajes agregados, tomando mensajes de la colección y procesándolos por separado.

Respuesta de mensaje

Todos los mensajes en Huazhong se procesan de forma asincrónica, es decir, los servicios no se bloquearán ni esperarán entre sí, logrando así una respuesta de bajo acoplamiento, sin bloqueo y alta concurrencia. sistema de fórmulas. Después de que la persona que llama del proceso Flower envía un mensaje de solicitud, el mensaje se procesa en el proceso y la persona que llama puede continuar realizando otras tareas informáticas sin bloquear la espera de resultados.

A diferencia de la programación imperativa tradicional, normalmente el iniciador del proceso no es el destinatario final de los resultados del procesamiento del proceso. Por ejemplo, para el desarrollo web, el iniciador del proceso suele ser un servlet, pero el navegador o la aplicación del cliente en realidad acepta los resultados del procesamiento. El servicio en el proceso puede enviar los resultados del procesamiento directamente al cliente sin pasar por un servlet. Es decir, llamar al servlet iniciador no necesita esperar el resultado del procesamiento final del servicio de proceso. Después de enviar una solicitud de usuario al proceso, no es necesario bloquear el proceso en espera y puede obtener inmediatamente la solicitud de otro usuario. continuar procesando.

Pero Flower también permite que la persona que llama bloquee y espere el resultado del procesamiento del mensaje. El modo de respuesta de mensaje permite que la persona que llama al proceso obtenga el mensaje del resultado final del procesamiento del proceso. Ejemplo de código de referencia/flower sample/src/main/Java/com/ly/train/flower/common/sample/textflow/sample Java.

Modelo de desarrollo de red Flower

Modelo de desarrollo web del servicio de integración Flower 3

Flower admite el modo asincrónico de Servlet3. El hilo de procesamiento de solicitudes llama al proceso Flower y. pasa en el AsyncContext El objeto se libera inmediatamente. Referencia de ejemplo de código/flower.sample/src/main/Java/com/ly/train/flower/common/sample/web/async/async servlet.Java.

Para desarrollar un servicio Flower que admita Servlet3, debe implementar la interfaz de servicio del marco y generar una excepción en el proceso del objeto del método (mensaje t, contexto de servicio que pasará el marco Flower); un objeto web a través del contexto. getWeb() obtiene el objeto web, obtiene los parámetros de la solicitud y genera el resultado de la respuesta del procesamiento.

Modo de desarrollo de Flower que integra Spring boot

Flower admite el desarrollo de Spring boot. En el proyecto, basándose en flower.web, la interfaz de servicio y la interfaz InitController se implementan en el marco. Inicialice @BindController para anotar los parámetros requeridos Al compilar, @BindController será anotado automáticamente por la enumeración flower.web para generar el controlador requerido por Spring boot.

Nota: flower.web utiliza anotaciones para generar las clases de controlador necesarias para el arranque de primavera para el servicio. Este proceso de generación se completa cuando se compila el programa. Si el entorno IDE no admite la compilación en caliente, debe ejecutar mvn install para generar código en la línea de comando.

Para ver ejemplos de códigos, consulte /flower.sample/src/main/Java/com/ly/train/flower/common/sample/spring boot.

Sugerencias de desarrollo para el uso de puestos de flores

Arquitectura de implementación distribuida de flores

Método de reproducción cromática

1 Inicie el centro de registro de Flower.center. .

2. Desarrollar servicios de flores, iniciar el servicio comercial de contenedores de flores y registrar automáticamente el servicio en el centro de registro.

3. Desarrollar Flowerweb Gateway, iniciar el servicio Flower web Gateway y organizar el proceso.

1. Centro de registro

Flower.center está desarrollado en base a spring-boot y se puede iniciar desde la línea de comandos después de empaquetarlo en fat-jar.

Entrada de inicio del registro de flores/centro de flores/src/main/Java/com/ly/train/flower/center/center comando de inicio del registro de flores de Java Java-jar center-0.1 .2. .jar

2. Inicie el contenedor de flores empresarial

La implementación de flores admite el contenedor de flores y el contenedor Spring. El siguiente ejemplo se basa en la demostración de arranque de primavera.

2.1 Crear el archivo de configuración flower.yml

2.2 Configurar FlowerFactory

2.3 Desarrollo del servicio de flores

2.4 Crear una clase de inicio

p>

3. Inicie el servidor de puerta de enlace y programe el proceso.

3.1 Crear flower.yml

3.2 Configurar FlowerFactory

3.3 Desarrollar el servicio de flores

3.4 Desarrollar el controlador de puerta de enlace

3.5 Clase de inicio

Ejemplo de detalles del proyecto

Instancia distribuida de flores/leeyazou/flower showcase git

Conceptos básicos

Flower Factory.

Utilice el FlowerFactory predeterminado.

Crea tu propia fábrica de flores bajo demanda. La ruta predeterminada del archivo de configuración es classpath: flower.yml y el formato de contenido del archivo de configuración es estilo yaml. Consulte Información de configuración para obtener más detalles.

Después de obtener FlowerFactory, puede usar la interfaz que proporciona:

Enrutador de proceso FlowRouter Una vez creado el proceso, puede crear el enrutador correspondiente a través de FlowerFactory y luego puede llamar. el servicio.

Información de configuración distribuida

Flower.yml

Comprender el diseño interno de Flower le ayudará a utilizar mejor Flower para desarrollar sistemas de reacción.

Diseño del módulo central de Flower (marco de microservicio de flujo en proceso)

Flower se desarrolla en base al Actor de Akka y el servicio está encapsulado en el Actor. Los mensajes recibidos por los participantes se pasan al servicio como parámetros de la llamada y la salida del servicio se envía a los participantes posteriores como entrada del servicio.

Clase principal de Flower

Inicialización de Flower y sincronización de llamadas

Inicialización del proceso de servicio

Procesamiento de flujo de mensajes

Flower Hasta aquí el diseño central. Sin embargo, los métodos de aplicación y los patrones de diseño extendidos a partir de esto son muy diferentes de los de Akka.

Diseño del marco de microservicios de medios de transmisión distribuida

El marco de microservicios distribuido tradicional realiza el desacoplamiento y la implementación distribuida de servicios a través de invocación remota, lo que permite el desarrollo del sistema, el mantenimiento y la reutilización de servicios. Es más conveniente y flexible, pero este tipo de microservicio todavía tiene muchas deficiencias.

Flower es un marco de microservicios de streaming dedicado a construir una nueva arquitectura de microservicios. Utilizando las ideas arquitectónicas de la computación de flujo, se desarrolla e implementa un sistema de microservicio que es liviano, fácil de diseñar y desarrollar, impulsado por mensajes, débilmente dependiente y con concurrencia asincrónica.

Estructura

Modelo de implementación

Flower administra y controla uniformemente todo el clúster del sistema de aplicaciones, y el centro de control controla y administra todos los recursos del clúster.

El agente se implementa en cada servidor del clúster y es responsable de cargar instancias de servicio e informar el estado al centro de control.

El almacén de código es responsable de administrar el paquete Java del servicio y el paquete está encapsulado con ensamblador.

El centro de control y el agente se desarrollan en base a Akka. Cada servicio está encapsulado en un actor, y el actor es responsable de la comunicación del mensaje.

Modelo de tiempo de inicio del clúster e implementación de servicios

Estructura de datos de servicios registrados

Las dependencias entre servicios se organizan en el centro de control.