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

Question

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

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

Pero, he estado experimentando con Elixir también, y soy bastante aficionado a 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 caliente, ¿cómo mezclaría docker con elixir (o erlang, para el caso)?

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

Quiero decir, podría escribir microservicios con Elixir y usarlos como si estuvieran escritos en cualquier otro lenguaje, el poliglotismo es uno de los beneficios de los microservicios de todos modos, pero entonces no estoy obteniendo todos los beneficios de usar la plataforma OTP, supongo que las aplicaciones erlang colaborativas puras son mucho más óptimas que el uso de colas intermedias para comunicarse entre microservicios escritos en diferentes (o no) lenguajes.

91

architecture docker erlang microservices elixir

Author: hjpotter92, 2015-05-24

Source

1 answers

score 121 · Accepted Answer

Esta es una pregunta muy abierta, pero intentaré 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. El Erlang VM y su biblioteca estándar fueron diseñados por adelantado para la construcción de sistemas distribuidos y esto realmente se muestra. Por lo que sé, es el único tiempo de ejecución y VM que se usa ampliamente en producción diseñado por adelantado para este uso caso.

Aplicaciones

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

se inician y se detienen como unidad. Iniciar y detener su sistema es una cuestión de iniciar todas las aplicaciones en él
proporcionar una estructura de directorios unificada y 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 uno
contiene el árbol de supervisión de la aplicación, con todos los procesos (por proceso me refiero a "procesos de VM" que son subprocesos ligeros de cálculo) y su estado

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

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

No solo eso, las herramientas alrededor de 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 matar 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:

Observador que se ejecuta con una aplicación Phoenix

La diferencia aquí es que las aplicaciones y los procesos le dan una abstracción para razonar sobre su código en producción. Muchos lenguajes proporcionan paquetes, objetos y módulos principalmente para la organización de código sin reflexión en 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 tienes una pérdida de memoria o un cuello de botella, ¿cómo puedes encontrar la entidad responsable de ello?

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

Comunicación

Todo esto es solo el comienzo realmente. Al crear 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 tienes un protocolo de comunicación y un mecanismo de serialización de la caja. 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ó de esto en Erlang Factory 2015 y cómo fueron capaces de aprovechar esto para construir una plataforma de juego: https://www.youtube.com/watch?v=_i6n-eWiVn4

Si desea utilizar HTTP y JSON, eso también está bien y 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 alrededor de 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 usted 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, aún mejor, si desea evitar agregar la complejidad de las implementaciones de microservicios a su sistema por adelantado, puede implementarlas por completo en el mismo nodo.

Y, al final del día, si está ejecutando todo esto utilizando el Protocolo Distribuido Erlang, puede ejecutarlos en diferentes nodos y lo harán ser capaz de llegar a otros siempre y cuando se refiera a ellos por {:node@network, :name} en lugar de :name.

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