architecture - ppt - plataforma microservicios

¿Dónde encaja Elixir/erlang en el enfoque de microservicios?

Question

Últimamente he estado haciendo algunos experimentos con docker compose para implementar múltiples microservicios de colaboración. Puedo ver los muchos beneficios que ofrecen los microservicios, y ahora que hay un buen conjunto de herramientas para administrarlos, creo que no es extremadamente difícil saltar al vagón de microservicios.

Pero también he estado experimentando con Elixir y me gustan mucho los beneficios que proporciona por sí mismo. Dado que alienta a empaquetar su código en múltiples aplicaciones desacopladas y admite actualizaciones de código activo, ¿cómo combinaría docker con elixir (o erlang, para el caso)?

Por ejemplo, si quiero usar docker porque proporciona paridad dev-prod, ¿cómo encaja el elixir en eso? Dado que los contenedores Docker son inmutables, pierdo la capacidad de realizar actualizaciones de código activo, ¿verdad? ¿Qué pasa con las implementaciones azules / verdes o las versiones canarias?

Quiero decir, podría simplemente escribir microservicios con Elixir y usarlos como si estuvieran escritos en cualquier otro idioma, el poliglotismo es uno de los beneficios de los microservicios de todos modos, pero no obtengo todos los beneficios de usar la plataforma OTP. Supongo que las aplicaciones erlang de colaboración pura son mucho más óptimas que el uso de colas intermedias para comunicarse entre microservicios escritos en diferentes (o no) idiomas.

Answer 1

Esta es una pregunta muy abierta, pero trataré de ilustrar por qué Elixir / Erlang puede ser la mejor plataforma para desarrollar sistemas distribuidos (independientemente de si está trabajando con microservicios).

Primero, comencemos con algunos antecedentes. Erlang VM y su biblioteca estándar se diseñaron por adelantado para construir sistemas distribuidos y esto realmente se muestra. Hasta donde sé, es el único tiempo de ejecución y VM utilizado ampliamente en la producción diseñada por adelantado para este caso de uso.

Aplicaciones

Por ejemplo, ya ha insinuado "aplicaciones". En Erlang / Elixir, el código se empaqueta dentro de las aplicaciones que:

1. se inician y se detienen como unidad. Iniciar y detener su sistema es cuestión de iniciar todas las aplicaciones en él.
2. proporciona una estructura de directorio unificada y una API de configuración (¡que no es XML!). Si ya ha trabajado y configurado una aplicación OTP, sabe cómo trabajar con cualquier otra
3. contiene el árbol de supervisión de la aplicación, con todos los procesos (por proceso me refiero a "procesos VM" que son subprocesos ligeros de cómputo) y su estado

El impacto de este diseño es enorme. Significa que los desarrolladores de Elixir, al escribir aplicaciones, tienen un enfoque más explícito para:

1. cómo se inicia y detiene su código
2. ¿Cuáles son los procesos que forman parte de una aplicación y, por lo tanto, cuál es el estado de la aplicación?
3. cómo reaccionarán y se verán afectados esos procesos en caso de accidentes o cuando algo salga mal

No solo eso, las herramientas en torno a esta abstracción son geniales. Si tiene instalado Elixir, abra "iex" y escriba :observer.start() . Además de mostrar información y gráficos sobre su sistema en vivo, puede eliminar procesos aleatorios, ver su uso de memoria, estado y más. Aquí hay un ejemplo de cómo ejecutar esto en una aplicación de Phoenix:

La diferencia aquí es que las aplicaciones y los procesos le brindan una abstracción para razonar sobre su código en producción . Muchos idiomas proporcionan paquetes, objetos y módulos principalmente para la organización del código sin reflexionar sobre el sistema de tiempo de ejecución. Si tiene un atributo de clase o un objeto singleton: ¿cómo puede razonar sobre las entidades que pueden manipularlo? Si tiene una pérdida de memoria o un cuello de botella, ¿cómo puede encontrar la entidad responsable de ello?

Si le preguntas a alguien que ejecuta un sistema distribuido, ese es el tipo de información que quiere, y con Erlang / Elixir lo tienes como el bloque de construcción.

Comunicación

Todo esto es solo el comienzo realmente. Al construir un sistema distribuido, debe elegir un protocolo de comunicación y el serializador de datos. Mucha gente elige HTTP y JSON que, cuando lo piensas, es una combinación muy detallada y costosa para realizar lo que realmente son llamadas RPC.

Con Erlang / Elixir, ya tiene un protocolo de comunicación y un mecanismo de serialización listo para usar. Si desea que dos máquinas se comuniquen entre sí, solo necesita darles nombres, asegurarse de que tengan el mismo secreto y listo.

Jamie habló sobre esto en Erlang Factory 2015 y cómo pudieron aprovechar esto para construir una plataforma de juego: https://www.youtube.com/watch?v=_i6n-eWiVn4

Si desea utilizar HTTP y JSON, también está bien y las bibliotecas como Plug y frameworks como Phoenix le garantizarán que también sea productivo aquí.

Microservicios

Hasta ahora no he hablado de microservicios. Eso es porque, hasta este punto, realmente no importan. Ya está diseñando su sistema y nodos en torno a procesos muy pequeños que están aislados. ¡Llámalos nanoservicios si quieres!

No solo eso, también se empaquetan en aplicaciones, que los agrupan como entidades que se pueden iniciar y detener como unidad. Si tiene aplicaciones A, B y C, y luego desea implementarlas como [A, B] + [C] o [A] + [B] + [C], tendrá muy pocos problemas para hacerlo debido a su diseño inherente. O, mejor aún, si desea evitar agregar la complejidad de las implementaciones de microservicios en su sistema por adelantado, simplemente puede implementarlas por completo en el mismo nodo.

Y, al final del día, si está ejecutando todo esto utilizando el Protocolo distribuido de Erlang, puede ejecutarlos en diferentes nodos y podrán comunicarse con otros siempre que se refiera a ellos por {:node@network, :name} lugar de :name .

Podría ir más lejos, pero espero haberte convencido en este momento. :)