[Python-es] Ejemplo de microservicios (Sistema distribuido)

Vie Abr 28 07:38:37 EDT 2017

El 27 de abril de 2017, 13:28, lasizoillo <lasizoillo en gmail.com> escribió:

> Buenas,
>
> Siento ser así, pero creo que te voy a plantear más dudas de las que
> te voy a resolver. Pero de todas formas te las vas a acabar
> encontrando, así que al lío.
>
> El día 26 de abril de 2017, 21:24, Luciano Andino
> <lucianoandino.ar en gmail.com> escribió:
> > Buenas, este es mi primer email a la lista. Les consulto: Tengo que
> > desarrollar una aplicación del tipo "Hotel" (clientes, habitaciones,
> > reservas, etc) pero utilizando microservicios. A detallar:
> >
> > * Un frontend del tipo API REST oauth2 (logueandose con la cuanta de
> gmail
> > por ejemplo), que interactue con el backend de hotel (utilizando
> > microservicios).
>
> Aparte de los que te comenta yamila, tienes otros frameworks como Falcon o
> Sanic
> https://falconframework.org/
> https://github.com/channelcat/sanic
>
> Estos que te comento te pueden dar un rendimiento mayor a costa de
> menor estabilidad y que muchas cosas que te las vas a tener que hacer
> tu. Como tu problema es ya bastante complejo, tira por los que te ha
> recomendado yamila y no mires un solo benchmark hasta que tengas el
> problema resuelto ;-) Django y Flask son dos buenas opciones.
>
> >
> > * El backend estará encapsulado en docker, porque a efectos de
> > geolocalización del usuario web, el frontend se comunicará con el backend
> > más cercano a través del UUID. Con esto quiero decir que habría más de un
> > backend. (Sistema distribuido)
>
> A este párrafo no le he encontrado el sentido. Docker permite
> contenedores de forma sencilla, lo cual es útil para montar un entorno
> de desarrollo o un sistema distribuido. Hay otras formas de hacer
> sistemas distribuidos. Pero bueno, aceptemos que tenemos docker en el
> sistema y que necesitas saber que instancia se va a encargar de hacer
> el trabajo.
>
> Docker tiene un demonio que se encarga de manejar los contendores y
> una serie de comandos que se comunican mediante api rests con el para
> que le digas como hacerlo. Docker compose está hecho en python, puedes
> ver su código. Y tienes librerias para comunicar con ese api:
> https://github.com/docker/docker-py
>
> Con eso puedes resolver el levantar y dar de baja instancias, descagar
> imágenes del registry, ...
>
> También hay opciones como docker registrator (si no quieres hacerlo
> tu) que atiende a los eventos de docker para ver que instancias están
> levantadas. Luego guarda la información en un etc o un consul y así
> tienes un punto con la información de qué backends hay levantados para
> tirarles las peticiones geolocalizadas esas que necesitas:
> https://github.com/gliderlabs/registrator
> https://github.com/jplana/python-etcd
> https://github.com/cablehead/python-consul
>
> Pero vamos, esto es solo una opción para hacer las llamadas. Hay otras
> aproximaciones, más a lo service bus, que en vez de centralizar quién
> puede atender peticiones, lo que centraliza son las peticiones en si a
> través de una cola de mensajes. Puedes echarle un ojo a nameko, que
> aunque creo que no cubre tus necesidades de routing geolocalizado
> puede darte una idea:
> https://github.com/nameko/nameko
> https://www.rabbitmq.com/tutorials/tutorial-four-python.html
> https://www.rabbitmq.com/tutorials/tutorial-five-python.html
>
> Otra aproximación es que cuando se levantan los backends se den de
> alta en un dns y mediante views en los servidores DNS se resuelva el
> tema de la geolocalización. Aunque hay gente que no le gusta que eso
> se haga:
> http://queue.acm.org/detail.cfm?id=1647302
>
> Por lo que cuentas una solución registrator, consul y código para ver
> a dónde atacar me suena mejor. Pero como siempre todo depende de los
> detalles.
>
> >
> > * Debo ser capaz desde un perfil de administrador, podér agregar
> instancias
> > backend, dar de baja, etc.
> >
>
> Eso como te decía yamila suena a scheduler. Puedes tirar del api de
> docker y hacerte el tuyo o tratar de usar uno de los 200 que hay (he
> dicho 200 como estimación, podrían ser más o menos). Otra opción es
> tirar por un sistema de PaaS (plataform as a service) que aparte de
> donde y como levantar las instancias suelen ayudar en su construcción,
> marchas atrás, ...
>
> Levantar instancias de código es trivial, pero ¿qué piensas hacer con los
> datos?
>
> Datos y sistemas distribuidos es un auténtico marrón:
> https://es.wikipedia.org/wiki/Teorema_CAP
>
> Si cada instancia tiene sus propios datos no distribuidos te quitas
> una gran complejidad. Bieeeen. Se te va a complicar el hacer los
> backups. Oooooo. Pero cada backend va a tener los datos más cerca lo
> que implica menos latencias. Bieeeen, Pero las tareas de
> administración (cambio de esquema, creación de índices, ...) se
> multiplican por cada particionado de datos. Oooooo.
>
> Elijas la solución final que elijas, piensa en que dejas un marrón a
> un pobre administrador de sistemas que tiene familia. Piensa en ellos
> y echale un ojo a 12Factor para que no tenga que acabar siguiendo los
> 12 pasos de aa.
> https://12factor.net/es/
>
> Esas son unas pocas buenas prácticas que te ayudarán con los sistemas
> distribuidos. Algo tan tonto como inyectar la configuración por
> variables de entorno te permite ejecutar la misma imagen de docker en
> desarrollo, preproducción y en cada uno de las instancias distribuidas
> de producción.
>
>
> > Cuando digo "tipo Hotel", es porque tomé una variante similar, en mi caso
> > sería "alquiler de bicicletas de persona a persona", el usuario puede
> > reservar bicicletas (hacer uso) de otro usuario registrado en el sitio.
> >
> > Cuento con conocimientos (no tantos) de Flask y como aplicación
> monolítica
> > me queda claro cómo hacerla, pero llevándola a microservicios, el tema
> de la
> > comunicación entre los servicios y cómo dividir la base de datos, me está
> > dando problemas de sólo pensar. Docker también es nuevo para mí.
> >
>
> Con calma, pasito a pasito. Son muchas cosas pero una por una no son
> tan difíciles:
> - Dockeriza una de tus aplicaciones monolíticas: base de datos por un
> lado, servidor smtp por otro, tu código por otro. Muchas imágenes ya
> están creadas, solo hace falta hacer un "docker run ...." ;-)
> - Haz un docker composer y levanta tu entorno de desarrollo con un solo
> comando,
> - Sonrie orgulloso
> - Juguetea con los comandos de docker-composer para crear más
> instancias de un servicio y otro.
> - Juguetea con el api python de docker
> - Hazte alguna prueba de concepto rápida: registro de backends en
> consul, que tal un rabbitmq y si tiro este contenedor como se comporta
> la plataforma. Pruebas de concepto muy simples y chabacanas para
> quedarte con la sensación. Si vas a perder más de uno o dos días te
> estás complicando la vida.
> - Respira hondo y pon en orden todo lo que has aprendido.
> - Profundiza en alguna de las pruebas de concepto. Plantea por aquí
> (como configuro el dbrouter de django para que ataque al master para
> escrituras y a varios slaves para consulta) o por otros foros (alguna
> receta para montar un cluster de mongo con replica sets en
> docker-composer) dudas específicas que te irán surgiendo.
> - Haz el proyecto
> - Profit ;-)
>
> lasizoillo, gracias por tu respuesta, todo lo que me comentas me servirá.
Mientras avanzo iré
releyendo tu respuesta. Te voy a hacer caso sobre dockerizar una aplicación
monolítica y ver qué me permite
hacer las herramientas que mencionas. por el momento la base es un archivo
de texto, pero
si hago dos servicios que se comuniquen entre si, los pondré a cada uno en
un docker.

La única manera es ir a paso a paso como decís. Cuando tenga dudas
puntuales, volveré a preguntar.

gracias y saludos.

> Existe un framework para este tipo de desarrollo o bien un ejemplo? Es
> para
> > la Universidad.
> >
> > Muchas gracias,
> >
> > --
> > Luciano Andino
> > Ing. en Sistemas de Información
> > UTN FRSF
> > BMSTU
> >
> >
> >
> > _______________________________________________
> > Python-es mailing list
> > Python-es en python.org
> > https://mail.python.org/mailman/listinfo/python-es
> >
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
>

-- 
Luciano Andino
Ing. en Sistemas de Información
UTN FRSF
BMSTU
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20170428/61efec8f/attachment.html>