¿Cómo elegir la arquitectura de microservicios? Haga que su sistema funcione de manera más estable

¿Lo has encontrado? El sistema estaba bien cuando se conectó por primera vez, pero se bloqueó cuando había demasiados usuarios. Agregue una nueva característica y todo el sistema deberá volver a probarse. El equipo quería cambiar algo, pero también surgieron problemas en otros lados. Para ser honesto, muchos equipos se enfrentan a este tipo de problemas: la arquitectura que eligieron originalmente ahora está bloqueada.

¿Qué hacer? Los microservicios parecen una buena idea, pero ¿cómo hacerlo específicamente?

¿Desmantelar o no desmantelar? esto es un problema

Algunos equipos simplemente juntan todo el código y piensan que es así de simple. De hecho, el desarrollo fue rápido al principio, pero después de medio año, el código se volvió un desastre. Nadie se atreve a moverse con indiferencia porque no sabe dónde se verá afectado.

Otros equipos están demasiado divididos. Es necesario llamar a una función simple en cinco o seis servicios y, para comprobar el problema, hay que mirar tres o cuatro paneles de seguimiento. La implementación es aún más problemática. Lo que se podría haber hecho en un día ahora requiere la coordinación de varios equipos.

Es como construir Lego. Si todas las piezas están pegadas, tendrás que desmantelar todo el edificio si quieres reemplazar las ventanas. Pero si cada parte es demasiado pequeña para verla, le dolerán las manos cuando la junte y será fácil perderla.

Entonces, ¿cómo desmantelarlo?

Encuentra ese punto "perfecto"

En realidad, una buena arquitectura de microservicios consiste en encontrar un equilibrio. Debe ser lo suficientemente independiente como para permitir que el equipo se desarrolle de forma independiente, pero lo suficientemente compacto como para no complicar cosas simples.

¿Cómo encontrar este punto? Mire el negocio en sí. Si una función cambia con frecuencia, debería ser un servicio independiente. Si un conjunto de datos siempre aparece junto, debería ser así. Por ejemplo, si la información del usuario, desde el registro hasta el inicio de sesión y la información personal, se divide en tres servicios, la interfaz deberá ajustarse tres veces cada vez que se muestre la página del usuario. ¿Por qué molestarse?

Pero el sistema de pedidos es diferente. Realizar un pedido es un proceso, el pago es otro y el envío es otro. Estos son completamente separables porque cambian con diferentes frecuencias y tienen diferentes equipos responsables de ellos.

¿Sabías? A veces lo más difícil no es la tecnología, sino la determinación de desentrañar el código que se ha enredado. Es como un garaje organizado desde hace muchos años. Al principio siempre pensé "esto podría ser útil", pero al final me resistí a tirar nada. Pero después de organizarlo, descubrirás que el espacio es más grande y es más fácil encontrar cosas.

Deje que los miembros del servicio hablen entre sí.

Una vez desarmado, ¿cómo podemos comunicarnos? Hay dos formas comunes: una es la llamada sincrónica, como hacer una llamada telefónica, te llamo y debes contestar de inmediato; el otro es la mensajería asincrónica, como enviar un correo electrónico, yo lo envié y usted puede manejarlo a su conveniencia.

Las llamadas sincrónicas son simples y directas, adecuadas para escenarios que requieren una respuesta inmediata. Por ejemplo, al consultar el saldo de un usuario, no puedes esperar cinco minutos antes de que se muestren los resultados, ¿verdad? Pero tiene un problema: si el servicio llamado se bloquea, la persona que llama también quedará bloqueada. Es como una ficha de dominó, cae una y luego cae la otra.

Los mensajes asincrónicos son más flexibles. Los servicios se comunican a través de colas de mensajes y el remitente no tiene que esperar a que el receptor termine de procesar. Incluso si el servicio de recepción no está disponible temporalmente, el mensaje permanecerá esperando en la cola sin afectar al remitente. Esto es como ir a la oficina de correos a enviar una carta. Puedes simplemente poner la carta en el buzón e irte sin esperar a que el cartero la recoja.

Pero la asincronía tiene un precio. El sistema se vuelve más complejo, gestiona colas de mensajes y se ocupa de mensajes perdidos o duplicados. A veces incluso se necesitan servicios especializados para rastrear dónde ha ido un proceso empresarial.

¿Cuál elegir? Depende de cuánta demora pueda tolerar su empresa y cuánta complejidad pueda aceptar. No existe un bien o un mal absoluto, sólo si es adecuado o no.

¿Qué hacer con los datos? Dividir o no dividir

El almacenamiento de datos es quizás el problema más difícil en los microservicios. El enfoque tradicional es que todos los servicios compartan una base de datos. Sencillo, ¿verdad? Pero el problema también está aquí. Una vez que se cambia la estructura de la base de datos, todos los servicios pueden verse afectados. Para empeorar las cosas, los servicios se acoplarán implícitamente a través de la base de datos: si cambio un campo, ¿cómo puedo saber si se está utilizando?

