Analista de sistemas. Una breve guía de la profesión. Parte 4. Integraciones síncronas y asíncronas. DESCANSO, gRPC, Kafka, RabbitMQ

En este artículo, aprenderá sobre los principales tipos de integración de aplicaciones y sistemas distribuidos más utilizados, como REST, gRPC, Kafka, RabbitMQ, WebSocket.

Este texto es artículo de revisión y está dirigido principalmente a recién llegados a la industria de TI, destinado a quienes quieran familiarizarse con la profesión, conocer sus contenidos, principios básicos, prácticas y herramientas utilizadas en la misma.

Comunicación entre aplicaciones. Integraciones.

Los sistemas modernos suelen constar de muchas aplicaciones independientes que se pueden distribuir en diferentes nodos (físicos o virtuales) de la red. Estas aplicaciones pueden escribirse en diferentes lenguajes de programación y utilizar diferentes formatos de datos. Interactúan tanto entre sí como con aplicaciones de otros sistemas.

Integración — el proceso de interacción entre aplicaciones independientes. El objetivo principal de la integración es permitir el intercambio de información entre aplicaciones.

hay dos modo interacciones de aplicaciones (discutidas en detalle en la primera parte del artículo):

• Sincrónico Interacción: una interacción de bloqueo en la que el cliente no puede continuar trabajando hasta que reciba una respuesta.

• Asincrónico interacción: interacción sin bloqueo en la que el cliente puede continuar trabajando después de enviar la solicitud.

También hay varios maneras interacciones demostradas en la imagen a continuación:

• Transferir archivos (Transferencia de archivos): la aplicación intercambia archivos de datos con otra aplicación.

• Base de datos compartida (Base de datos compartida): las aplicaciones intercambian datos a través de una base de datos común.

  Llamada a procedimiento remoto (Llamada a procedimiento remoto – RPC): cada aplicación describe a otras aplicaciones todos los procedimientos a los que se puede llamar de forma remota para intercambiar datos o realizar una solicitud. Un procedimiento es un fragmento de código de programa que realiza alguna función. Una llamada a procedimiento se refiere a la ejecución de una función.

• Mensajería (Mensajería): las aplicaciones están conectadas mediante intermediarios de mensajes, a través de los cuales intercambian datos entre sí.

• API — las aplicaciones se comunican entre sí a través de interfaces de software.

API REST, esquema json, OpenAPI

API DESCANSO

DESCANSAR La transferencia de estado representacional es un estilo arquitectónico que describe las restricciones de diseño de las aplicaciones que utilizan el protocolo HTTP (HTTPS) para transferir datos.

Una API que sigue las restricciones del estilo REST se llama RESTful o simplemente REST API.
Las aplicaciones pueden utilizar la API REST para intercambiar mensajes en varios formatos (XML, JSON, etc.) utilizando el protocolo HTTP(s).

RESTful describe principios de diseño aplicaciones, muchas de las cuales son limitaciones del protocolo HTTP con el que ya está familiarizado:

• arquitectura cliente-servidor;

• no almacenar estado — el cliente y el servidor deben interactuar sin almacenar el estado (sin estado). El cliente deberá proporcionar toda la información necesaria para su tramitación en la solicitud. El servidor no puede saber nada sobre solicitudes anteriores de este cliente;

• Utilice el almacenamiento en caché de datos siempre que sea posible — el almacenamiento en caché se puede realizar tanto en el lado del cliente como en el lado del servidor. El almacenamiento en caché puede mejorar el rendimiento mediante el uso de datos previamente almacenados, pero vale la pena considerar la posibilidad de que queden obsoletos;

• el recurso debe tener un identificador persistente único (URL)que no puede cambiar durante el intercambio de datos o como resultado de cambios en su estado. Si a un recurso se le asigna un identificador diferente, el servidor debe informar al cliente que la solicitud no tuvo éxito y proporcionar un enlace a la nueva dirección;

