La palabra "microservicios" ha existido durante los últimos años. La tecnología se está desarrollando activamente, la gente habla de ella en conferencias en línea y las escribimos nosotros mismos todos los días. Érase una vez, un nuevo enfoque ya se ha convertido en una rutina. Pero como arquitecto de Java, estoy interesado en cómo era el código antes, cómo cambió, qué métodos de ejecución son populares ahora y se usarán en 2021: asincronía, contenedores, FaaS.
Así nació este post en dos partes, que preparé para Habr en base a mis artículos del blog de BellSoft y la mesa redonda Joker 2020, donde discutimos el futuro de Java. La mejora real del ecosistema para backends hoy en día no puede existir sin comprender cómo crear microservicios: ¿escribir desde cero o cortar monolitos con un bisturí? Propongo en la primera parte hablar sobre su esencia, y en la segunda, descomponer el contenedor de microservicios en capas y observar la contribución de cada capa.
La principal ventaja está en la estructura.
La gran mayoría de los materiales de la arquitectura de microservicios lo comparan con los monolitos en términos de estructura. Cómo funcionan los componentes como un todo o de forma aislada. Los microservicios son independientes entre sí y pueden intercambiar datos a través de la red a través de protocolos arbitrarios, como la API REST. ¿Qué nos aporta? Como mínimo, la libertad de elegir cualquier herramienta, sin mirar el ESB, las restricciones de esquema y las sutilezas de la compatibilidad. La virtualización y la contenedorización también están evolucionando, y ahora los pequeños contenedores con Alpine Linux le permiten ejecutar muchos componentes a la vez en hardware previamente dedicado.
Tomemos un servicio simple como reservar un boleto o recargar una cuenta. Incluso antes de la llegada de los microservicios, el enfoque CRUD se utilizó para administrar el ciclo de vida de un objeto de datos en dichos sistemas. Pero toda la funcionalidad que proporciona operaciones CRUD para alguna entidad se puede aislar fácilmente. Luego, puede tratar por separado el escalado, el control de acceso y la interacción en general, por ejemplo, a través de REST.
Todo parece ir bien, ¿cuál es el truco?
Problemas y soluciones
Las diferentes partes de una aplicación monolítica se ejecutan en la memoria compartida y todas las solicitudes se envían al mismo servidor físico. Los microservicios se comunican entre sí a través de protocolos, y esto da lugar, por ejemplo:
dificultad para gestionar el tráfico y la latencia de la red;
fallas de solicitudes y otros errores;
la necesidad de serializar datos y cifrar conexiones.
, API Kafka/Redis/RabbitMQ , . Kafka DevOps.
, , . . , , — . - .
:
(Kafka, Kinesis);
, service mesh (Istio, OSM);
.
— :
, , :
, . streaming platform (, Kafka) , .
, . , . , , .
Service mesh («c ») . , , Sidecar.
, JVM, , .
. , , Docker- .
-, , . , .
- . . , — SOA.
. . , — . , , REST.
Java? , . Java EE 20 . : , XML javadoc ; ; Java 5. . Java EE.
, Java EE (, JNDI), , , . Web 1.0 Web 2.0, . .
Container dependency injection
« ». , . « » — . . , : trailing lambdas Kotlin Ktor; data- , Java 14 record- ( Lombok).
. , /. , , , , . IDE, , . — .
Contexts and Dependency Injection (CDI). CDI Java EE JSR 299/365 Weld, WildFly. — (Inversion of Control, IoC).
: , , ( Spring Data) HTML. . — , . , Convention over Configuration ( « »), IoC- , BeanFactory Spring. .
Como prometí en la introducción, esta publicación se ha convertido en una pequeña excursión a la historia de la arquitectura de microservicios, después de todo, sin ella, en ninguna parte. Trabajamos con una gran tecnología que tiene más de 20 años, pero que aún se siente moderna. Esto se debe a que los métodos están en demanda y en vivo, y no se convierten en heredados.
En la segunda parte, analizaré las capas del contenedor de microservicios en detalle, explicaré a qué afecta la elección correcta del tiempo de ejecución y le diré cómo reducir el consumo de recursos al mínimo.