amazon-web-services - prices - aws login account
Creación de aplicaciones de Erlang para la nube (2)
Estoy trabajando en un servidor de socket que se implementará en AWS y hasta ahora tenemos la aplicación OTP básica configurada siguiendo una estructura similar al proyecto de ejemplo en Erlang en la práctica , pero queríamos evitar tener un enrutador de mensajes global porque eso no va a escalar bien
Después de revisar la guía de diseño de OTP sobre aplicaciones distribuidas y los capítulos correspondientes ( Distribunomicon y OTP distribuido ) en Learn You Some Erlang , parece que el mecanismo de aplicación distribuida integrado está orientado a las soluciones locales, donde ha conocido nombres de host e IP y el la configuración del clúster se determina de antemano, mientras que en nuestra configuración prevista, la aplicación deberá escalar dinámicamente hacia arriba y hacia abajo, y las direcciones IP de los nodos serán aleatorias.
Lo siento, es un poco complejo, mi pregunta es si existen pautas de diseño para las aplicaciones distribuidas de Erlang que se implementan en la nube y necesitan ocuparse de todas las escalas dinámicas.
Gracias,
Acabo de aprender Erlang, por lo que no puedo ofrecer ningún consejo práctico, pero parece que tu situación podría requerir un tipo de enfoque de "descubrimiento de recursos", tal como he leído en Erlang y OTP en acción.
Erlware también tiene una aplicación para ayudar con esto: https://github.com/erlware/resource_discovery
Hay algunos posibles enfoques:
- En Erlang y OTP en acción, un método presentado es usar uno o dos nodos centrales con dominios o IP conocidos, y tener todos los otros nodos conectados a este para descubrirse entre sí.
- Las aplicaciones como https://github.com/heroku/redgrid/tree/logplex requieren tener un nodo redis central donde todos los nodos de Erlang se registran a sí mismos y realizan la administración de miembros.
- Servicios de terceros como Zookeeper y qué no hacer algo similar
- Cualquier otra cosa que la gente pueda recomendar
Tenga en cuenta que a menos que necesite proteger su comunicación, ya sea al cambiar el protocolo de distribución para usar SSL o al usar grupos de seguridad de AWS, y no para restringir quién puede acceder a su red.