Uno de los principales problemas en el desarrollo y posterior operación de microservicios es el ajuste competente y preciso de sus instancias. En mi opinión, el nuevo marco
microconfig.io puede ayudar. Le permite resolver con bastante elegancia algunas de las tareas rutinarias de configuración de aplicaciones.
Si tiene muchos microservicios, y cada uno de ellos viene con sus propios archivos / archivos de configuración, es probable que cometa un error en uno de ellos, que sin la destreza adecuada y un sistema de registro puede ser muy difícil de detectar. La tarea principal que establece el marco es minimizar la configuración de instancias duplicadas, reduciendo así la probabilidad de agregar un error.
Veamos un ejemplo. Supongamos que hay una aplicación simple con un
archivo de configuración
yaml . Puede ser cualquier microservicio en cualquier idioma. Veamos cómo se puede aplicar el marco a este servicio.
Pero primero, para mayor conveniencia, crearemos un proyecto vacío en el IDE de Idea instalando primero el complemento microconfig.io en él:
Configuramos la configuración de inicio del complemento, puede usar la configuración predeterminada, como en la captura de pantalla anterior.
Nuestro servicio se llama orden, luego en un nuevo proyecto crearemos una estructura similar:
En la carpeta con el nombre del servicio colocamos el archivo de configuración -
application.yaml . Todos los microservicios se inician en algún tipo de entorno, por lo que, además de crear la configuración del servicio en sí, es necesario describir el entorno en sí: para esto, cree la carpeta
envs y agregue un archivo con el nombre de nuestro entorno de trabajo. Por lo tanto, el marco creará archivos de configuración para los servicios en el entorno de desarrollo, ya que este parámetro se establece en la configuración del complemento.
La estructura del archivo
dev.yaml será bastante simple:
mainorder: components: - order
El marco funciona con configuraciones que se agrupan. Para nuestro servicio, seleccione un nombre para el grupo de orden principal. El marco encuentra cada grupo de aplicaciones en el archivo de entorno y crea configuraciones para todas ellas que encuentra en las carpetas correspondientes.
En el archivo de configuración del servicio de
pedidos , indicaremos hasta ahora solo un parámetro:
spring.application.name: order
Ahora ejecute el complemento y generará la configuración deseada de nuestro servicio para nosotros de acuerdo con la ruta especificada en las propiedades:
Puede
hacerlo sin instalar el complemento simplemente descargando el kit de distribución del marco y ejecutándolo desde la línea de comandos.
Esta solución es adecuada para su uso en el servidor de compilación.
Vale la pena señalar que el marco comprende perfectamente la sintaxis de
propiedad , es decir, los archivos de propiedad ordinarios que se pueden usar juntos en configuraciones
yaml .
Agregue otro servicio de
pago y complique el existente al mismo tiempo.
En
orden :
eureka: instance.preferIpAddress: true client: serviceUrl: defaultZone: http://192.89.89.111:6782/eureka/ server.port: 9999 spring.application.name: order db.url: 192.168.0.100
En
pago :
eureka: instance.preferIpAddress: true client: serviceUrl: defaultZone: http://192.89.89.111:6782/eureka/ server.port: 9998 spring.application.name: payments db.url: 192.168.0.100
El principal problema con estas configuraciones es la presencia de una gran cantidad de copiar y pegar en la configuración del servicio. Veamos cómo el marco ayuda a deshacerse de él. Comencemos con lo más obvio: la presencia de la configuración de
Eureka en la descripción de cada microservicio. Cree un nuevo directorio con el archivo de configuración y agregue una nueva configuración:
Y en cada uno de nuestros proyectos ahora agregaremos la línea
#include eureka .
El marco buscará automáticamente la configuración de eureka y la copiará a los archivos de configuración del servicio, mientras que no se creará una configuración de eureka separada, ya que no la especificaremos en el
archivo de entorno
dev.yaml .
Orden de servicio:
#include eureka server.port: 9999 spring.application.name: order db.url: 192.168.0.100
También podemos hacer la configuración de la base de datos en una configuración separada cambiando la línea de importación a
#include eureka, oracle .
Vale la pena señalar que cada cambio durante la regeneración de los archivos de configuración que el marco monitorea y coloca en un archivo especial al lado del archivo de configuración principal. La entrada en su registro se ve así: "La propiedad almacenada 1 cambia a
order / diff-application.yaml ". Esto le permite detectar rápidamente cambios en archivos de configuración grandes.
Eliminar las partes comunes de la configuración le permite deshacerse de muchos copiar y pegar innecesarios, pero no le permite crear de manera flexible una configuración para varios entornos: los puntos finales de nuestros servicios son únicos y codificados, lo cual es malo. Intentemos eliminarlo.
Una buena solución sería mantener todos los puntos finales en una configuración a la que otros puedan hacer referencia. Para hacer esto, el soporte para marcadores de posición se ha introducido en el marco. Así es como cambia el archivo de configuración de
Eureka :
client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/
Ahora veamos cómo funciona este marcador de posición. El sistema encuentra un componente llamado
puntos finales y busca
eurekaip en él, y luego lo sustituye en nuestra configuración. ¿Pero qué pasa con los diferentes entornos? Para hacer esto, cree el archivo de configuración en
puntos finales del siguiente tipo
application.dev.yaml . El marco de forma independiente, por extensión de archivo, decide a qué entorno pertenece esta configuración y la carga:
El contenido del archivo dev:
eurekaip: 192.89.89.111 dbip: 192.168.0.100
Podemos crear la misma configuración para los puertos de nuestros servicios:
server.port: ${ports@order}.
Todas las configuraciones importantes están en un solo lugar, lo que reduce la probabilidad de un error debido a los parámetros dispersos en los archivos de configuración.
El marco proporciona muchos marcadores de posición listos para usar, por ejemplo, puede obtener el nombre del directorio en el que se encuentra el archivo de configuración y asignarlo:
#include eureka, oracle server.port: ${ports@order} spring.application.name: ${this@name}
Debido a esto, no es necesario especificar adicionalmente el nombre de la aplicación en la configuración y también se puede mover a un módulo común, por ejemplo, al mismo eureka:
client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/ spring.application.name: ${this@name}
El archivo de configuración del
pedido se reducirá a una línea:
#include eureka, oracle server.port: ${ports@order}
En caso de que no necesitemos ningún ajuste de la configuración principal, podemos especificarlo en nuestra configuración y se aplicará durante la generación. Es decir, si por alguna razón necesitamos un nombre único para el servicio de pedidos, simplemente deje el parámetro
spring.application.name .
Supongamos que necesita agregar configuraciones de registro personalizadas al servicio, que se almacenan en un archivo separado, por ejemplo,
logback.xml . Cree un grupo separado de configuraciones para ello:
En la configuración básica, indicaremos el marco donde colocar el archivo de configuración de registro que necesitamos usando el
marcador de posición @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml
En el archivo
logback.xml , configuramos
apéndices estándar, que a su vez también pueden contener marcadores de posición, que el marco cambiará durante la generación de configuraciones, por ejemplo:
<file>logs/${this@name}.log</file>
Al
agregar la importación de
logback en la configuración del servicio, obtenemos automáticamente el registro configurado para cada servicio:
#include eureka, oracle, logback server.port: ${ports@order}
Es hora de familiarizarse con todos los marcadores de posición del marco disponibles con más detalle:
$ {this @ env} : devuelve el nombre del entorno actual.
$ {... @ name} : devuelve el nombre del componente.
$ {... @ configDir} : devuelve la ruta completa al directorio de configuración del componente.
$ {... @ resultDir} : devuelve la ruta completa al directorio de destino del componente (los archivos recibidos se colocarán en este directorio).
$ {this @ configRoot} : devuelve la ruta completa al directorio raíz del almacén de configuración.
El sistema también le permite obtener variables de entorno, por ejemplo, la ruta a Java:
$ {env @ JAVA_HOME}O bien, dado que el marco está escrito en
JAVA , podemos obtener variables del sistema similares a llamar a
System :: getProperty usando una construcción como esta:
${system@os.name}Vale la pena mencionar el soporte para el lenguaje de extensión
Spring EL . En la configuración, se aplican expresiones similares:
connection.timeoutInMs: #{5 * 60 * 1000} datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10}
y puedes usar variables locales en archivos de configuración usando la expresión
#var :
#var feedRoot: ${system@user.home}/feed folder: root: ${this@feedRoot} success: ${this@feedRoot}/archive error: ${this@feedRoot}/error
Por lo tanto, el marco es una herramienta bastante poderosa para la configuración fina y flexible de microservicios. El marco realiza perfectamente su tarea principal: eliminar copiar y pegar en la configuración, consolidar la configuración y, como resultado, minimizar los posibles errores, al tiempo que facilita la combinación de configuraciones y cambios para diferentes entornos.
Si está interesado en este marco, le recomiendo que visite su página oficial y lea la
documentación completa, o profundice en la fuente
aquí .