¿Cómo diseñar un middleware de mensajes? La arquitectura general del middleware de mensajes.

Concepto MQ

1. Mensaje

El mensaje es el concepto más pequeño en MQ, que es esencialmente un dato. Puede ser entendido por una o más aplicaciones, y es un soporte de información que se pasa entre las aplicaciones.

2. Cola

2.1 Cola local

La cola local se puede dividir en cola de inicialización, cola de transmisión, cola de destino y cola de letra muerta según la función.

La cola de inicialización se utiliza como una función de activación de mensajes.

La cola de transmisión solo almacena temporalmente el mensaje a transmitir. Cuando las condiciones lo permiten, el mensaje se transmite a otros gestores de colas a través de la canalización.

La cola de destino es el destino de los mensajes y puede almacenar mensajes durante mucho tiempo.

Si el mensaje no se puede entregar a la cola de destino y ya no se puede enrutar, se coloca automáticamente en la cola de mensajes no entregados para su almacenamiento.

2.2 Cola de alias y cola remota

Es solo una definición de cola, utilizada para especificar la cola del gestor de colas remoto. Usando una cola remota, el programa no necesita conocer la ubicación de la cola de destino.

2.3 Cola modelo

La cola modelo define una combinación de atributos de cola local. Una vez que se abre la cola modelo, el gestor de colas creará dinámicamente una cola local basada en estos atributos.

3. Administrador de colas (Administrador de colas)

Un gestor de colas es una organización responsable de proporcionar servicios de mensajes a las aplicaciones. Si el gestor de colas se compara con una base de datos, la cola es una de las tablas.

4. Canal

Un canal es una conexión de comunicación punto a punto unidireccional entre dos administradores.Si se requiere comunicación bidireccional, se pueden establecer un par de canales.

5. Oyente

Características de los productos MQ

Transmisión confiable

Se puede decir que esta característica es la base del middleware de mensajes. Para las aplicaciones, siempre que los datos se envíen correctamente al middleware de mensajes, el problema de la transmisión confiable de datos es el middleware de mensajes.

No repita la transmisión.

La propagación no repetitiva es la función de reanudar la transmisión en puntos de interrupción, que es especialmente adecuada para entornos de red inestables y ahorra recursos de red.

Transmisión asincrónica

La transmisión asincrónica significa que ambas partes que reciben información no tienen que estar en línea al mismo tiempo y tener capacidades y seguridad fuera de línea.

Impulsado por mensaje

Después de recibir el mensaje, notifique activamente al destinatario del mensaje.

Transacción de soporte

La aplicación puede combinar algunas actualizaciones de datos en una unidad de trabajo. Estas actualizaciones generalmente están relacionadas lógicamente. Para garantizar la integridad de los datos, todas las actualizaciones deben tener éxito o fallar simultáneamente).

Introducción a los escenarios aplicables de MQ

La cola de mensajes MQ es producida por el concepto de acoplamiento de Yunsong. Utiliza principalmente colas y publica y suscribe como el mecanismo de transmisión de mensajes para transmitir mensajes de manera confiable al lado del consumidor de manera asíncrona.

Es ampliamente utilizado entre sistemas distribuidos multiplataforma y entre sistemas para proporcionarles mecanismos de transmisión asincrónicos eficientes y confiables.

• Canal de mensajes

  Use MQ para conectar clientes y servidores que colaboran entre sí para que puedan intercambiar mensajes.

Si el cliente y el servidor necesitan una interacción segura y confiable, se puede usar una cola MQ como un canal seguro, de modo que el cliente y el servidor puedan comunicarse de forma asincrónica de manera segura y eficiente.

• Bus de mensajes

  Para un sistema distribuido compuesto por muchos servicios desarrollados independientemente, si van a formar un sistema completo, estos servicios deben poder interactuar de manera confiable y, al mismo tiempo, para la solidez del sistema,

No existe una dependencia excesivamente estrecha entre cada servicio, por lo que se pueden conectar diferentes servicios a través del bus de mensajes, lo que les permite transferir datos de forma asincrónica.

• Enrutamiento de mensajes (enrutador de mensajes)

  Mediante el enrutamiento de mensajes, puede enrutar los mensajes enviados a las colas designadas de MQ a diferentes colas de acuerdo con las reglas.

Además, la especificación JMS también admite el filtrado de mensajes a través de condiciones de selector. Múltiples consumidores pueden consumir mensajes en la misma cola, y cada consumidor solo consume mensajes de interés.

