Bien, sigamos hablando del ensayo del artículo anterior. En el artículo anterior, mencionamos que si queremos actualizar todas las configuraciones de microservicio y actualizar la configuración sin reiniciar, solo podemos confiar en Spring Cloud Config. Sin embargo, necesitamos enviar solicitudes de publicación de un servicio a otro.
¿Podemos soportarlo? Esto es mucho mejor que la falta anterior de centro de configuración. Entonces, ¿cómo podemos seguir evitando enviar solicitudes de publicación al servicio uno por uno para informar el servicio? Su información de configuración ha cambiado y debe modificar la información de configuración en la memoria a tiempo.
En este momento, no debemos olvidar el modelo de suscripción de publicación de la cola de mensajes. Todos los servicios se suscriben a este evento. Cuando cambia este evento, se pueden notificar a todos los microservicios para actualizar su información de configuración de memoria. En este momento, el bus de mensajes de bus puede resolverlo. Solo necesita emitir una actualización en el lado del servidor de configuración de SpringCloud para activar todas las actualizaciones de microservicios.
Como se muestra en el siguiente diagrama arquitectónico:
Además de admitir la configuración automatizada de RabbitMQ, Spring Cloud Bus también es compatible con Kafka, que ahora se usa ampliamente. En este artículo, construiremos un entorno local de Kafka y lo usaremos para intentar usar el bus Spring Cloud para admitir Kafka para implementar la función del bus de mensajes.
Kafka se implementa utilizando Scala y se utiliza como una tubería para el procesamiento de datos activos y de transmisión activa de LinkedIn, y ahora es ampliamente utilizada por muchas compañías de Internet como una transmisión de datos y sistemas de mensajes.
El diagrama de arquitectura de Kafak es el siguiente:
Kafka es un sistema de mensajería implementado basado en el modo de publicación/suscripción de mensajes. Sus principales objetivos de diseño son los siguientes:
1. Persistencia del mensaje: proporcione la capacidad de persistencia del mensaje en una complejidad de tiempo o (1), e incluso los datos por encima del nivel de TB pueden garantizar el rendimiento de acceso con complejidad de tiempo constante.
2. Alto rendimiento: también puede admitir un rendimiento de más de 100k por segundo en máquinas comerciales baratas
3. Distribuido: soporte de partición de mensajes y consumo distribuido, y garantice el pedido de mensajes dentro de la partición
4.
5. En tiempo real: admite procesamiento de datos en tiempo real y procesamiento de datos fuera de línea
6. Escalabilidad: soporte de expansión horizontal
Algunos conceptos básicos involucrados en Kafka:
1.Broker: un clúster Kafka contiene uno o más servidores, que se llaman corredores.
2.Tópico: lógicamente similar a la cola de cola de Rabbit, cada mensaje publicado en el clúster Kafka debe tener un tema. (Los mensajes con diferentes temas se almacenan por separado. Aunque el mensaje lógico de un tema se almacena en uno o más corredores, el usuario solo necesita especificar el tema del mensaje para producir o consumir datos sin preocuparse por dónde se almacenan los datos)
3. Partición: la partición es una partición en el concepto físico. Para proporcionar el rendimiento del sistema, cada tema se dividirá físicamente en una o más particiones, y cada partición corresponde a una carpeta (almacenando el contenido del mensaje y el archivo de índice de la partición correspondiente).
4.Productor: productor de mensajes, responsable de producir mensajes y enviarlos a Kafka Broker.
5.Consumer: consumidor de mensajes, cliente que lee mensajes para Kafka Broker y los procesa.
6. Grupo de consumo: cada consumidor pertenece a un grupo específico (cada consumidor puede especificarse como un grupo y, si no se especifica, pertenece al grupo predeterminado). El grupo puede usarse para implementar funciones como un mensaje que consumen varios miembros en el grupo.
Puede ver en el diagrama de arquitectura de Kafka que Kafka requiere soporte de chokeeper. Debe especificar dónde está Zookeeper en su configuración de Kafka. Proporciona algunas garantías de confiabilidad a través de Zookeeper y es el maestro y esclavo del corredor. También necesitamos saber que los mensajes de Kafka están organizados en forma de tema. Los productores envían mensajes de formulario de tema, y los consumidores se dividen de acuerdo con los grupos, por lo que un grupo de consumidores necesitará los mismos mensajes de formulario de tema. En el lado del servidor, también fabrica algunos fragmentos, por lo que se puede distribuir un tema en diferentes fragmentos, lo que nos facilita expandir e implementar múltiples máquinas. Kafka se distribuye naturalmente. Para la demostración aquí, solo necesitamos usar su configuración predeterminada y hacer una pequeña demostración en Windows.
Nos centramos principalmente en el soporte de Spring Cloud Bus para Kafka, que implementa la función del bus de mensajes. Para colas específicas de mensajes de Kafka y RabbitMQ, esperamos encontrar información para aprenderla usted mismo. Con cierto apoyo conceptual, hacemos algunas demostraciones.
Como sigue: primero, cree un nuevo módulo SpringCloud-Config-Client1 para facilitar nuestras pruebas. Las dependencias introducidas son las siguientes:
<Spendency> <MoupRoupId> org.springframework.boot </groupid> <artifactId> spring-boot-starter-actuator </artifactid> </dependency> <pendency> <grupoD> org.springframework.boot </groupid> <artifactid> spring-boot-starter-web </artifactid> <//dependency> </dependency> <MoupRoD> org.springframework.cloud </groupid> <artifactid> Spring-Cloud-Starter-Config </artifactId> <versión> 1.4.0.release </versions> </dependency> <pendency> <proupid> org.springframe.cloud </groupid> <Atifactid> spring-starter-eure-eureka </arthamworkwork. <Versión> 1.3.5.Release </versión> </pendency> <ependency> <grupoD> org.springframework.cloud </groupid> <artifactid> spring-cloud-starter-bus-kafka </arfactid> <versión> 1.3.2.release </versión> </dependencia>
A continuación, tenga en cuenta que el archivo de configuración de Client1 debe cambiarse a bootstrap.yml, porque se prefiere este formato de configuración. Como se menciona en el ensayo anterior, la configuración de Client1 es la siguiente:
Servidor: Puerto: 7006Spring: Aplicación: Nombre: Cloud-Config Cloud: Config:#¿Qué entorno se utiliza para comenzar? Dev representa el entorno de desarrollo. Esto está relacionado con el sufijo del archivo en su almacén. Por ejemplo, el formato de nomenclatura del archivo de configuración del almacén es la nube-config-dev.properties, por lo que el perfil debe escribirse perfil de dev: Descubrimiento: habilitado: Verdadero# Este nombre es el nombre de servicio del lado del servidor de configuración, y no puede escribirlo a ciegas. Service-ID: config-server#registro centro eureka: cliente: servicio-url: defaultzone: http: // localhost: 8888/eureka/, http: // localhost: 8889/eureka/#¿Es necesario extraer el permiso? El valor predeterminado es verdadero. Si no es falso, no se le permitirá extraer el contenido actualizado por la gestión del servidor del centro de configuración: Seguridad: habilitado: FALSO
Luego comience la clase de la siguiente manera:
@SpringBootApplication@EngabledScoveryClientPublic Class Client1Application {public static void main (string [] args) {springApplication.run (client1application.class, args); }}Luego asigne una copia del testController en el cliente al cliente1, el código es el siguiente:
@RestController // Las propiedades aquí pueden actualizarse. Si el centro de configuración en GIT cambia, debe actualizarse. Sin esta anotación, la configuración no se puede actualizar en el tiempo @refreshscopePublic de clase TestController {@Value ("$ {name}") Nombre de cadena privada; @Value ("$ {edad}") edad entera privada; @RequestMapping ("/test") public String test () {return this.name+this.age; }}Luego agregue la siguiente configuración al servidor de configuración en el módulo en el ensayo anterior:
#Si se requiere permiso para extraer, el valor predeterminado es verdadero. Si no es falso, no se le permitirá extraer el contenido actualizado por la gestión del servidor del centro de configuración: Seguridad: habilitado: FALSO
A continuación, debemos hacer una cosa: config-client, config-client1 y config-servir deben introducir dependencias de kafka, de la siguiente manera:
<Spendency> <ProupId> org.springframework.cloud </groupid> <artifactid> spring-ncloud-starter-bus-kafka </arfactid> <ververy> 1.3.2.release </versión> </pendency>
Nuestro proyecto está listo, por lo que lo pondremos aquí por el momento. Instalemos y descargemos Kafka a continuación. Primero, vamos al sitio web oficial de Kafka kafka.apache.org/downloads para ir a la versión recomendada en el sitio web oficial.
Primero, ingresamos el directorio de Kafka descargado y editamos kafka-run-class.bat en kafka_2.11-1.1.0/bin/windows de la siguiente manera:
Encuentre esta configuración de la siguiente manera:
Copie el código de la siguiente manera: set command =%java%%kafka_heap_opts%%kafka_jvm_performance_opts%%kafka_jmx_opts%%kafka_log4j_opts%-cp%classpath%%kafka_opts%*
Puede ver que % classpath % no tiene cotizaciones dobles.
Por lo tanto, adjuntarlo en cotizaciones dobles, de lo contrario no se puede iniciar. Se informa que su JDK no está instalado correctamente. Después de la modificación, es el siguiente:
Copie el código de la siguiente manera: set command =%java%%kafka_heap_opts%%kafka_jvm_performance_opts%%kafka_jmx_opts%%kafka_log4j_opts%-cp "%classpath%"%kafka_opts%*%*
A continuación, abra el servidor.properties en la carpeta de configuración y configúrela de la siguiente manera:
Puede ver que está conectado al Zookeeper local.
Luego comenzamos primero Zookeeper, y luego Kafka, como sigue:
Cuando ve la información anterior, demuestra que la startup de Zookeeper es exitosa. ,
A continuación, comience a Kafka con otro CMD, como sigue:
Ver esta información significa que Kafka ha sido lanzado con éxito
Ok, comencemos el proyecto anterior, dos centros de registro, un servidor SpringCloud-Config, dos SpringCloud-Config-Client y SpringCloud-Config-Client1.
Puedes ver que SpringCloudbus está en el fragmento 0. Si la información anterior aparece en ambos Clientes de configuración, demuestra que el inicio es exitoso.
Ok, ahora accedamos al lado del servidor de configuración, como sigue:
Visite dos clientes más, como sigue:
Bien, el espectáculo ha comenzado. Ahora vamos al repositorio Git para modificar el archivo del centro de configuración y cambiar la edad a 24, de la siguiente manera:
A continuación, utilizamos actualización para actualizar la configuración del servidor de configuración y notificar a los dos clientes que actualicen la información de configuración en la memoria. Use Postman para enviar localhost: 7000/bus/actualización, de la siguiente manera:
Puede ver que no se devuelve ninguna información, pero no se preocupe, esta es una notificación exitosa para todos los clientes para actualizar la información en la memoria.
Luego rehacimos el servidor de configuración y dos clientes para actualizar la página, y el resultado es el siguiente:
Los dos clientes son los siguientes:
Puede ver que todos los clientes actualican automáticamente la información de configuración en la memoria.
Hasta ahora, lo anterior ha actualizado la información de configuración. También está bien si queremos actualizar la información de configuración de un servicio específico. Podemos especificar el rango de actualización de la siguiente manera:
Especificar el rango de actualización
En el ejemplo anterior, activamos /refresh para otras instancias de servicio en el bus solicitando la interfaz Spring Cloud Bus /bus/refresh desde la instancia del servicio. Sin embargo, en algunos escenarios especiales (como la versión en escala de grises), esperamos actualizar la configuración de una instancia específica en el microservicio.
Spring Cloud Bus también tiene un buen soporte para este escenario: /bus/refresh también proporciona parámetros destination para localizar la aplicación específica para actualizar. Por ejemplo, podemos solicitar /bus/refresh?destination=服务名字:9000 . En este momento, cada instancia de la aplicación en el bus determinará si es su propio nombre de instancia en función del valor del atributo destination .
Si se cumple la configuración, la configuración se actualizará. Si la configuración no coincide, el mensaje será ignorado.
Además del posicionamiento de instancias específicas, los parámetros destination también se pueden utilizar para posicionar servicios específicos. El principio de los servicios de posicionamiento se implementa utilizando PathMateCer de Spring, por ejemplo: /bus/refresh?destination=customers:** , que desencadenará todas las instancias del servicio customers para actualizar.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.