En una arquitectura de microservicios débilmente acoplada, ¿cómo realiza un seguimiento de sus dependencias?

Una opción popular de arquitectura de alto nivel en un programa moderno es un sistema de microservicios basado en REST. Esto tiene varias ventajas, como acoplamiento flojo, reutilización fácil, restricción limitada de tecnologías que se pueden usar, alta escalabilidad, etc.

Pero uno de los problemas que preveo en dicha arquitectura es la poca visibilidad de cuáles son las dependencias de una aplicación. Por ejemplo, supongamos que tengo una aplicación que utiliza un conjunto de llamadas REST a diario. Esta aplicación también utiliza un segundo conjunto de llamadas REST, pero solo una vez por trimestre. Si escaneara los registros de la última semana, vería todas las llamadas diarias, pero probablemente no vería las llamadas trimestrales. Cuando llega el momento de refactorizar, las llamadas trimestrales tienen un alto riesgo de ruptura.

¿Qué patrones o herramientas se pueden usar para reducir este riesgo y proporcionar una mayor visibilidad de cuáles son las dependencias de una arquitectura débilmente acoplada?

— David dice reinstalar a Mónica
fuente

Esto es exactamente por qué el acoplamiento flojo puede ser malo. Cuando no hay dependencias de tiempo de compilación, la única forma de detectar errores, y nunca los detecta, es mediante pruebas automatizadas. La solución es algún tipo de prueba automatizada, que probablemente incluye pruebas unitarias, así como pruebas de integración.

— Frank Hileman

@FrankHileman Testing obviamente ayuda, pero me resulta difícil creer que esta sea la única solución que existe. Además, hay muchos lenguajes que no tienen comprobaciones en tiempo de compilación (es decir, JS o Python), por lo que incluso con un acoplamiento estrecho todavía tendría problemas.

— David dice reinstalar a Mónica

Los sistemas de tipo estático pueden detectar grandes cantidades de errores durante la fase de compilación. La única compensación por la falta de dicho sistema son las pruebas automatizadas, que yo sepa. La detección de errores estáticos mediante pruebas automatizadas o simplemente compilando siempre será más confiable que las pruebas.

— Frank Hileman

Una forma posible podría ser implementar el cliente API de cada servicio por separado e incluir a estos clientes como dependencias del proyecto. Con la API, los clientes también serían más fáciles de rastrear qué versión del servicio estamos consumiendo.

— Laiv

@Laiv Tengo curiosidad por los servicios RESTful, por lo que no es una opción, ya que cualquiera puede enviar solicitudes HTTP más o menos.

— David dice reinstalar a Mónica

Respuestas:

¿Qué patrones o herramientas se pueden usar para reducir este riesgo?

Mantener sus API y sus capacidades comerciales compatibles con versiones anteriores.

Proporcionar una mayor visibilidad de cuáles son las dependencias de una arquitectura débilmente acoplada

Controles de salud.

Mi servicio es un cliente para su capacidad de API mensual. Pero mi servicio es el cliente de su API cada vez que mi servicio se está ejecutando. Por lo tanto, mi servicio se activa cada 10 minutos, o lo que sea, se conecta a su API mensual y ejecuta el protocolo para asegurarse de que la capacidad que necesita mi servicio aún esté disponible.

Por lo tanto, sus registros le mostrarán con qué frecuencia algún otro servicio está verificando para ver si cada servicio en particular que ofrece todavía está disponible, al igual que le muestra con qué frecuencia se utiliza cada servicio en particular que ofrece.

— VoiceOfUnreason
fuente

Hay al menos dos ubicaciones donde puede encontrar las dependencias:

Configuración. El acceso a API externas requiere conocer mucha información sobre cada una de esas API. ID de acceso, claves secretas, puntos finales. Todo esto no puede ser en el código, ya que tal información será cambiar. Como ejemplo, recientemente comencé a migrar todos mis microservicios a SSL. Esto significa que cada servicio que se basa en el que se está migrando debe reconfigurarse para que apunte a la https://versión en lugar de http://. Me alegra que los puntos finales estuvieran en la configuración en lugar de estar codificados.
Interfaces No accede a un servicio directamente desde su código, porque la versión de la API cambiará, e incluso puede decidir cambiar a una API diferente. En su lugar, crea una capa de abstracción y utiliza la dependencia a través de una interfaz. Al seguir una lógica común al crear esas interfaces, puede facilitarle la vida más adelante cuando busque las dependencias.

Cuando llega el momento de refactorizar, las llamadas trimestrales tienen un alto riesgo de ruptura.

Para eso es la prueba de regresión.

No puede simplemente mirar el código, cambiarlo y confiar en sí mismo de que nada se rompió. Esto no funcionará en una arquitectura de microservicios. Esto tampoco funcionará en una aplicación monolítica. Un compilador puede detectar algunos de los errores que introducirá al modificar el código. En algunos idiomas, como Haskell, el compilador puede ser muy capaz y detectar la mayoría de los errores; Sin embargo, los compiladores para los idiomas principales no harán mucho por usted. Si no tienes pruebas, estás jodido. La presencia de microservicios es irrelevante.

— Arseni Mourzenko
fuente

-2

Las API REST se especifican en términos generales, por lo que en algún momento puede ser útil pasar a gRPC, google protobufs o Thrift para definir una interfaz RPC y luego versionarla.

— Patricio
fuente

Esto podría ser mejor como comentario ... pero honestamente, esto no explica mucho.

— David dice reinstalar a Mónica

Lo suficientemente justo. Una API de descanso no tiene una dependencia específica del tiempo de compilación en otro servicio porque el enlace entre los dos es solo una llamada de descanso HTTP, algo así como un host y una ruta. Con gRPC, o Protobuf o Thrift, se define una interfaz que se utiliza para generar código. El código generado se compila y versiona, y luego sus servicios se compilan contra esas interfaces. El resultado es que cada servicio depende claramente de una o más de sus otras interfaces de servicio. Espero que aclare mi respuesta!

— Patrick