• utilizar una interfaz unificada (Hypermedia como motor del estado de la aplicación – HATEOAS): una interfaz HTTP unificada define CRUD (Crear, Leer, Actualizar, Eliminar): operaciones para crear, leer, actualizar y eliminar recursos en forma de métodos HTTP POST, GET, PUT, BORRAR ;

• usar códigos de estado (código de estado): las respuestas HTTP deben incluir códigos de estado, por ejemplo, 200 OK, 400 Bad Request, 502 Bad Gateway.

Al diseñar una API, es importante no olvidarse de idempotencia Métodos HTTP.

Métodos idempotentes son métodos que no cambian el estado en la base de datos o cambian el estado solo en la primera solicitud. Si se vuelve a enviar una solicitud idéntica, el estado de la base de datos no cambia. Los métodos idempotentes son: GET, PUT, DELETE, HEAD y OPTIONS.

Maravilloso artículo sobre Habré.que explica en detalle qué es la idempotencia y por qué no debe olvidarse.

Esquema Json

Esquema JSON es uno de los lenguajes para describir la estructura de un objeto JSON, utilizando la sintaxis JSON. Se utiliza para definir y verificar la estructura de datos y generar automáticamente código y documentación.

Esquema JSON consiste en de varios elementos clave:

• tipo de datos: Define el tipo de datos que se puede representar en el esquema JSON. Por ejemplo, cadena, número, booleano, objeto y matriz.

• Valor obligatorio: Indica si el valor es obligatorio u opcional. Los valores obligatorios están indicados con el símbolo. requeridoy opcionales, por la ausencia de este símbolo.

• Valores mínimos y máximos.: Define los valores mínimos y máximos permitidos para numérico tipos de datos.

• Longitudes mínimas y máximas: Define las longitudes mínima y máxima permitidas para término.

• Valores válidos: define una lista de valores válidos para un campo determinado.

• Propiedades adicionales: Determina si se pueden agregar propiedades adicionales a un objeto o matriz.

• Restricciones adicionales: define restricciones adicionales en la estructura de datos, como la unicidad de las claves o el orden de los elementos en una matriz.

Puede obtener más información sobre el esquema json. Aquíy su exactitud puede validarse, por ejemplo, aquí.

API abierta

API abierta — uno de los estándares de descripción de API, es un formalizado especificación y en toda regla estructura para describir, crear, usar y visualizar API, así como generar código automáticamente.

El formato utilizado es XML y JSON, pero en general se puede elegir otro lenguaje de marcado conveniente: YAML.

Un documento YAML en OpenAPI es un árbol con un conjunto de ramas. Hay varias ramas básicas, como consultas o componentes. Estos, a su vez, también pueden contener ramas adicionales que contienen descripciones de operaciones, parámetros de solicitud y esquemas de respuesta.

La descripción oficial de OpenAPI está disponible en github o aquí.

En la siguiente imagen se muestra una especificación de ejemplo con explicaciones.

La especificación OpenAPI consta de los siguientes objetos básicos:

• /pay – el nombre del punto final (punto final, “identificador”) – la URL a la que se envían las solicitudes. Para cada endopint, puede registrar un conjunto de métodos HTTP (GET, POST, PUT, PATCH, DELETE);

• post — método HTTP (en este caso POST);

• parameters — lista de parámetros pasados ​​en la solicitud;

  • name — nombre del parámetro

  • in — donde se pasa el parámetro (ruta, encabezado, consulta, cookie)

• requestBody — cuerpo de la solicitud;

• responses — una lista de posibles respuestas a la solicitud;

• 200 — Código de estado HTTP

• components — una sección que contiene componentes (objetos) para una reutilización conveniente en el código YAML.

• $ref es una referencia a un componente (en components), donde se define el objeto de respuesta/solicitud. Esto se hace para que el código YAML sea más fácil de leer y reutilizar.

También presente:

• tags— etiquetas utilizadas para marcar un grupo de puntos finales;

• summary — breve descripción;

• description — descripción del objeto;

recurso genial para ver el árbol de objetos de OpenAPI como una hoja de referencia a mano cuando sea demasiado vago para leer la documentación.

Un buen artículo sobre Habré sobre la especificación OpenAPI.

Una herramienta conveniente para describir especificaciones en formato OpenAPI: swagger.io (desde la Federación Rusa disponible con VPN).

Puedes mirar y practicar la escritura. Aquí.

Ventajas de usar OpenAPI:

Si no está familiarizado con OpenAPI, al describir la especificación por primera vez, puede parecer que la sintaxis es demasiado compleja y confusa. Sin embargo, este no es el caso y existen varias ventajas importantes que hacen que OpenAPI sea muy conveniente:

1. OpenAPI le permite acelerar la descripción de una gran cantidad de métodos, especialmente con objetos repetidos.

2. El código de servidor y de cliente y los objetos de datos se pueden generar a partir de la especificación OpenAPI.

3. Swagger se puede utilizar para realizar pruebas.

4. La especificación parece muy clara, informativa e interactiva, en comparación con su descripción en cualquier editor de texto.

gRPC, HTTP/2, Protobuf.

Como variante de la arquitectura RPC (llamada a procedimiento remoto), el protocolo gRPC fue creado por Google para acelerar la transferencia de datos entre microservicios y otros sistemas que necesitan comunicarse entre sí.

Usos de gRPC Protobuf (Protocol Buffers), utiliza como protocolo de transporte HTTP 2.0.

HTTP/2 – la segunda versión principal del protocolo de red HTTP. Admite transmisión bidireccional en una única conexión TCP, le permite agrupar solicitudes en marcos con la capacidad de priorizar y luego combinar (multiplexar) estos marcos.

Protobuf en general, es una secuencia de campos codificados en formato binario, que consta de una clave y un valor. La clave es el número definido para cada campo de mensaje en el archivo proto. Cada campo está precedido por el número de campo y su tipo.

gRPC proporciona cuatro tipos de transmisión:

• unario (Unario): permite al cliente enviar una solicitud y recibir una respuesta del servidor. Adecuado para situaciones en las que el cliente necesita realizar una operación y obtener el resultado.

• Lado del servidor (Server Streaming): el cliente envía una solicitud al servidor y el servidor devuelve un flujo de respuestas al cliente. Por ejemplo, cuando se solicita una fuente de noticias y el servidor envía noticias cuando están disponibles.

• Lado del cliente (Client Streaming): el cliente envía un flujo de mensajes de solicitud al servidor. El servidor devuelve una respuesta al cliente. Útil al transferir grandes cantidades de datos o registrar eventos.

• Bidireccional (Transmisión bidireccional): el cliente y el servidor se transmiten flujos de datos entre sí. El cliente es quien inicia este tipo de streaming bidireccional. El cliente también finaliza la conexión. Este tipo de transmisión es adecuado, por ejemplo, para chatear o transmitir vídeo.

gRPC tiene funciones de generación de código integradas. El analista solo necesita describir el formato de datos en el archivo protobuf y el compilador generará código de cliente y servidor para el controlador de llamadas gRPC.

El código generado actúa como una capa entre la lógica de la aplicación y la biblioteca gRPC. Este código utilizado por el cliente se llama con un bastón (talóntalón).

Que mas leer: excelentes artículos de yandex y de OTUS de Habré.

Pruebas API.

Según tengo entendido, las pruebas de API son responsabilidad de la función dedicada de un ingeniero de control de calidad (probador), pero el analista necesita saber qué y cómo se puede hacer.

Para fines de prueba de API, existen varias herramientas útiles como Cartero, Insomnio y otros.

Un buen artículo general sobre Habré sobre los conceptos básicos del trabajo con Postman.