• Publicar / Suscribir (Publicsher / Suscriptor)

  El modo de publicación / suscripción se utiliza para la comunicación de uno a muchos. Cuando un editor de mensajes envía un mensaje a un tema, todos los suscriptores del tema recibirán el mensaje.

Uno de los middleware de mensajes más simples.

¡Debes pensarlo, es la cola! Cola

ArrayBlockingQueue se puede usar como un simple MQ

Use put () para enviar mensajes y
take () para consumir mensajes

Encapsulamos ArrayBlockingQueue para admitir múltiples temas

Map  msg = new HashMap<String, ArrayBlockingQueue<Message>>()

Tal MQ más simple se realiza, como se muestra a continuación

Pero este MQ es demasiado simple, las desventajas son las siguientes:

El mensaje se perderá, si el jvm se cuelga, el mensaje se perderá.

No admite alta disponibilidad

No admite distribuido y no puede expandirse horizontalmente

Resolvemos uno por uno

Estar altamente disponible, ser distribuido

Primero resuelva la arquitectura distribuida como la evolución de la siguiente manera

Ahora nuestro sistema mq está dividido en varias máquinas, que admite distribuido,

Cualquier máquina puede enviar un mensaje siempre que esté conectado a nuestro MQ

Lo mismo es cierto en el lado del consumidor.

Solución distribuida, próxima a resolver alta disponibilidad

El problema actual es que MQ es un punto único: una vez que MQ se cuelga, todo el sistema de mensajería se colapsa por completo, lo que nunca se permite en un entorno de producción.

Diseñemos nuestra arquitectura de alta disponibilidad.

Dos tipos de ideas comúnmente utilizadas en la alta disponibilidad de sistemas distribuidos

Idea Kafka, cada nodo se divide en múltiples particiones (partición), y luego varios nodos hacen una copia de seguridad de las particiones entre sí

Idea Rocketmq, cada nodo está configurado con un modo de espera activo

Adoptamos el segundo tipo, el diagrama de la arquitectura se ha convertido en la siguiente imagen

MQ agrega un modo de espera activo para lograr una alta disponibilidad, la máquina en espera sincroniza los datos del host en tiempo real, de modo que cuando el mq principal cuelga, el productor puede cambiar automáticamente a la máquina en espera para continuar funcionando

Pero, ¿qué pasa si la máquina de respaldo también se cuelga? ¿Se perderán los mensajes en la máquina?

Aquí viene un nuevo concepto de cepillado

Para evitar la pérdida de mensajes causada por el tiempo de inactividad, los datos deben cepillarse

Las estrategias de flasheo comúnmente utilizadas son:

Parpadeo en tiempo real (síncrono), que envía un mensaje para volver a escribir después de escribir en el disco, para garantizar que el mensaje se escriba con éxito al 100%, la desventaja es que el rendimiento del envío de mensajes es deficiente

Disco flash regularmente (asincrónicamente), escriba el disco cada vez que la unidad, alto rendimiento

Buffer (asíncrono) intermitente, abrir un espacio de búfer, como 32k, intermitente después de escribir, alto rendimiento

Sin flashear el disco, regresar después de escribir memoria es la estrategia con el rendimiento más alto. **** Las desventajas también son obvias

Vamos a ordenar los pasos de trabajo en la imagen de arriba

1.1 El MQ activo y en espera se inicia y se registra en el centro de registro

1.2 El productor inicia y extrae todas las listas MQ del centro de registro

1.3 Seleccione un MQ principal para enviar mensajes (habrá múltiples principales después de la expansión horizontal)

1.4 Si el maestro cuelga el centro de registro, inmediatamente percibirá y notificará al productor que no piense que el maestro ha enviado, sino que lo enviará a la máquina en espera

Para ser altamente concurrente, no hay pérdida de datos

Si desea una alta concurrencia, no puede perder datos. De hecho, en lo que respecta a MQ, estos dos puntos son contradictorios, al igual que la teoría CAP.

Solo podemos sopesar los pros y los contras para encontrar un equilibrio, pero también elegir estrategias de acuerdo con la escena

En la mayoría de los casos, el parpadeo regular o el parpadeo del búfer + espera activa pueden lograr el 99% de los datos sin pérdida

Manteniendo un rendimiento decente

