¡Cómo compartir datos entre microservicios a gran escala!

May 10 2022
Varios enfoques adecuados para un sistema escalable considerando las compensaciones entre disponibilidad y consistencia Imagen del autor Prólogo Fiverr es un mercado en línea para servicios independientes. Los vendedores ofrecen sus servicios, o Gig — e.

Varios enfoques adecuados para un sistema escalable considerando las compensaciones entre disponibilidad y consistencia

Imagen del autor

Prólogo

Fiverr es un mercado en línea para servicios independientes. Los vendedores ofrecen sus servicios, o Gig , por ejemplo, diseño gráfico, traducciones, programación web, para que los compradores los soliciten.

Cuando los compradores buscan Gigs (servicios) en Fiverr, se sienten atraídos por vendedores que parecen confiables según su nivel de vendedor, reseñas y cartera que se muestra en sus páginas de Gig. Los compradores informaron que la experiencia pasada del vendedor es el factor más importante en su decisión. Como resultado, recientemente lanzamos la función Clientes principales, que permite a los vendedores mostrar las marcas de alta calidad con las que han trabajado.

Principales clientes en la página de conciertos del vendedor

Motivación

La característica MVP (producto mínimo viable) de los principales clientes comenzó mostrando a los principales clientes del vendedor en un solo punto de contacto en el sitio: su página de concierto (vista del comprador).
Para la implementación ad hoc, creamos un servicio dedicado (la "fuente de la verdad") para manejar los datos de los principales clientes.

Cuando un vendedor agrega un nuevo cliente principal, los datos se guardan en la base de datos del servicio de Clientes principales. Para representar la página de conciertos del vendedor, el servicio Gig Page envía una solicitud HTTP al servicio Top Client para obtener los datos de los principales clientes.

Arquitectura MVP (imagen del autor)

El MVP mostró signos prometedores, ¡sí! Así que decidimos aumentar la exposición mostrando a los principales clientes de los vendedores en las páginas de la parte superior del embudo de Fiverr, las páginas más populares en el viaje del usuario, con decenas de millones de visitas todos los días (p. ej., página de usuario, página de resultados de búsqueda). Mostrar los datos en varias páginas en Fiverr trae más complejidad y desafíos.

Debido a que el MVP se enfocó en una sola página en Fiverr, pudimos confiar en el servicio Top Clients para manejar todo. Sin embargo, la expansión incluyó un número creciente de páginas con diferentes escalas, incluida la página más popular de Fiverr; todo esto requiere alta disponibilidad.

Usamos una arquitectura de microservicios en la que una aplicación se estructura como una colección de servicios débilmente acoplados.

En este blog, hablaremos sobre los servicios que sirven las páginas de la parte superior del embudo en nuestro sitio web (p. ej., página de usuario, página de concierto). Cada servicio es responsable de una vista (página) específica en Fiverr. Sus bases de datos almacenan una vista de fecha optimizada para lectura (según las necesidades de su página) y tienen todos (o la mayoría) de los datos necesarios para representar la página.

Restricciones

Teníamos tres limitaciones principales:

  1. El modo de vista propia debe ser muy consistente : el modo de vista propia (donde un vendedor puede ver y editar su perfil, incluidos sus principales clientes) siempre debe estar actualizado; las discrepancias no son una opción. Los datos se tomarán de la base de datos del servicio Top Clients, donde se realizan todas las lecturas y escrituras.
  2. Otras páginas pueden ser eventualmente consistentes : además del modo de vista propia, otras páginas, como la página del concierto o la página del usuario, pueden mostrar datos con un retraso. Por ejemplo, si un vendedor acaba de agregar un nuevo cliente, es posible que este cliente no aparezca en otras páginas de inmediato.
  3. El servicio de Clientes principales no debería afectar la disponibilidad : los clientes principales del vendedor generalmente se presentarán en las páginas más populares de Fiverr. Por lo tanto, si no se pudieron obtener los datos, la página se debería representar correctamente independientemente de los datos que falten.

Sincrónico

Esto es lo mismo que la solución ad hoc: cada servicio envía una solicitud HTTP para obtener los principales clientes de un vendedor y espera una respuesta. Las lecturas y escrituras son de la misma base de datos.

Enfoque sincrónico (imagen del autor)

