Microservicios políglotas en Spring Cloud con Spring Sidecar

1
1213

0. Índice de contenidos.


1. Introducción.

Spring Cloud proporciona el soporte necesario para exponer nuestros microservicios dentro de una nube de
microservicios, proporcionando una implementación de todos aquellos patrones de desarrollo y despliegue sobre
sistemas distribuidos que hacen que nuestro sistema sea escalable y reactivo.

Spring Cloud permite además desplegar microservicios desarrollados y desplegados bajo stacks tecnológicos diversos,
no tienen necesariamente que estar desarrollados bajo la pila de productos de Spring, Spring Boot y Spring Cloud.

Para ello podemos hacer uso de un proyecto de Spring Cloud denominado Spring Sidecar que nos permitirá disponer de
microservicios políglotas que se beneficien de todo el ecosistema de microservicios estructurales de Spring Cloud,
desarrollados en el lenguaje que mejor convenga a cada objetivo de negocio.

El patrón se denomina Sidecar por la metáfora de un sidecar acoplado a una motocicleta.
El microservicio que va a dar el soporte, funciones auxiliares, para engancharse a los servicios de infraestructuras
en la nube se acopla como un sidecar a una motocicleta que es el microservicio que realmente expone la lógica funcional.

2. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2.5 GHz Intel Core i7, 16GB DDR3).
  • Sistema Operativo: Mac OS High Sierra 10.13.3
  • Oracle Java: 1.8.0_25
  • Spring Boot 1.5.9.RELEASE
  • Spring Cloud Edgware.RELEASE


3. Configuración del sidecar

Para el ejemplo generaremos dos proyectos, el sidecar y un proyecto en node.js que expondrá funcionalidad de negocio.

Para el sidecar podríamos tener un pom.xml como el siguiente:

Como con el resto de microservicios de infraestructura solo tenemos que añadir el soporte de los starters correspondientes
y una anotación @EnableSidecar, para habilitar el proyecto como Sidecar, en la clase anotada como @SpringBootApplication

A continuación, en el application.yml del mismo proyecto incluimos las siguientes propiedades

Por un lado tenemos el puerto de nuestro Sidecar (8082) y por otro la configuración del microservicio al que lo vamos a
acoplar:

  • puerto: 3000
  • url de health check: http://localhost:3000/health.json que es lo único que obligatoriamente debe implementar el microservicio de negocio, para redirigir las peticiones de health check de eureka.
  • home del microservicio: http://localhost:3000


4. Un microservicio en node.js.

Vamos a generar el microservicio de negocio en node.js desplegado sobre un servidor express sin muchas más pretensiones
que devolver un json estático y exponer un end-point de health check que es lo único que nos vincula al sidecar.

Aún en node, vamos a configurar un pom.xml con el plugin de npm para que esté gestionado también por maven.

Y dentro del directorio de resources un package.json con el siguiente contenido:

Un fichero estático products.json para devolver un listado de catálogo de productos:

Y el fichero server.js de configuración del servidor express con un contenido como el siguiente:

Desde el punto de vista del ejemplo lo más relevante es el end-point de health check para el cuál debemos devolver un
200 con un mensaje


5. Referencias.


6. Conclusiones.

Los patrones Sidecar y Ambassador justificarían de algún modo disponer de microservicios en la nube que no exponen
directamente funcionalidad de negocio; para el resto, por favor, recordad que los microservicios deben estar “construidos
alrededor de capacidades de negocio”.

Por último, sopesad también el coste de mantenimiento de esta poliglosía, desde el punto de vista de proyecto o de
producto, antes de recomendar o aventurarse en el desarrollo bajo distintos stacks tecnológicos bajo una ya costosa
arquitectura orientada a microservicios.

Un saludo.

Jose

1 Comentario

Dejar respuesta

Please enter your comment!
Please enter your name here