Si sus datos no son muy importantes, como los archivos de registro, simplemente puede disminuir el rendimiento sin cepillarse.

Resumen

Repasemos lo anterior

Desde la cola más simple hasta la alta disponibilidad distribuida, se crea un marco mq básico

Pero no hablamos sobre el envío de mensajes, cómo consumir mensajes, el consumo repetido de mensajes, el consumo secuencial de mensajes, etc.

Kafka

En primer lugar, echemos un vistazo a la arquitectura del sistema de Kafka (hacer un middleware de mensajes es inevitable para entender Kafka).

El ecosistema de Kafka contiene el siguiente contenido:

• Productor
• Consumidor
• Racimo Kafka
• ZooKeeper

Entre ellos, ZooKeeper asume el rol de NameServer, y también se utiliza para guardar los metadatos del sistema, proporcionando funciones como la selección maestra y la coordinación.

Broker es un servidor real, utilizado para almacenar mensajes.

Usabilidad

Primero observe la disponibilidad de dependencias externas. Si su sistema "depende en gran medida" de otros servicios externos, entonces la disponibilidad de su sistema debe estar relacionada con la disponibilidad de servicios externos. (La dependencia fuerte significa que el servicio que no se puede separar de la dependencia sigue ejecutándose normalmente)

De la arquitectura anterior se puede ver que Kafka solo depende de ZooKeeper, y el propio ZooKeeper está altamente disponible (el clúster ZK de 2N + 1 nodos puede tolerar la falla de N nodos), por lo que no afectará la disponibilidad de todo el clúster.

Luego mira la disponibilidad de Kafka. Hablar de disponibilidad inevitablemente implicará problemas de respaldo. Sin respaldo, hay un solo punto de problema y no hay alta disponibilidad. Así que echemos un vistazo a la estrategia de respaldo de Kafka.

(Paquete de un artículo de InfoQ que discute la disponibilidad de Kafka)

El flujo de datos de Kafka Replication se muestra en la figura anterior, y se puede obtener cierta información de la figura:

1. Las particiones están respaldadas, como topic1-part1, hay 3
2. Las copias de seguridad de la partición se distribuyen en diferentes intermediarios. En la figura anterior, topic1-part1 se distribuye en broker1, broker2 y broker3, entre los cuales broker1 es el líder.
3. Los líderes particionados se distribuyen aleatoriamente: en la figura anterior, el líder de topic1-part1 está en broker1, el líder de topic2-part1 está en broker y el líder de topic3-part1 está en broker4.
4. El mensaje se escribe en la partición Líder y luego se copia en la partición Seguidor a través de la partición Líder

Para una implementación más detallada de Kafka Replication, puede ir al sitio web oficial (también puede escribir un artículo separado más adelante), que no se ampliará aquí.

Una estrategia de replicación como Kafak asegura que el sistema aún esté disponible cuando falla cualquier Broker. Si el corredor1 falla, el líder de topic1-part1 será reelegido, y luego topic1-part1 en broker2 o broker3 puede convertirse en el líder y luego ser responsable de escribir mensajes.

Por lo tanto, la disponibilidad del sistema depende del número de copias de seguridad de la partición; estos datos de copia de seguridad son configurables.

Kafka logra una alta disponibilidad a través de la Replicación, y el ZooKeeper dependiente también está altamente disponible, por lo que la disponibilidad de todo el sistema está mejor garantizada.

Fiabilidad

En el middleware de mensajes, la confiabilidad es principalmente que el mensaje escrito se consumirá y el mensaje no se perderá.

Hay dos puntos en los que los mensajes no se pierden en un entorno distribuido:

1. Después de que el mensaje se haya escrito correctamente en un nodo, el mensaje persistirá
2. Los mensajes serán respaldados en otros nodos físicos

Mientras se cumplan los dos puntos anteriores, se puede garantizar que los datos no se perderán excepto por la falla permanente de todos los nodos.

Los mensajes escritos en Kafka Broker se mostrarán (de forma asíncrona o sincrónica) y se realizarán copias de seguridad en otros nodos físicos, por lo que se cumplen los dos puntos anteriores.

El disco flash asíncrono combinado con la estrategia de copia de seguridad de múltiples nodos también puede proporcionar una mayor confiabilidad, a menos que la falla de energía de la sala de computadoras o similar haga que se pierdan los datos de todos los nodos que no se han flasheado.