Beneficios

  1. Simplicidad para baja escala: cada servicio realiza una llamada API al servicio de los mejores clientes.
  2. Coherencia de datos: todas las páginas muestran exactamente los mismos datos sin preocuparse por la coherencia.
  3. Los diferentes servicios (consumidores) no necesitan guardar datos en sus bases de datos.
  1. Menor disponibilidad: al escalar (como en nuestras páginas de la parte superior del embudo), el servicio de Clientes principales tendrá que manejar toda la carga, convirtiéndose así en un cuello de botella.
  2. Llamadas redundantes: no todos los vendedores proporcionaron datos sobre sus principales clientes, sin embargo, seguimos llamando al servicio de Principales clientes para todos los vendedores, que devuelve una respuesta vacía.
  3. Latencia más alta: agregar una llamada API (al servicio de Clientes principales) en cada representación de página puede aumentar el tiempo de respuesta de la página y causar latencia.

Para reducir el tiempo de respuesta, podemos hacer llamadas paralelas al servicio de Página de usuario y al servicio de Clientes principales. Tenga en cuenta que esto es posible solo si tenemos la información necesaria para llamar al servicio Top Clients y no necesitamos esperar una respuesta del servicio de página de usuario.

Asincrónico

Nuestra suposición es que el servicio de Clientes principales tendrá una gran cantidad de lecturas. Por lo tanto, queremos desvincular la lógica comercial (agregar, modificar y eliminar clientes) de las páginas orientadas al usuario.

La segregación de responsabilidad de consultas de comandos ( CQRS ) es un patrón que separa la operación que lee datos (consultas) de la operación que actualiza datos (comandos) mediante el uso de diferentes interfaces.

La arquitectura de Fiverr usa CQRS junto con el abastecimiento de eventos . En nuestro caso , cuando un vendedor agrega/elimina un cliente principal, el servicio de Clientes principales actualiza su base de datos y luego publica un mensaje en Kafka (un sistema de mensajería), describiendo el cambio que ocurrió. Todos los demás servicios consumirán ese mensaje de Kafka para actualizar su vista de datos (base de datos desnormalizada) en consecuencia.

Enfoque asíncrono (imagen del autor)

Beneficios

  1. Alta disponibilidad: cada servicio almacena los datos de los principales clientes, lo que elimina la necesidad de una segunda llamada a la API.
  2. Los datos en los diversos servicios serán eventualmente consistentes con la fuente de datos veraces, gracias a la alta disponibilidad de Kafka.
  3. Cada servicio ajusta sus propios recursos para gestionar su escala. Esto se puede lograr ajustando la CPU y la memoria, teniendo una base de datos de alta disponibilidad y manteniendo una baja complejidad de consulta.
  1. Posibles inconsistencias entre las bases de datos de los servicios. Diferentes páginas pueden mostrar diferentes clientes principales del mismo vendedor.
  2. Duplicación de datos sobre múltiples bases de datos.

La solución híbrida es una mejora de la alternativa sincrónica. Una observación importante es que no todos los vendedores proporcionaron datos sobre sus principales clientes; por lo tanto, no es necesario llamar al servicio Top Clients en cada presentación de página.

Una vez que se crea un cliente, el servicio Top Clients enviará la identificación del cliente a sus consumidores. Cada servicio guardará el identificador del cliente en su BD:

Solución híbrida-escribir datos (imagen del autor)

Para mostrar los principales clientes en la página de conciertos, el servicio Página de conciertos comprobará si el vendedor tiene algún ID de cliente en la base de datos. Si es verdadero, llamará al servicio Top Clients para enriquecer los datos de ese cliente.

Solución híbrida-lectura de datos (imagen del autor)

Beneficios

  1. Servicio Call Top Clients solo para vendedores con clientes; evitar llamadas redundantes.
  2. Solo se guarda el ID del cliente, lo que da como resultado una base de datos más pequeña.
  1. El servicio Top Clients sigue afectando el tiempo de respuesta de las páginas.
  2. Los datos todavía están duplicados en los servicios.

Nuestro objetivo era mostrar los principales clientes de los vendedores en varias páginas de Fiverr. El factor más crucial fue que la página tuviera una alta disponibilidad, incluso al precio de no mostrar los principales clientes del vendedor en caso de falla. Por lo tanto, elegimos la alternativa Asincrónica.

Resumen

Implementamos la función MVP de Top Clients , que sirvió una sola página en Fiverr, utilizando un enfoque síncrono. A medida que el producto se expandía, queríamos mostrar los datos en diferentes páginas en Fiverr.

Nos dimos cuenta de que el servicio Top Clients (nuestra fuente de confianza) no podrá manejar la gran carga de todos los demás servicios, por lo que decidimos usar Kafka para compartir los datos del servicio Top Clients entre todos los demás servicios. En esta solución, cada servicio contiene todos los datos necesarios para renderizar la página, con los datos adicionales de los principales clientes del vendedor.

Estén atentos a una forma 10 veces más rápida de enviar datos entre microservicios. Lo compartiré una vez que complete mi investigación y discusiones.

© Copyright 2021 - 2022 | unogogo.com | All Rights Reserved