El estado ideal de los microservicios es que cada servicio tenga su propia base de datos. De esta manera, los servicios están realmente desacoplados y los cambios en la estructura de la base de datos de un servicio no afectarán a otros servicios. Pero aquí viene el problema: los datos empresariales están naturalmente relacionados. El pedido necesita conocer la información del usuario y la logística necesita conocer los detalles del producto. ¿Cómo sincronizar estos datos?

Hay dos métodos comunes. Una es obtener los datos requeridos a través de API entre servicios, como ir a la casa de un vecino a pedir prestado algo. La ventaja es que los datos siempre están actualizados, pero la desventaja es que el rendimiento del sistema puede verse afectado si la cadena de llamadas es larga.

La otra es la replicación de datos, donde cada servicio almacena una copia de los datos que necesita. Así como tú tienes herramientas en casa, yo también compro un juego de las mismas herramientas. De esta manera, no hay necesidad de llamadas frecuentes entre servicios, pero la sincronización de datos se ha convertido en un nuevo problema: ¿cómo garantizar que los datos que tengo en la mano sean consistentes con los suyos?

kpotenciaCuando ayudamos a los clientes a diseñar arquitectura, a menudo recomendamos una solución híbrida: los datos centrales son independientes y los datos compartidos se sincronizan a través de eventos. Cuando se actualiza la información del usuario, el servicio de usuario publicará un evento "El usuario ha actualizado" y otros servicios que prestan atención a este evento actualizarán sus propios datos relacionados almacenados. Esto mantiene la independencia y garantiza la coherencia de los datos.

Desafíos de operación y mantenimiento: de la complejidad a la simplicidad

De hecho, los microservicios son más complejos de implementar que las aplicaciones monolíticas. Imagínese que en el pasado solo tenía que iniciar una aplicación, pero ahora tiene que iniciar una docena o incluso docenas de servicios. ¿Qué pasa con el seguimiento? ¿Cómo comprobar el registro? ¿Cómo localizar rápidamente un problema cuando algo sale mal?

Aquí es donde se necesitan buenas herramientas y procesos. La tecnología de contenedores unifica la implementación. Cada servicio está empaquetado en una imagen de contenedor y se ejecuta igual en cualquier entorno. Las herramientas de orquestación lo ayudan a administrar estos contenedores: reinicie automáticamente cualquier contenedor que falle y expanda automáticamente cuando aumente el tráfico.

El seguimiento también se realiza en capas. Depende del estado general del sistema, así como del rendimiento de los servicios individuales. El seguimiento de enlaces es particularmente útil. Una solicitud pasa por cinco o seis servicios. Puede ver claramente cuánto tiempo pasó en cada servicio y en qué paso se quedó atascado.

La recopilación de registros es igualmente importante. Los registros de todos los servicios se reúnen y se buscan utilizando la misma interfaz. De lo contrario, cuando ocurre un problema, deberá iniciar sesión en siete u ocho servidores para verificar los registros respectivamente. Para cuando se haya comprobado el problema, el usuario habrá huido.

De hecho, la estructura crece

Dicho todo esto, quizás te preguntes: ¿Qué patrón arquitectónico es mejor?

La verdad es que no existe una respuesta estándar. La arquitectura más adecuada debería surgir de su negocio real, en lugar de copiar los diseños de otras personas.

Al principio, puede comenzar con una aplicación monolítica, pero debe organizar conscientemente el código por módulos comerciales. Cuando un módulo realmente necesita desarrollarse de forma independiente, divídalo en microservicios. Esta evolución gradual es más práctica y menos riesgosa que diseñar una arquitectura de microservicio perfecta desde el principio.

kpotenciaEl equipo ha realizado muchos viajes de este tipo. Desde el código inicial hasta borrar los límites del servicio; desde scripts de implementación manual hasta canalizaciones automatizadas; desde la codificación cuando ocurren problemas hasta la recuperación automática del sistema. Este proceso es como podar un árbol. En lugar de cortar todas las ramas a la vez, puedes recortarlas lentamente según sea necesario para que el árbol crezca más saludable.

La arquitectura no son las líneas del dibujo, sino el esqueleto que sustenta el funcionamiento del negocio. Debe ser fuerte pero no rígido; debe ser flexible pero no suelto. Cuando se encuentra ese equilibrio, el sistema cobra vida: crece, se adapta y permanece estable a pesar del cambio.

¿No es esto lo que perseguimos? Deje que la tecnología realmente sirva al negocio, en lugar de dejar que el negocio se adapte a la tecnología. Cuando la arquitectura ya no sea un problema que te preocupe todos los días, podrás centrarte más en la creación de valor en sí misma. En ese momento, es posible que haya olvidado la existencia de la arquitectura: la mejor arquitectura es a menudo la arquitectura que la gente no puede sentir.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en tecnología de accionamiento modular, Kpower integra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.