Por supuesto, la pérdida de mensajes no significa necesariamente que el mensaje se haya destruido realmente del disco o no se haya almacenado. Si el mensaje se almacena, pero no se puede consumir, también es una pérdida de mensaje para el cliente. Por ejemplo, el consumidor recibe ACK y luego lo consume. Si se bloquea antes del consumo, no se recibirá la próxima vez, y se puede entender que el mensaje se perdió, pero no discutiremos esto en este artículo. Situación

Evaluación

Ventaja

1. Algunas funciones están alojadas en ZK, y solo necesitan prestar atención al contenido relacionado con el mensaje. Desde esta perspectiva, simplifica parte del contenido
2. Alta utilización de la máquina. De la estrategia de copia de seguridad anterior, se puede ver que los datos entre diferentes corredores se respaldan mutuamente. Esta estructura mejora la tasa de utilización de la máquina en relación con el modo maestro-esclavo (la mayoría del modo maestro-esclavo, el esclavo es inútil)

Desventajas

1. Introdujo ZK, aumentó las dependencias externas y aumentó la complejidad de la operación y el mantenimiento.

Desde la arquitectura del sistema, el método de respaldo es una mejor manera de dominarse mutuamente, pero la implementación será más complicada. Si desea implementar un MQ usted mismo, es más fácil comenzar con el modo maestro-esclavo.

(La estrategia de respaldo de Kafka y la implementación de la WAL de base son más complicadas, y tengo la oportunidad de decir esto más adelante)

RocketMQ

(Imagen tomada del documento RocketMQ_design)

RocketMQ contiene los siguientes contenidos:

• Productor
• Consumidor
• Nombre del servidor
• Corredor

Productor, Consumidor y Kafka son lo mismo (Todos MQ proporcionará Productor y Consumidor), Rocket también tiene un clúster de Corredores, la mayor diferencia con respecto a Kafka es que RocketMQ implementa un servicio de Servidor de Nombres en clúster.

Usabilidad

La disponibilidad de RocketMQ también se divide en NameServer y Broker.

NameServer está en modo de clúster y "casi" no tiene estado, y se puede implementar en clústeres, por lo que no habrá problemas de disponibilidad. (Sin estado significa que cada nodo proporciona servicios de forma independiente y solo necesita implementar varios nodos para resolver el problema de disponibilidad)

La disponibilidad de Broker se puede dividir en dos partes: para un tema, se puede distribuir en múltiples Brokers maestros, de modo que después de que uno de los Brokers no esté disponible, los otros Brokers puedan proporcionar servicios sin afectar el servicio de escritura. Después de que un Master Broker se cuelga, aunque se pueden utilizar otros maestros para garantizar la disponibilidad de la escritura, algunos datos que se han escrito en el agente fallido no se pueden consumir. RocketMQ resuelve este problema a través del modelo Master-Slave.

Después de que el maestro falla permanentemente, la solicitud de lectura en el maestro se puede transferir al esclavo, lo que puede garantizar la disponibilidad del sistema (maestro-esclavo se copia de forma asíncrona, lo que significa que es posible que no se haya copiado una pequeña cantidad de datos del maestro al esclavo, lo cual es confiable Sección de sexo).

Combinando los dos puntos anteriores, RocketMQ también proporciona características de alta disponibilidad, y la disponibilidad depende solo de sus propios servicios, no se introducen servicios adicionales como Kafka, como ZK.

Fiabilidad

La confiabilidad se considera desde la perspectiva de la confiabilidad de un solo intermediario que escribe mensajes y respalda mensajes.

RocketMQ utiliza un método de parpadeo sincrónico para conservar los mensajes escritos.

La única diferencia entre el parpadeo síncrono y el parpadeo asíncrono es que el parpadeo asíncrono regresa directamente después de escribir el caché de página, mientras que el parpadeo síncrono necesita esperar a que se complete el parpadeo antes de regresar. El proceso de escritura es el siguiente:

1. Escriba en pagecache, el hilo espera, informa que el hilo de cepillado parpadea
2. Después de parpadear el hilo, active el extremo frontal para esperar el hilo, que puede ser un lote de hilos
3. El hilo de espera de front-end quiere que el usuario devuelva el resultado de escritura

(El cepillado sincrónico requiere necesariamente más tiempo que el cepillado asincrónico. Más adelante se discutirá cómo resolver la pérdida de rendimiento causada por el cepillado sincrónico)

