Microservicios y bibliotecas compartidas

9

Estamos diseñando un sistema basado en microservicios independientes (conectados a través de un bus RabbitMq). El código (al menos para los primeros componentes) se escribirá en python (tanto python2 como python3). Ya tenemos una aplicación monolítica que implementa parte de la lógica empresarial, que queremos refactorizar como microservicios y ampliar. Una pregunta que me preocupa es:

¿Cuál es la mejor manera de compartir código entre los diferentes microservicios? Tenemos funciones auxiliares comunes (procesamiento de datos, registro, análisis de configuración, etc.), que deben ser utilizados por varios microservicios.

Los microservicios se desarrollarán como proyectos separados (repositorios git). Las bibliotecas comunes también se pueden desarrollar como un proyecto autónomo. ¿Cómo comparto estas bibliotecas entre los microservicios?

Veo varios enfoques:

copiar alrededor de la versión de la biblioteca que se necesita para cada microservicio y actualizar según sea necesario
liberar las bibliotecas comunes a un PyPi interno y enumerar esas bibliotecas como dependencias en los requisitos del microservicio
incluir el repositorio de la biblioteca como un submódulo git

Me gustaría leer un poco más sobre los enfoques sugeridos, las mejores prácticas y las experiencias pasadas antes de decidir cómo proceder. ¿Tienes alguna sugerencia o enlace?

python microservices

— dangonfast
fuente

No estoy lo suficientemente versado en microservicios (mi empresa ha comenzado recientemente a hacer algo similar) para responder, pero aquí hay un enlace a una presentación sobre por qué lo que está describiendo es una bandera roja y puede conducir a un "monolito distribuido" . Los microservicios no deberían haber requerido bibliotecas compartidas. Realmente solo deberían comunicarse entre una API bien definida como Swagger (ahora llamada API abierta ).

— Capitán Man

@CaptainMan: Claro, pero supongamos que tiene esta función simple: fib(n)(implementación de la serie de Fibonacci). No desea repetir esa implementación en cada microservicio. Eso pertenece a una utilsbiblioteca (versionada, para características y correcciones de errores). Eso no es un monolito distribuido, es solo una capa de funcionalidad común. Mi pregunta es cómo manejar esta capa a nivel de implementación.

— dangonfast

Nuestros microservicios han compartido bibliotecas para garantizar que se comuniquen con todos los demás microservicios de nuestro sistema de la misma manera. No estoy seguro de cómo sería posible hacer eso con bibliotecas no compartidas; Como mínimo, todo el mundo necesitaría algunas bibliotecas de manipulación XML / JSON / etc. Todavía no he visto esa presentación, pero ¿tenía en mente un significado más específico de "biblioteca compartida" que el que estoy pensando?

— Ixrec

1

@ jeckyll2hide Estamos usando C ++, pero nuestra infraestructura para esto es más o menos equivalente a su segundo punto: repositorio separado, todos declaran sus dependencias, sistema de compilación estándar que sabe cómo encontrar esas dependencias en el momento de la compilación, etc.

— Ixrec

1

Me siento como un tonto, su pregunta no es realmente sobre microservicios compartiendo bibliotecas específicamente, sino realmente cómo compartir las bibliotecas de su equipo con el equipo. Sé lo suficiente sobre eso para publicar una respuesta.

— Capitán Man

5

Su segunda opción es definitivamente el camino a seguir. Divida las bibliotecas comunes e instálelas en su servidor PyPi local.

La opción 1 es horrible porque las mejoras en las bibliotecas serán difíciles de propagar a otros que puedan usarla.

La opción 3 es similar a la opción 1.

El patrón común es configurar Jenkins para que cuando empuje al maestro de un repositorio de biblioteca, realice una compilación de Python y lo cargue automáticamente al repositorio de PyPi. Una vez que escriba este script de compilación, nunca tendrá que preocuparse por empaquetar bibliotecas y cargarlas manualmente en PyPi. Y con esta opción, todas las actualizaciones de la biblioteca estarán disponibles instantáneamente para posiblemente actualizarse a otros microservicios.

Configurar su propio servidor PyPi es muy fácil. Me gusta esta guia

— Tommy
fuente

1

Estoy de acuerdo en que la opción 2 es la mejor, pero la opción 3 con los submódulos tiene mucho más en común con la opción 2 que con la opción 1.

— 8bittree

@ 8bittree: sí, la opción 3 es similar a la opción 2, pero tener el servidor git (el control remoto "central") es el mecanismo de distribución del paquete. Por un lado, está usando git para algo que no es (gestión de dependencias), por otro lado, reduce el número de componentes (sin necesidad de PyPi privado)

— dangonfast

2

No es un tipo de Python, pero el servidor PyPi parece la mejor opción. Una búsqueda rápida en Google da la apariencia de que es análogo a tener un repositorio Nexus para los frascos Java del equipo.

Realmente, siempre que se implemente en algún tipo de repositorio central (en la oficina / equipo) con el que su herramienta de gestión de dependencia de elección pueda trabajar (leer y desplegar en), entonces es una buena opción.

La opción 1 es realmente la peor, nunca debería tener que lidiar manualmente con las dependencias. Es un dolor. En la universidad, antes de conocer a Maven, y cuando pensaba que Git era demasiado complicado, hacíamos todo de forma manual, desde fusionar el código de todos hasta configurar las rutas de clase, hasta obtener dependencias. Fue un dolor, en serio no quisiera que nadie pasara ni siquiera una fracción de ese problema, especialmente en un entorno de trabajo donde la eficiencia es importante.

La opción 3 probablemente funcionaría bien, pero no tiene ningún beneficio real sobre un PyPi local (aparte de ser más fácil de configurar, pero los beneficios de un sistema de administración de dependencia real son mucho mejores).

— Capitán Hombre
fuente

1

En primer lugar, dividir un monolito en microservicios siempre será difícil. Consulte Gestión de datos descentralizada: encapsular bases de datos en microservicios para tener una idea de por qué.

Dicho esto, hay varias recetas sobre cómo hacerlo de manera relativamente sensata. Uno de ellos es http://12factor.net/ . Eso diría que debe mantener cada biblioteca y aplicación de forma independiente, luego administrar explícitamente las dependencias. Si sigues esa ruta, te recomendaré que tengas un comando simple que actualice todas las dependencias a lo que sea actual, y lo ejecutes regularmente para cada microservicio. Es importante contar con un proceso de lanzamiento en el que bloquee las versiones de las bibliotecas en producción. Sin embargo, realmente, realmente , realmente no quieres estar en una posición donde las dependencias se vuelven obsoletas y no sabes qué hay ahí fuera.

También enfóquese en hacer que sus bibliotecas de respaldo sean lo más ajustadas y enfocadas posible. Siempre habrá una atracción natural para comenzar a agregar cosas a las bibliotecas principales para compartirlas fácilmente. Haga eso, y rápidamente atraerá toda la bola de espagueti existente a las bibliotecas compartidas y volverá efectivamente al desorden que tiene ahora. Por lo tanto, es mejor corregir en exceso a la inversa.

— btilly
fuente

0

Debería poder ir sin servidor apuntando directamente desde un archivo de dependencia de paquete de Python a los repositorios privados de GitHub que contienen las bibliotecas. Pipenv y Poeta apoyan esto, creo.

— Dogweather
fuente