En general, la tarea de probar una API es asegurarse de que funciona correctamente (devuelve la respuesta esperada a una solicitud de usuario o el error correspondiente si la solicitud es incorrecta).

Corredores de mensajes. Kafka, RabbitMQ.

Apache Kafka y ConejoMQ Estos son intermediarios de mensajes de software distribuido. Su uso es la base de la arquitectura de interacción de servicios basada en eventos.

Estos sistemas suelen constar de tres componentes básicos:

• servidor (corredor)procesamiento de mensajes;

• productoresque envían mensajes a una determinada cola con nombre, preconfigurada por el administrador en el servidor;

• consumidoresque leen los mismos mensajes que aparecen.

Los productores no saben nada sobre los consumidores cuando registran datos para el corredor, y los consumidores no saben nada sobre los productores de datos.

hay dos modelos de trabajo corredores:

• tirar del modelo — Los propios consumidores envían una solicitud al servidor para recibir un nuevo lote de mensajes. Con este enfoque, los consumidores pueden controlar eficazmente su propia carga de trabajo. Además, el modelo pull permite agrupar los mensajes en lotes, logrando así un mejor rendimiento. Kafka, por ejemplo, trabaja según este modelo.

• modelo de empuje — los productores envían de forma independiente al consumidor una nueva porción de datos. Por ejemplo, RabbitMQ funciona según este modelo. Reduce el retraso en el procesamiento de mensajes y le permite equilibrar la distribución de mensajes entre los consumidores.

Hay varios modelos de entrega de mensajes:

• Al menos una vez (al menos una vez; se permiten mensajes duplicados): el productor envía un mensaje a la cola y espera la confirmación del corredor. El consumidor recupera el mensaje de la cola y envía confirmación de que ha sido procesado. Si el productor no recibe la confirmación del corredor, reenvía el mensaje. El mensaje se procesará al menos una vez, pero puede haber situaciones en las que el mismo mensaje se procese varias veces. Para evitar la duplicación de mensajes, los componentes deben ser idempotentes, lo que significa que reprocesar el mismo mensaje no cambia el estado del sistema ni de sus datos. También puede utilizar identificadores únicos para mensajes y almacenar una lista de mensajes que ya han sido procesados.

• Como mucho una vez (no más de una vez, pero es posible que no se entregue en absoluto; se permite la pérdida de mensajes): el productor envía el mensaje a la cola y no espera la confirmación del corredor. El consumidor recupera el mensaje de la cola y no envía confirmación de que ha sido procesado. Se elimina la posibilidad de mensajes duplicados, pero el mensaje puede perderse.

• exactamente una vez (estrictamente solo una vez – estrictamente un mensaje): el corredor garantiza que cada mensaje se entregará y procesará exactamente una vez. El productor envía el mensaje a la cola y espera la confirmación del corredor de que se ha recibido. El consumidor recupera el mensaje de la cola y envía una confirmación de procesamiento.

kafka

Apache Kafka es un intermediario de mensajes de software distribuido que se utiliza para procesar datos en tiempo real con alto rendimiento y baja latencia.

Un clúster de Kafka está formado por intermediarios.

Tiendas Kafka mensajesque provienen de otros procesos llamados “productores”, en el formato “clave – valor”.
Llave (Clave) puede ser cualquier cosa: numérica, cadena, objeto o completamente vacía.
Significado (Valor) también puede ser cualquier cosa: un número, una cadena o un objeto en su propio dominio que puede serializarse (JSON, Protobuf, etc.) y almacenarse.

En el mensaje el productor podrá indicar tiempo (marca de tiempo), o el corredor lo hará por él en el momento en que se reciba el mensaje.

Titulares (Encabezados) se parecen en el protocolo HTTP: pares de clave-valor de cadena y se pueden usar para transmitir metadatos.