Usando el método de flasheo síncrono, desde la perspectiva de un solo nodo, la confiabilidad es más alta que el método de flasheo asíncrono, porque siempre que el Productor reciba retroalimentación de que el mensaje se escribió con éxito, entonces este mensaje debe ser flasheado y no debe Los mensajes se pierden debido a una falla de energía y otras razones.

Un solo nodo inevitablemente se enfrentará a un único punto de problema: cuando no se puede recuperar una falla permanente de un nodo, incluso si este mensaje ha persistido, no tiene sentido. En comparación con el método de respaldo mutuo de Kafka, RocketMQ utiliza el método MS.

El modo MS encontró el problema de la replicación maestro-esclavo retrasada (la replicación asincrónica siempre se retrasa), luego algunos datos pueden perderse después de que el maestro no esté disponible. RocketMQ proporciona un modo de doble escritura síncrona para este escenario.

Evaluación

Ventaja

1. Sin dependencias externas (esto significa que su sistema no requiere servicios adicionales, ya sea de operación y mantenimiento o disponibilidad, esto es realmente una ventaja)

Desventajas

1. El problema de la utilización de la máquina causado por la estructura de MS (Slave puede estar inactivo la mayor parte del tiempo)

Limitado por la utilización de la máquina del MS, en realidad no adoptará el modo de un maestro y muchos esclavos. La mayoría de ellos son un maestro y un esclavo. Algunos de los servicios con requisitos de fiabilidad más bajos ni siquiera están equipados con esclavos. Esto ha sido confirmado por los compañeros de desarrollo internos de Ali, que también es un defecto del modelo MS.

Algunas otras arquitecturas de MQ

Kafka introdujo un ZK externo, y el modo maestro-esclavo de RocketMQ no es "bueno", entonces ¿puede combinar los dos modos?

A continuación, discutimos varias arquitecturas que el autor considera.

Combinando Kafka y RocketMQ

Esta arquitectura es principalmente para eliminar la dependencia de ZK basada en Kafka. La introducción de ZK es principalmente para resolver el problema de coordinación de los sistemas distribuidos.Además, Kafka almacenará metadatos (configuración del tema, progreso del consumo y otra información almacenada en ZK) en ZK, mientras proporciona servicios de NameServer.

En este punto, estoy de acuerdo con el enfoque de RocketMQ. Los metadatos se pueden almacenar en el Broker, porque el Broker tiene estado, por lo que el progreso del consumo y otra información en él es irrelevante para otros Brokers (si hay una copia de seguridad mutua, debe sincronizar estos datos), por lo que NameServer puede Muy ligero y sin estado. RocketMQ hace exactamente lo mismo: el código de NameServer tiene aproximadamente 1,000 líneas, lo cual es relativamente simple.

Uno de los mayores problemas en la implementación de esta arquitectura es que después de eliminar ZK, los métodos internos primarios y secundarios deben seleccionar el Líder para cada Partición de tema. Es muy difícil implementar la selección maestra en la arquitectura sin un nodo central, incluida la necesidad de lidiar con la partición de la red y otros problemas. Cuando resolvemos este problema en la arquitectura anterior, podemos hacer algunos compromisos: por ejemplo, el nodo central se puede seleccionar primero y luego el nodo central es responsable de los problemas restantes relacionados con la selección del maestro.

El nodo central puede especificarse manualmente, y la disponibilidad del nodo central en sí no es muy importante, porque el sistema puede ejecutarse normalmente sin el nodo central, pero no es posible seleccionar el maestro. La disponibilidad del sistema depende de si el nodo central falla y otros no al mismo tiempo (sacrificando algunas operaciones y mantenimiento automatizados, porque no se considera la alta disponibilidad del nodo central, pero se eliminan las dependencias externas, y el diseño del sistema siempre tiene una compensación).

Eliminar NameServer

Considere en profundidad:

• La información de metadatos no es más que la configuración del tema, el progreso del consumo, la cantidad de datos no será muy grande, se puede almacenar directamente en el Broker
• Y el propio Broker ya es un nodo múltiple, naturalmente puede lograr la copia de seguridad de los metadatos

Después de almacenar los metadatos en el intermediario, habrá un problema: cada intermediario debe tener todos los metadatos, luego todos los intermediarios deben comunicarse para obtener los datos del tema (si solo los datos están disponibles, solo haga una copia de seguridad entre varios intermediarios).

