Puntos clave:
- La interacción entre componentes directamente entre sí puede conducir a un comportamiento inesperado que es difícil de comprender para los desarrolladores, operadores y analistas comerciales.
- Para garantizar la sostenibilidad empresarial, debe ver todas las interacciones que surgen en el sistema.
- : , -; , ; , ; (process mining), ; , .
- , , , .
En 2018, conocí a un arquitecto de una gran empresa de Internet. Me dijo que siguen todas las pautas correctas y dividen la funcionalidad en pequeños fragmentos dentro de diferentes áreas, aunque no llaman a este estilo arquitectónico "microservicios". Luego hablamos sobre cómo estos servicios interactúan entre sí para respaldar la lógica empresarial que trasciende los límites del servicio, porque aquí es donde la teoría se pone en práctica. Dijo que sus servicios interactúan utilizando eventos publicados en el autobús; este enfoque se llama " coreografía " (lo hablaré con más detalle a continuación). La empresa considera que esto es óptimo en términos de reducción de la cohesión. Pero se enfrentaron a un problema: es difícil entender lo que está sucediendo en el sistema y es aún más difícil cambiarlo. " Este no es el baile coreografiado que ves en las presentaciones de microservicios, ¡esto es un salto incontrolable! "
Todo esto está en sintonía con lo que otros clientes me han dicho, por ejemplo, Josh Wolf de Credit Sense :" El sistema que estamos reemplazando utiliza una coreografía compleja de igual a igual que requiere el análisis de varias bases de código para comprender ".
Entendamos esta situación con un ejemplo simplificado. Supongamos que está creando una aplicación de cumplimiento de pedidos. Ha elegido utilizar una arquitectura basada en eventos y ha elegido, por ejemplo, Apache Kafka como bus de eventos. Cuando alguien realiza un pedido, el servicio de pago genera un evento que es recogido por el servicio de pago. Este servicio de pago recibe dinero y genera un evento que es recogido por el servicio de inventario.
Flujo coreografiado de eventos.
La ventaja de este enfoque es que puede agregar fácilmente nuevos componentes al sistema. Supongamos que desea crear un servicio de notificación que envíe correos electrónicos a sus clientes. Simplemente puede agregar un nuevo servicio y suscribirse a los eventos apropiados sin tocar el resto del sistema. Y ahora puede administrar de forma centralizada su configuración de interacción y la complejidad de las notificaciones que cumplen con los requisitos del GDPR (reglamento de protección de datos de la UE).
Este estilo de arquitectura se llama coreografía porque no es necesario que un orquestador les diga a los otros componentes qué hacer. Aquí, cada componente genera eventos a los que otros componentes pueden reaccionar. Se supone que este estilo reduce el acoplamiento entre componentes y facilita el diseño y la modificación del sistema, como ocurre con nuestro esquema de servicio de notificación.
Pérdida de transparencia en el flujo de eventos.
Quiero centrarme en la pregunta que surge con más frecuencia cuando participo en discusiones sobre esta arquitectura: "¿Cómo evitar perder la transparencia (y probablemente el control) del flujo de eventos?" En un estudio , Camunda (donde trabajo) preguntó sobre el uso de microservicios. El 92% de los encuestados al menos los ha considerado, y el 64% ya los ha utilizado de una forma u otra. Esto ya no es una exageración. Pero en ese estudio, también preguntamos sobre las dificultades y recibimos una clara confirmación de nuestros temores: la mayoría de las veces nos informaron sobre la pérdida de transparencia de un extremo a otro de los procesos comerciales que involucran múltiples servicios.
¿Recuerda arquitecturas basadas en múltiples activadores de bases de datos? Arquitecturas en las que nunca se sabe qué sucederá exactamente en respuesta a alguna acción, e incluso por qué sucederá esto. A veces me recuerdan esto por las dificultades asociadas con los microservicios reactivos, aunque tal comparación es claramente inapropiada.
Asegurar la transparencia
¿Qué se puede hacer en tal situación? Los siguientes enfoques lo ayudarán a recuperar la transparencia, pero cada uno tiene sus propios méritos y deméritos:
- Rastreo distribuido (como Zipkin o Jaeger).
- Lagos de datos o herramientas analíticas (como Elastic).
- Control y análisis de minería de procesos (por ejemplo, ProM).
- Seguimiento mediante la automatización del flujo de tareas (como Camunda).
Tenga en cuenta que todos estos enfoques implican observar un sistema en ejecución y examinar los flujos de datos en él. No conozco ninguna herramienta de análisis estático que pueda extraer información útil.
Seguimiento distribuido
Este enfoque monitorea la pila de llamadas entre diferentes sistemas y servicios. Para esto, se utilizan identificadores únicos, generalmente agregados a ciertos encabezados (por ejemplo, en HTTP o encabezados de mensajes). Si todos en su sistema entienden o al menos transmiten estos encabezados, puede rastrear el intercambio de solicitudes entre servicios.
Normalmente, el seguimiento distribuido se utiliza para comprender cómo fluyen las solicitudes en el sistema, para encontrar dónde hay fallas e investigar las causas de la degradación del rendimiento. Las ventajas del enfoque incluyen la madurez del conjunto de herramientas y el ecosistema viviente que lo acompaña. Por lo tanto, será relativamente fácil para usted comenzar a usar el rastreo distribuido, incluso si generalmente tiene que (quizás de manera agresiva) instruir a sus aplicaciones o contenedores.
Entonces, ¿por qué no utilizar este enfoque para comprender cómo los procesos comerciales generan eventos? Por lo general, hay dos razones para esto:
- . , , . . , -.
- . , , 90 % . Three Pillars with Zero Answers — towards a New Scorecard for Observability. .
Entonces, por sí solo, el rastreo no es adecuado para nosotros. Sería lógico recurrir a un enfoque similar, pero teniendo en cuenta nuestra tarea específica. Por lo general, esto significa recopilar no rastros, sino eventos comerciales o temáticos importantes que ya puede haber encontrado. A menudo, la solución se reduce a crear un servicio que escuche todos los eventos y los almacene en la base de datos, lo que puede aumentar la carga en el sistema. Hoy en día, mucha gente usa Elastic para esto.
Es un mecanismo poderoso que es relativamente fácil de implementar. Y ya ha sido implementado por la mayoría de nuestros clientes impulsados por eventos. El principal obstáculo para la implementación suele ser la cuestión de quién, en una gran organización, gestionará dicha herramienta, porque ciertamente debe gestionarse de forma centralizada. Le resultará fácil crear su propia interfaz de usuario para trabajar con este mecanismo, lo que le permitirá encontrar rápidamente información relevante para determinadas consultas.
Un ejemplo de una interfaz de monitoreo de eventos .
Las desventajas incluyen la falta de gráficos que faciliten el trabajo con la lista de eventos. Pero puede agregarlos a la infraestructura, por ejemplo, proyectando eventos en un renderizador como BPMN. Los marcos pequeños como bpmn.io le permiten agregar información a los diagramas que se muestran como páginas HTML simples ( ejemplo ) que se pueden empaquetar en el complemento de Kibana.
Este modelo no se puede ejecutar con ningún módulo de gestión de procesos de negocio, es solo un diagrama que se utiliza para visualizar los eventos registrados. Desde este punto de vista, tiene cierta libertad para elegir el detalle de la pantalla. Y si está especialmente interesado en la imagen completa, puede crear modelos que muestren eventos de diferentes microservicios en un diagrama. Un diagrama como este no le impedirá realizar cambios en los servicios individuales, por lo que la flexibilidad de su empresa no se verá afectada. Pero existe el riesgo de que los diagramas se vuelvan obsoletos en comparación con el estado actual del sistema operativo.
Herramientas de minería de procesos
En el enfoque anterior, tendría que modelar explícitamente el diagrama que se utilizará para la representación. Pero si no podemos conocer de antemano la naturaleza del flujo de eventos, primero debemos investigarlo.
Esto se puede hacer utilizando herramientas para monitorear y analizar procesos. Pueden crear y mostrar gráficamente un diagrama completo, lo que a menudo le permite explorar los detalles, especialmente los relacionados con los cuellos de botella del sistema o las posibles optimizaciones.
Suena como la solución perfecta a nuestro problema. Desafortunadamente, estas herramientas se usan con mayor frecuencia para investigar procesos en arquitecturas heredadas, por lo que se enfocan en analizar registros y funcionan de manera mediocre con transmisiones en vivo de eventos. Otra desventaja es que son herramientas puramente científicas que son difíciles de usar (por ejemplo, ProM) o muy pesadas (por ejemplo, Celonis). En mi experiencia, no es práctico utilizar este tipo de herramientas en iniciativas típicas de microservicios.
En cualquier caso, la exploración de procesos y el análisis de datos brindan interesantes oportunidades de transparencia en los flujos de eventos y los procesos comerciales. Con suerte, pronto habrá una tecnología con una funcionalidad similar, pero más liviana, más amigable para los desarrolladores y más fácil de implementar.
Seguimiento con automatización del flujo de tareas
Otro enfoque interesante es modelar los flujos de tareas y luego implementarlos y ejecutarlos a través del módulo de control. Este modelo es especial en el sentido de que solo rastrea eventos y no hace nada activamente. Es decir, no gestiona nada, solo registra. Hablé sobre esto en Kafka Summit San Francisco 2018 , usando Apache Kafka y el módulo de flujo de trabajo de código abierto Zeebe para la demostración .
Esta oportunidad es especialmente interesante. Hay muchas innovaciones en el campo de los módulos de control, lo que conduce a la aparición de herramientas compactas, fáciles de desarrollar y altamente escalables. Escribí sobre esto en Eventos, flujos y servicios de larga duración: un enfoque moderno para la automatización del flujo de trabajo . Las desventajas obvias incluyen la necesidad de un modelo preliminar del flujo de tareas. Pero, por otro lado, este modelo se puede ejecutar utilizando el módulo de control de procesos, a diferencia del monitoreo de eventos. Básicamente, comienza a procesar instancias para eventos entrantes o asigna eventos a una instancia. También te permite comprobar si la realidad coincide con tu modelo.
Además, este enfoque le permite aprovechar toda la cadena de herramientas proporcionada por la plataforma de automatización del flujo de tareas. Puede ver el estado real del sistema, realizar un seguimiento de los SLA, detectar fallas en las instancias de proceso o realizar un análisis exhaustivo de los datos históricos de auditoría.
Un ejemplo de seguimiento de un flujo de tareas.
Cuando probé este enfoque con nuestros clientes, fue fácil de configurar. Simplemente armamos un componente genérico que recibe eventos del bus y lo emparejamos con el módulo de control de flujo de tareas. Si el evento no pudo conciliarse, usamos una pequeña tabla de decisiones para determinar si podría ignorarse o el evento conduciría a un incidente que tendría que ser investigado más tarde. También mejoramos los módulos de control de flujo de tareas que se utilizan dentro de los microservicios para ejecutar la lógica empresarial de modo que generen ciertos eventos (por ejemplo, una instancia de proceso se inicia, se completa o ha completado alguna etapa) que serán parte del panorama general.
Todo esto es similar al monitoreo de eventos, pero con énfasis en los procesos comerciales. A diferencia del seguimiento, el enfoque captura todos los eventos comerciales y muestra el panorama general en diferentes formatos adecuados para diferentes partes interesadas.
Perspectiva empresarial
La disponibilidad de procesos comerciales para el monitoreo le permite comprender el contexto. Puede ver para una instancia específica cómo, cuándo y en qué estado terminó. Esto significa que puede comprender qué camino no siguió este proceso (y otros a menudo lo siguen) y qué eventos o datos llevaron a ciertas decisiones. También puede comprender lo que puede suceder en un futuro próximo. Otros tipos de seguimiento no lo permiten. Si bien hoy en día no es habitual discutir el tema de la coherencia entre el negocio y la TI, es imperativo que los no especialistas también puedan comprender los procesos comerciales y cómo fluyen los eventos a través de diferentes microservicios.
Del seguimiento a la gestión
El seguimiento de procesos es una gran herramienta para brindar monitoreo operativo, informes, KPI y transparencia; todos estos son factores importantes para mantener la flexibilidad de la empresa. Pero en los proyectos actuales, el seguimiento es solo el primer paso hacia una administración y una orquestación más profundas en su ecosistema de microservicios.
Por ejemplo, puede comenzar monitoreando los tiempos de espera en los procesos de un extremo a otro. Cuando se agota el tiempo de espera, se realiza una acción automáticamente. En el siguiente ejemplo, después de 14 días notificaremos al cliente sobre el retraso, pero aún esperaremos. Y después de 21 días cancelaremos el pedido.
Curiosamente, enviar un equipo para cancelar un pedido aquí es una orquestación que a menudo se discute de manera controvertida.
Orquestación
A menudo escucho que la orquestación debe evitarse porque conduce a la coherencia o interrumpe la autonomía de microservicios individuales y, por supuesto, puede implementarse de manera deficiente. Pero también es posible implementar la orquestación de una manera que sea consistente con los principios de los microservicios y brinde un gran valor al negocio. Hablé de esto en detalle en InfoQ New York 2018 .
Para mí, la orquestación significa que un servicio puede decirle a otro que haga algo. Y eso es todo. Esta no es una conexión cercana, sino un tipo diferente de conexión. Recordemos nuestro ejemplo con una orden. Puede ser aconsejable que el servicio de caja registradora genere un pedido y lo coloque en el bus del evento sin saber quién lo procesará. El servicio de pedidos recoge el evento sobre el pedido que ha aparecido. El destinatario se entera del evento y decide hacer algo al respecto. Es decir, la cohesión está presente del lado del receptor.
Con el pago, la situación es diferente, ya que es bastante extraño que el servicio de pago sepa por qué se ha recibido el pago. Pero necesitará este conocimiento para reaccionar a los eventos correctos como realizar o realizar un pedido. También significa que el servicio tendrá que cambiarse cada vez que desee recibir pagos por nuevos productos o servicios. En muchos proyectos, esta conexión desagradable se pasa por alto al generar los eventos de pago necesarios, pero estos no son eventos, ya que el remitente quiere que alguien haga algo al respecto. ¡Esto es un equipo! El servicio de pedidos ordena al servicio de pago que reciba dinero. En este caso, el remitente sabe qué comando enviar y lo hace, es decir, la cohesión está presente en el lado del remitente.
Para que toda interacción entre dos servicios sea eficaz, implica cierto grado de acoplamiento. Pero dependiendo de la tarea específica, puede ser recomendable implementar la conectividad en uno de los lados.
El servicio de pedidos puede incluso ser responsable de la orquestación y otros servicios, rastreando las etapas de cumplimiento del pedido. Discutí los beneficios de este enfoque en detalle en la charla anterior. El truco es que una buena arquitectura requiere equilibrar la orquestación y la coreografía, lo que no siempre es fácil de hacer.
Sin embargo, en este artículo, quería centrarme en la transparencia. Y hay una ventaja obvia en la orquestación mediante el módulo de flujo de tareas: un modelo no es solo un código para que lo ejecute el orquestador, sino que se puede utilizar para proporcionar transparencia al flujo.
Conclusión
Es muy importante garantizar la transparencia de sus procesos comerciales, independientemente de su implementación. Consideré diferentes enfoques, y en proyectos reales, todo se reduce a algún tipo de monitoreo de eventos usando herramientas como Elastic, o al seguimiento de procesos usando módulos de control. En parte, la elección puede depender del caso específico y los roles de las personas involucradas. Por ejemplo, un analista de negocios necesita comprender los datos recopilados de todas las instancias de proceso con el grado de detalle requerido, mientras que un oficial de operaciones necesita analizar un proceso específico en diversos grados de detalle y, probablemente, adquirir herramientas para resolver rápidamente los incidentes a nivel del sistema.
Si su proyecto se basa en gran medida en la coreografía, el seguimiento del proceso puede llevarlo a agregar orquestación. Y creo que este es un paso muy importante para mantener un control a largo plazo sobre sus procesos comerciales. De lo contrario, puede "crear un sistema controlado por eventos cuidadosamente desacoplado sin darse cuenta de que perderá transparencia a medida que aumenta el número de eventos y procesos y, por lo tanto, se generará problemas en los próximos años", como dijo Martin Fowler . Si está trabajando en un sistema completamente nuevo, busque un equilibrio entre la orquestación y la coreografía desde el principio.
Sin embargo, independientemente de las características específicas de la implementación del sistema, asegúrese de proporcionar a la empresa una visualización comprensible de los procesos comerciales implementados mediante servicios interactivos.