Los datos en Kafka se pueden dividir particiones (particiones) dentro de diferentes Topikov (temas). El aumento de particiones aumenta el paralelismo de lectura y escritura. Las particiones residen en uno o más intermediarios, lo que permite escalar el clúster.
Dentro de una partición, los mensajes están estrictamente ordenados por sus números de serie (compensar), y también se indexan y almacenan junto con la hora de creación.

Cada corredor tiene almacenamiento localcuyos datos pueden quedar desactualizados en tiempo o en tamaño (esto se puede configurar de forma global o individual en cada tema).

Solo tema Puede considerarse como un canal lógico a través del cual pasan los mensajes. Otros procesos, llamados consumidores, pueden leer mensajes de temas.

Kafka lo apoya todo tres formas de entrega сообщений: Como máximo una vez, al menos una vez, exactamente una vez.

Normalmente necesario alcance del trabajo del analista Al diseñar la integración usando Kafka es:

• descripción de los formatos de datos; la mayoría de las veces es JSON;

• determinar el número de temas en función de los requisitos comerciales y la arquitectura del sistema. Por ejemplo, diferentes tipos de datos (registro, transacciones, eventos) pueden requerir temas separados. Separar los datos por tema ayuda a aislar diferentes flujos de datos, mejorando la capacidad de administración y la seguridad;

• determinar los parámetros del tema: nombre del tema, número de particiones (secciones), tiempo de almacenamiento de datos o restricciones en la cantidad de datos almacenados.

• definir la estrategia de partición:

  • hash (la estrategia predeterminada cuando el hash de la clave del mensaje se utiliza para la distribución entre particiones), o

  • usando claves de partición (utiliza una clave de mensaje especificada por el usuario para distribuir mensajes en particiones; esto ayuda a dirigir los mensajes relacionados a una partición).

ConejoMQ

ConejoMQ – intermediario de mensajes de software basado en el estándar AMQP.

La fuente del mensaje es una aplicación externa que crea una conexión utilizando el protocolo AMQP y genera mensajes al corredor RabbitMQ para su posterior procesamiento.

Formato de mensaje:

• encabezados – titulares mensajes. Requerido para el funcionamiento de encabezados tipo Exchange, así como para funciones adicionales de TTL tipo Rabbit;

• clave de enrutamiento – clave de enrutamientosólo puede haber uno por mensaje;

• modo_entrega— un signo de perseverancia mensajes;

• carga útil— útil cargaen cualquier formato serializable.

Editor siempre escribe para intercambiar con una clave de enrutamiento que coincida con el nombre de la cola.
El editor también define un modo de entrega para cada mensaje: una “señal de persistencia”. Esto significa que el mensaje se guardará en el disco y no desaparecerá si se reinicia el agente RabbitMQ.

Intercambio es el punto de entrada y enrutador de todos los mensajes (tanto los entrantes de Publisher como los que salen de los procesos internos en Rabbit).

Hay 4 tipos de Intercambio:

• Intercambio directo: se envía un mensaje a la cola si la clave de enrutamiento del mensaje coincide exactamente con el nombre de la cola.

• Intercambio de temas: Este tipo de intercambiador permite enrutar mensajes según patrones clave de enrutamiento.

• Intercambio de fans: El mensaje se envía a todas las colas asociadas con este intercambiador, independientemente de la clave de enrutamiento.

• Intercambio de encabezados: el enrutamiento de mensajes se produce según los encabezados de los mensajes, no en las claves de enrutamiento.

Cola (cola), es un almacén secuencial de mensajes no procesados. El almacenamiento de mensajes en el disco (persistente) depende del indicador delivery_mode asignado por el editor para cada mensaje.
Duradero/Transitorio: una señal de persistencia de la cola. Durable significa que el intercambio persistirá después de reiniciar RabbitMQ. Este valor debe especificarse junto con delivery_mode=2 (persistente).

Los mensajes se ponen en cola y se recuperan según el principio FIFO (primero en entrar, primero en salir).

Hay tres tipos de colas:

• Clásico – cola normal, utilizada en la mayoría de los casos.