Este problema se puede implementar mediante la introducción de protocolos como Gossip, por lo que la arquitectura puede eliminar el NameServer anterior y evolucionar hacia la siguiente estructura:

En este punto, en realidad solo queda un clúster de Broker en la arquitectura. Los datos entre Brokers utilizan la estrategia de respaldo de Kafka, y los metadatos entre Brokers se copian a través del protocolo Gossip.

De hecho, la arquitectura del sistema es muy simple aquí, y siento que no hay contenido que pueda eliminarse y cambiarse (la creencia simple del autor es hermosa).

Pero, de hecho, uno de los problemas que se ha pasado por alto es la compensación anterior. Al final, para un sistema, definitivamente queremos ser lo suficientemente automatizados, por lo que todavía tenemos que resolver el problema de alta disponibilidad del nodo central.

Cómo elegir un líder único en Broker, este es realmente el problema de consistencia de los sistemas distribuidos, siempre que se introduzca un protocolo que pueda resolver el problema de consistencia de los sistemas distribuidos, como Raft y Paxos.

Entonces esta arquitectura es teóricamente factible:

• No NameServer;
• Los corredores utilizan el maestro mutuo y el respaldo para garantizar la disponibilidad y confiabilidad del sistema;
• Introducir el protocolo Gossip para copiar metadatos;
• Introducir un acuerdo de coherencia para resolver el problema de elegir al líder;
  • Para simplificar, puede usar el protocolo de coherencia para seleccionar el nodo central, y el nodo central es responsable de coordinar otros problemas.
  • También es posible seleccionar directamente el tema de cada Partición de tema a través del acuerdo de coherencia.

Si escribimos un MQ nosotros mismos

Anteriormente dije que la cuenta pública espera escribir una serie de artículos similares a "From Entry to XXX", por lo que no quiero diseñar el sistema demasiado complicado al principio, para que no pueda lograrlo yo mismo. O elija una arquitectura más simple para facilitarnos discutir los temas centrales de MQ y realmente usar el tiempo comercial para hacer algunos intentos.

Por lo tanto, los artículos posteriores se desarrollarán sobre la base de la siguiente arquitectura (una vez que el contenido de esta arquitectura haya finalizado, se introducirán varios protocolos para simplificar la arquitectura o mejorar la disponibilidad y confiabilidad del sistema).

Similar a la arquitectura RocketMQ, y simplificado:

• NameServer de nodo único (el descubrimiento del servicio de NameServer se puede hacer a través de DNS)
• Broker adopta el modelo maestro-esclavo
• Los metadatos se almacenan en el intermediario y se informan al NameServer (cada intermediario solo almacena parte de los metadatos, que se agregan en el NameServer)

La implementación de esta arquitectura será relativamente simple, pero aún tiene alta disponibilidad y confiabilidad. Debido a que el NameServer en sí no tiene estado y la falla del NameServer no afecta los servicios centrales del sistema (envío y mensajería de mensajes), se puede tolerar un solo nodo. Broker es similar a la implementación de RocketMQ, y el modo de parpadeo sincrónico más los modos principal y de espera también pueden proporcionar una mejor usabilidad y confiabilidad, pero la tasa de utilización no es suficiente (según la intención original de escribir esta serie de artículos, no consideraremos primero la tasa de utilización) .

Conclusión

Este artículo presenta principalmente la arquitectura de Kafka y RocketMQ y discute la realización de la usabilidad y la confiabilidad. La combinación de ambos proporciona la arquitectura MQ en la que el autor piensa.

Al final del artículo, damos la base arquitectónica para el contenido de la serie de discusiones subsiguientes, es decir, elija el modo más fácil para discutir las preguntas de seguimiento. Este es un acuerdo común que debe alcanzarse antes de escribir el siguiente artículo.

Referencias

https://www.jianshu.com/p/ffa950d18f52
https://blog.csdn.net/apanious/article/details/51014396
https://www.cnblogs.com/hzmark/p/mq_arch.html

---

Comunidad de desarrolladores de Kotlin

La cuenta pública de la primera comunidad de desarrolladores de Kotlin en China, que comparte e intercambia principalmente temas relacionados, como el lenguaje de programación Kotlin, Spring Boot, Android, React.js / Node.js, programación funcional e ideas de programación.

Cuanto más ruidoso es el mundo, más pensamiento pacífico se necesita.