Simplifique la arquitectura compleja: hable sobre microservicios

¿Alguna vez has experimentado ese momento de dolor de cabeza? A medida que el sistema se hace cada vez más grande, las funciones se apilan unas sobre otras y hay que tener cuidado al cambiar una línea de código, por temor a afectar a todo el cuerpo. Supongo que muchos equipos han encontrado problemas similares: los servicios están enredados, todos los empleados tienen que estar en espera para un lanzamiento y las nuevas funciones se lanzan tan lentamente como un caracol. Se siente como un montón de cables enredados al azar, y cuanto más pasa, más difícil es desatarlo.

¿Pero es realmente esa la única manera en que pueden suceder las cosas? Piénselo de otra manera.

¿Por qué su arquitectura siempre está "atada"?

Imagínese si tuviera una aplicación enorme con todas las funciones empaquetadas juntas. Cada actualización, incluso el simple ajuste del color de un pequeño botón, requiere volver a implementar todo el sistema. Esto no es sólo una cuestión de eficiencia, sino más bien una aventura en curso: no sé si este cambio afectará a otras funciones completamente ajenas.

En este momento, apareció silenciosamente el concepto de microservicios. No es magia, es simplemente una forma más inteligente de organizar el código: dividir un sistema grande en pequeños servicios independientes. Cada servicio solo es responsable de una cosa y puede desarrollarse, implementarse y ejecutarse de forma independiente. ¿No suena mucho más refrescante?

Sin embargo, dividirse no es sólo una cuestión de hacer algunos cortes al azar. Si se descompone demasiado, la gestión será como un pedazo de arena suelta; si no se descompone lo suficiente, volverá al antiguo camino. Cómo captar este grado es el verdadero conocimiento.

¿Qué papel juega Spring Boot aquí?

Es posible que haya oído hablar de Spring Boot, que es como una caja de herramientas bien pensada que hace que la creación de microservicios sea menos dolorosa. Le ayuda a manejar muchas cosas triviales: la configuración se simplifica, la gestión de dependencias se vuelve intuitiva y el servidor integrado le evita tener que preocuparse por el medio ambiente. Puede concentrarse en su negocio en lugar de ajustar las configuraciones sin cesar.

Pero el hecho de que una herramienta sea fácil de usar no significa que pueda producir automáticamente una buena arquitectura. Del mismo modo que darte un juego de utensilios de cocina de primera categoría no significa que puedas cocinar una comida deliciosa de inmediato. La clave está en cómo lo uses.

Algunas ideas prácticas sin desvíos

¿A qué debemos prestar atención específicamente? Permítanme hablar sobre algunos puntos que se mencionan a menudo, pero que es fácil extraviarse en la operación real.

¿Cómo trazar los límites del servicio? Esta puede ser la primera pregunta que molesta a la gente. Mi sugerencia es: dividir por capacidades comerciales, no por nivel técnico. Por ejemplo, "Gestión de usuarios" podría ser un servicio y "Procesamiento de pedidos", otro. Cada servicio debe tener sus propios datos y tratar de evitar compartir bases de datos directamente. De esta manera, si ocurre un problema en el servicio, este no se caerá como una ficha de dominó.

¿Es mejor comunicarse más ligero o más pesado? Siempre hay diálogo entre servicios, pero la forma de diálogo es particular. Muchas personas quieren utilizar colas de mensajes complejas o cadenas de llamadas sincrónicas cuando aparecen por primera vez. De hecho, esto puede no ser apropiado. Para la mayoría de los escenarios, será suficiente mantener una API HTTP simple y directa o mensajería liviana. El diseño excesivo es a veces más problemático que el diseño insuficiente.

Las fallas son normales, no accidentes. En el mundo de los microservicios, es posible que un servicio esté temporalmente fuera de línea. No espere ser 100% estable para siempre. Por lo tanto, se debe considerar la tolerancia a fallas al diseñar: configuraciones de tiempo de espera, mecanismos de reintento, estrategias de degradación del servicio, todo lo cual debe pensarse de antemano. Es como llevar un paraguas cuando sales. Puede que no llueva todos los días, pero siempre es bueno tener uno.

La implementación y el seguimiento no se pueden realizar en el último momento. Si hay demasiados servicios, la implementación manual se convertirá en una pesadilla. Considere la posibilidad de automatizar su proceso de implementación desde el principio. De manera similar, el monitoreo no es un parche agregado después de conectarse. Cada servicio debe exponer métricas de estado, registros y métricas clave para que pueda ver el estado del sistema de un vistazo.

Hablemos de nuestras propias experiencias.

existirkpotenciaEn nuestra práctica técnica, consideramos los microservicios como un camino evolutivo más que como una revolución disruptiva. No es una panacea y no puede resolver todos los problemas, pero para escenarios adecuados (como proyectos que requieren una iteración rápida, desarrollo de equipos independientes y pilas de tecnología diversificadas) sí puede aportar una flexibilidad diferente.

Tendemos a empezar poco a poco, desglosando las piezas que cambian con más frecuencia y que son más fáciles de separar. Cada paso de separación va acompañado de contratos claros y garantías de prueba. Durante el proceso, se descubrió que se subestimaba seriamente la importancia de la documentación y la comunicación. Si la interfaz del servicio cambia, se debe notificar a todos los equipos relevantes a tiempo; La gestión de versiones de API también debe tener reglas; de lo contrario, habrá caos durante la actualización.

A veces se escuchan advertencias sobre la "complejidad de los sistemas distribuidos", y así es. Pero la complejidad no es un motivo para darse por vencido, es algo que hay que gestionar. Al elegir las herramientas adecuadas, establecer acuerdos claros y cultivar hábitos de colaboración entre los equipos, muchos problemas se pueden resolver en las primeras etapas.

Tener algunas charlas honestas

La arquitectura de microservicios no es el final, es solo un camino. Su valor no reside en la división en sí, sino en la independencia y velocidad que aporta. Si su equipo se ve abrumado por la complejidad de una arquitectura monolítica, intente repensarla desde esta perspectiva. Comience con módulos pequeños, pruebe sus ideas y luego amplíelas gradualmente. La tecnología siempre sirve a los objetivos comerciales, no permita que la arquitectura sea una limitación.

existirkpotencia, creemos que una buena solución técnica debe ser como una máquina precisa: cada componente realiza sus propias tareas y trabaja en conjunto para, en última instancia, impulsar el buen funcionamiento del conjunto. Requiere paciencia y atención constante a los detalles. Si usted también está explorando un camino similar, tal vez estos intercambios puedan brindarle una perspectiva ligeramente diferente.

Recuerde, no existe una única respuesta correcta, sólo opciones que son más apropiadas para la situación en cuestión. El requisito previo para tomar una buena decisión es siempre ver claramente cuál es su problema.

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.