• Quórum – un análogo de una cola clásica, pero con garantías de coherencia, lograda mediante el quórum en el clúster.

• Arroyo — un nuevo tipo de cola (a partir de RabbitMQ 3.9), análogo de Apache Kafka.

Proceso de trabajo ConejoMQ:

1. El consumidor crea una conexión utilizando el protocolo AMQP y recibe mensajes de la cola.

2. RabbitMQ almacena el mensaje hasta que la aplicación receptora se conecta y lo recupera de la cola. El consumidor puede acusar recibo del mensaje inmediatamente o después de procesarlo en su totalidad. Una vez recibida dicha confirmación, el mensaje se elimina de la cola.

Soportes de RabbitMQ dos formas de entrega сообщений: como máximo una vez, al menos una vez.

Normalmente necesario alcance del trabajo del analista Al diseñar la integración utilizando RabbitMQ es:

• descripción de los formatos de datos para la carga útil; la mayoría de las veces es JSON;

• definir colas (Queues) y el signo de su persistencia (vurable/eransient);

• descripción de claves de mensaje (claves de enrutamiento);

• determinación de políticas cambiarias (tipos de cambio).

WebSocket

Enchufe — el nombre de la interfaz del software para garantizar el intercambio de datos entre procesos. Para comunicarse utilizando la pila de protocolos TCP/IP, se utilizan direcciones y puertos.

El par dirección-puerto define un socket (“socket” correspondiente a la dirección y el puerto). En el proceso de intercambio, por regla general, se utilizan dos sockets: el socket del remitente y el socket del destinatario.

Cada proceso puede crear un socket de “escucha” (zócalo del servidor) y vincularlo a algún puerto del sistema operativo.

El proceso de escucha suele estar en un bucle de suspensión, lo que significa que se despierta cuando llega una nueva conexión. Al mismo tiempo, es posible comprobar la disponibilidad de conexiones en ese momento, establecer un tiempo de espera para la operación, etc.

WebSocket Es un protocolo de comunicación a través de una conexión TCP, diseñado para intercambiar mensajes entre un cliente y un servidor en tiempo real después de que se ha establecido una conexión.

WebSocket es adecuado cuando necesita actualizaciones de datos en tiempo real y la capacidad de entregar mensajes al cliente sin solicitudes constantes.

Si los datos son estáticos o tardan en actualizarse, no es necesario utilizar websockets.

WSS (WebSockets Secure) es un protocolo para intercambiar datos entre un servidor y un cliente mediante una conexión segura, generalmente a través del puerto 443 (utilizando el protocolo HTTP).

Para establecer una conexión WebSocket, el cliente y el servidor utilizan un protocolo similar a HTTP. La solicitud se envía a ws: o wss: URI (similar a http o https).

El servidor responde a la solicitud con un protocolo de enlace de protocolos de conmutación HTTP 101, cambia de HTTP a WebSocket y admite comunicación bidireccional en tiempo real.

El servidor puede abrir múltiples conexiones WebSocket con el mismo cliente o con diferentes clientes.

En este caso, el servidor admite mensajes puntuales (a uno), selectivos (a un grupo) o de difusión (a todos a la vez).

Para cerrar la conexión, el cliente debe enviar una solicitud al servidor y, una vez transcurrido el tiempo de espera, debe enviar una respuesta para confirmar el cierre.

En este artículo, aprendió sobre los tipos principales y más utilizados de interacciones de integración entre aplicaciones y sistemas distribuidos.

La parte final de la serie de artículos examinará metodologías y enfoques modernos para el desarrollo de software, así como sus principales artefactos y actividades. Esto le ayudará a desarrollar una comprensión más completa del trabajo de un analista de sistemas en términos de su función en el equipo de producto.

Puede encontrar este y otros artículos sobre análisis de sistemas y arquitectura de TI en mi pequeño y acogedor canal de Telegram: Notas de un analista de sistemas