Una guía para los microservicios de Java. Parte 2: Implementación y Pruebas

Traducción y adaptación de microservicios Java: una guía práctica . Enlace a la primera parte de la guía . Cualquier programa Java del lado del servidor y, por tanto, cualquier microservicio, es simplemente un archivo con extensión .jar o .war. Hay una gran cosa acerca del ecosistema Java, o más bien de la JVM: sólo necesitas escribir código Java una vez y puede ejecutarse en casi cualquier sistema operativo, siempre y cuando no hayas compilado tu código con una versión de Java más nueva que tu versión de JVM de destino. Es importante comprender esto, especialmente cuando se trata de temas como Docker, Kubernetes o (¡redoble de tambores!) La nube. ¿Por qué? Veamos diferentes escenarios de implementación.

Ejemplo minimalista de implementación de microservicio Java

Sigamos con el ejemplo del banco. Entonces tenemos un archivo monobank.jar (monolito) y nuestro Riskengine.jar recién extraído (el primer microservicio de verificación de riesgos). Supongamos también que ambas aplicaciones, como cualquier otra aplicación del mundo, necesitan un archivo .properties. En nuestro caso, solo contendrá la URL de la base de datos y las credenciales. Una implementación mínima podría consistir en dos directorios similares a este: Primero:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Segundo:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Esto deja abierta la pregunta: ¿cómo llegarán los archivos .properties y .jar al servidor? Desafortunadamente, puede haber muchas respuestas.

Cómo utilizar herramientas de compilación, SSH y Ansible para implementar microservicios Java

Consejos aburridos, pero no menos excelentes, sobre cómo implementar microservicios Java... En realidad, exactamente de la misma manera que los administradores de sistemas han implementado cualquier programa de servidor Java en las empresas durante los últimos 20 años. Esta es la mezcla:

• tu herramienta de construcción favorita (Maven, Gradle)
• buen SSH/SCP antiguo para copiar .jars a servidores
• Scripts Bash para administrar servidores y scripts de implementación
• o incluso mejor: algunos scripts de Ansible.

Por supuesto, esto no es adecuado para innovadores que necesitan una nube que "respire", servidores con equilibrio de carga automático, etc. Esta es la vieja escuela realmente aburrida. ¡Sin embargo funciona!

Cómo utilizar Docker para implementar microservicios Java

Volvamos a la dulce agonía de la elección. Hace un par de años Docker entró en escena, y con él la contenedorización. Si nunca ha trabajado con él, aquí hay una breve descripción dirigida a usuarios finales y desarrolladores:

• Un contenedor (simplificado) es similar a la vieja máquina virtual, pero "más ligero". Si no tiene claro qué significa "más fácil" en este contexto, consulte esta respuesta en Stackoverflow .
• El contenedor garantiza su propia portabilidad. Es decir, funciona en cualquier lugar. Suena familiar, ¿no?

Es curioso que, dada la portabilidad y compatibilidad con versiones anteriores de la JVM, esta característica no parezca una gran ventaja. Simplemente puede descargar JVM.zip en cualquier Raspberry Pi (o incluso en un teléfono móvil), extraerlo y ejecutar cualquier archivo .jar. La situación cambia en lenguajes como PHP o Python, donde las incompatibilidades de versiones o las configuraciones de implementación son más complejas. O si su aplicación Java depende de muchos otros servicios instalados (con los números de versión correctos): por ejemplo, una base de datos Postgres o un almacén de valores clave de Redis. Entonces, la principal ventaja de Docker para microservicios Java, o más precisamente para aplicaciones Java, es la siguiente: la capacidad de configurar entornos de prueba o integración homogeneizados utilizando herramientas como Testcontainers . Los desarrollos complejos son más fáciles de instalar. Tomemos como ejemplo el software del foro Discourse . Puede instalarlo con una sola imagen de Docker, y esa imagen contiene todo lo que necesita, desde el software Discourse escrito en Ruby hasta una base de datos Postgres, Redis y el fregadero de la cocina. Si sus implementaciones son similares o desea ejecutar una pequeña base de datos Oracle, pruebe Docker. Entonces, para resumir, en lugar de simplemente mirar el archivo .jar, ahora:

• empaquete su archivo jar en una imagen de Docker
• envíe esta imagen a un registro Docker privado
• extraiga y ejecute esta imagen en su plataforma de destino
• o copie la imagen de Docker directamente a su sistema de producción y ejecútela.

Cómo utilizar Docker Swarm o Kubernetes para implementar microservicios Java

Supongamos que decide probar Docker. Cada vez que implementas un microservicio Java, creas una imagen de Docker que agrupa tu archivo .jar. Supongamos que tiene un par de estos microservicios Java y desea implementarlos en varias máquinas (en un clúster). Surge la pregunta: ¿cómo gestionar este cluster? ¿Ejecutar contenedores Docker, verificar el rendimiento, implementar actualizaciones, escalar el sistema (brrr)? Dos posibles respuestas a esta pregunta son Docker Swarm y Kubernetes. Entrar en detalles sobre ambas opciones haría que este ya extenso tutorial fuera demasiado largo, pero creemos que es importante mencionar que, en última instancia, ambas opciones dependen de que usted escriba archivos YAML (consulte las historias de sangría de Yaml ) para administrar su clúster. Si quieres saber qué sentimientos evoca esto en la práctica, simplemente escribe una consulta similar en la búsqueda de Twitter. Entonces, el proceso de implementación para sus microservicios Java ahora se ve así:

• Configuración y gestión de Docker Swarm/Kubernetes
• Todos los pasos para Docker (ver arriba)
• Escribe y ejecuta YAML hasta que te sangren los ojos hasta que todo funcione.

Cómo probar microservicios Java

Supongamos que decide implementar microservicios en producción. ¿Cómo podemos probar la integración de n-microservicios durante el desarrollo ahora? ¿Cómo puedes ver si todo el flujo de trabajo está funcionando y no solo partes de él? En la práctica, puedes utilizar uno de estos tres métodos:

1. Con un poco de trabajo (si usa marcos como Spring Boot), puede combinar todos sus microservicios en una clase de lanzamiento y cargar todos los microservicios usando una única clase Wrapper.java, dependiendo de si tiene suficiente memoria en su máquina para Ejecútalos todos tus microservicios.
2. Puede copiar la configuración de Docker Swarm o Kubernetes localmente.
3. Simplemente ya no ejecute pruebas de integración localmente. En su lugar, implemente un entorno DEV/TEST dedicado. Esto es algo que muchos equipos hacen cuando sucumben al dolor de las configuraciones de microservicios locales.

Además, además de sus microservicios Java, probablemente también necesitará un intermediario de mensajes en ejecución (como ActiveMQ o RabbitMQ) o quizás un servidor de correo electrónico o cualquier otro componente de mensajería que sus microservicios Java necesiten para comunicarse entre sí. Esto conduce a una subestimación significativa de la complejidad en el lado de DevOps. Eche un vistazo a las bibliotecas de prueba de microservicios, pueden aliviar este problema. En cualquier caso, esta complejidad nos lleva a los problemas generales de los microservicios, de los que hablaremos ahora mismo. En la parte final , cubriremos preguntas generales sobre los microservicios de Java.