Organización de la interacción efectiva de microservicios.

Recientemente, las arquitecturas de microservicios han gozado de cierta popularidad. El rendimiento y la escalabilidad de las soluciones basadas en ellos pueden depender de cómo interactúan los microservicios. Esta interacción puede ser sincrónica o asincrónica. El material, cuya traducción presentamos hoy a su atención, analiza métodos sincrónicos para la interacción de microservicios. Es decir, nos centraremos en el estudio de dos tecnologías: HTTP / 1.1 y gRPC. La primera tecnología está representada por llamadas HTTP estándar. El segundo se basa en el uso del marco RPC de alto rendimiento de Google. El autor del artículo sugiere mirar el código necesario para implementar la interacción de microservicios utilizando HTTP / 1.1 y gRPC, tomar medidas de rendimiento y elegir una tecnología que permita organizar el intercambio de datos entre microservicios de la mejor manera.

Aplicación normal

Comencemos pequeño y creemos un sistema de dos microservicios que puedan interactuar entre sí. Tenga en cuenta que el modo de clúster no se usa aquí. Aquí hay un diagrama de nuestra aplicación.


Arquitectura de aplicación típica

La aplicación consta de los siguientes componentes:

• Herramienta de prueba del sistema: jMeter .
• Servicio A: un microservicio que ejecuta solicitudes para el servicio B y devuelve las respuestas recibidas del mismo.
• Servicio B (Servicio B): un microservicio que envía datos JSON estáticos en respuesta a solicitudes después de un retraso de 10 milisegundos, utilizado para todas sus API.
• Máquinas virtuales (VM 1 y VM 2): instancias Amazon EC2 t2.xlarge.

▍HTTP / 1.1

HTTP / 1.1 es una tecnología estándar para organizar la interacción de microservicios, que se utiliza cuando se utilizan bibliotecas HTTP como axios o superagent .

Aquí está el código de servicio B que implementa la API de nuestro sistema:

server.route({  method: 'GET',  path: '/',  handler: async (request, h) => {    const response = await new Promise((resolve) => {      setTimeout(() => {        resolve({          id: 1,          name: 'Abhinav Dhasmana',          enjoys_coding: true,        });      }, 10);    });    return h.response(response);  }, }); 

Aquí está el código para el servicio A que accede al servicio B usando HTTP / 1.1:

 server.route({ method: 'GET', path: '/', handler: async (request, h) => { try { const response = await Axios({ url: 'http://localhost:8001/', method: 'GET', }); return h.response(response.data); } catch (err) { throw Boom.clientTimeout(err); } }, }); 

Al ejecutar estos microservicios, podemos aprovechar jMeter para ejecutar pruebas de rendimiento. Descubriremos cómo se comporta el sistema cuando trabaje con 50 usuarios, cada uno de los cuales realiza 2000 solicitudes. Como se puede ver en la siguiente figura, la mediana de los resultados de la medición es de 37 ms.


Resultados de la investigación de un sistema en modo normal usando HTTP / 1.1 usando jMeter

▍gRPC

gRPC utiliza la tecnología Protocol Buffers de forma predeterminada. Por lo tanto, usando gRPC, además del código de dos servicios, necesitaremos escribir el código de protoarchivo, que describe la interfaz entre los módulos del sistema.

 syntax = "proto3"; service SampleDataService { rpc GetSampleData (Empty) returns (SampleData) {} } message SampleData { int32 id = 1; string name = 2; bool enjoys_coding = 3; } message Empty {} 

Ahora, dado que ahora planeamos usar gRPC, necesitamos reescribir el código de servicio B:

 const grpc = require('grpc'); const proto = grpc.load('serviceB.proto'); const server = new grpc.Server(); const GetSampleData = (call, callback) => { setTimeout(() => {   callback(null, {     id: 1,     name: 'Abhinav Dhasmana',     enjoys_coding: true,   }); }, 10); }; server.addService(proto.SampleDataService.service, { GetSampleData, }); const port = process.env.PORT; console.log('port', port); server.bind(`0.0.0.0:${port}`, grpc.ServerCredentials.createInsecure()); server.start(); console.log('grpc server is running'); 

Presta atención a algunas características de este código:

• El comando const server = new grpc.Server(); creamos un servidor grpc.
• server.addService(proto... comando server.addService(proto... agregamos el servicio al servidor.
• El comando server.bind(`0.0.0.0:${port}... se usa para vincular el puerto y las credenciales.

Ahora reescriba el servicio A usando gRPC:

 const protoPath = `${__dirname}/../serviceB/serviceB.proto`; const proto = grpc.load(protoPath); const client = new proto.SampleDataService('localhost:8001', grpc.credentials.createInsecure()); const getDataViagRPC = () => new Promise((resolve, reject) => { client.GetSampleData({}, (err, response) => {   if (!response.err) {     resolve(response);   } else {     reject(err);   } }); }); server.route({ method: 'GET', path: '/', handler: async (request, h) => {   const allResults = await getDataViagRPC();   return h.response(allResults); }, }); 

Entre las características de este código están las siguientes:

• const client = new proto.SampleDataService... comando const client = new proto.SampleDataService... creamos un cliente grpc.
• Se realiza una llamada remota utilizando el client.GetSampleData({}...

Ahora probemos lo que tenemos con jMeter.


Resultados de la investigación de un sistema en modo normal usando gRPC usando jMeter

Después de cálculos simples, puede descubrir que una solución que usa gRPC es un 27% más rápida que una solución que usa HTTP / 1.1.

Aplicación de clúster

Aquí hay un diagrama de una aplicación similar a la que acabamos de investigar pero que funciona en modo de clúster.


Arquitectura de aplicación en modo de clúster

Si compara esta arquitectura con la considerada anteriormente, se pueden observar los siguientes cambios:

• Hay un equilibrador de carga (Load Balancer), que usa NGINX .
• El servicio B ahora está presente en tres instancias que escuchan en diferentes puertos.

Una arquitectura similar es típica para proyectos reales.

Explorando HTTP / 1.1 y gRPC en un nuevo entorno.

▍HTTP / 1.1

Cuando se utilizan microservicios que usan HTTP / 1.1 en un entorno en clúster, su código no tendrá que modificarse. Solo necesita configurar nginx para organizar el equilibrio del tráfico del servicio B. En nuestro caso, para hacer esto, necesita traer el /etc/nginx/sites-available/default a este formulario:

 upstream httpservers {  server ip_address:8001;  server ip_address:8002;  server ip_address:8003; } server {  listen 80;  location / {     proxy_pass http://httpservers;  } } 

Ahora veamos lo que tenemos y veamos los resultados de probar el sistema usando jMeter.


Resultados de investigación para un sistema basado en clúster que utiliza HTTP / 1.1 con jMeter

La mediana en este caso es de 41 ms.

▍gRPC

El soporte GRPC apareció en nginx 1.13.10 . Por lo tanto, necesitamos la última versión de nginx, para cuya sudo apt-get install nginx comando sudo apt-get install nginx habitual no es adecuado.

También aquí no utilizamos Node.js en modo de clúster , ya que gRPC no es compatible con este modo.

Para instalar la última versión de nginx, use la siguiente secuencia de comandos:

 sudo apt-get install -y software-properties-common sudo add-apt-repository ppa:nginx/stable sudo apt-get update sudo apt-get install nginx 

Además, necesitaremos certificados SSL. Se puede crear un certificado autofirmado usando openSSL :

 openssl req -x509 -newkey rsa:2048 -nodes -sha256 -subj '/CN=localhost' \ -keyout localhost-privatekey.pem -out localhost-certificate.pem 

Para usar gRPC, debe editar el archivo / etc/nginx/sites-available/default :

 upstream httpservers {  server ip_address:8001;  server ip_address:8002;  server ip_address:8003; } server {  listen 80;  location / {     proxy_pass http://httpservers;  } } 

Ahora todo está listo para probar la solución gRPC de clúster utilizando jMeter.


Resultados de un sistema en modo de clúster usando gRPC usando jMeter

En este caso, la mediana es de 28 ms, que es un 31% más rápida en comparación con el mismo indicador obtenido al examinar una solución HTTP / 1.1 agrupada.

Resumen

Los resultados del estudio muestran que una aplicación basada en microservicios que usa gRPC es aproximadamente un 30% más productiva que una aplicación similar que usa HTTP / 1.1 para intercambiar datos entre microservicios. El código fuente de los proyectos discutidos en este artículo se puede encontrar aquí .

Estimados lectores! Si está desarrollando microservicios, hable acerca de cómo organizar el intercambio de datos entre ellos.