O mundo non se queda parado. O progreso crea novos retos tecnolóxicos. De acordo cos requisitos cambiantes, a arquitectura dos sistemas de información debe evolucionar. Hoxe falaremos sobre a arquitectura orientada a eventos, a simultaneidade, a concorrencia, a asincronía e como podes vivir en paz con todo isto en Erlang.
Introdución
Dependendo do tamaño do sistema deseñado e dos requisitos para el, nós, os desenvolvedores, escollemos o método de intercambio de información no sistema. Na maioría dos casos, para organizar a interacción dos servizos, unha opción de traballo pode ser un esquema cun corredor, por exemplo, baseado en RabbitMQ ou kafka. Pero ás veces o fluxo de eventos, o SLA e o nivel de control sobre o sistema son tales que a mensaxería preparada non é adecuada para nós. Por suposto, podes complicar un pouco o sistema asumindo a responsabilidade da capa de transporte e da formación do clúster, por exemplo usando ZeroMQ ou nanomsg. Pero se o sistema ten o rendemento e as capacidades suficientes dun clúster Erlang estándar, entón a cuestión de introducir unha entidade adicional require un estudo detallado e unha xustificación económica.
O tema das aplicacións distribuídas reactivas é bastante amplo. Para manterse dentro do formato do artigo, o tema da discusión de hoxe só serán ambientes homoxéneos construídos sobre Erlang/Elixir. O ecosistema Erlang/OTP permítelle implementar unha arquitectura reactiva co mínimo esforzo. Pero en calquera caso, necesitaremos unha capa de mensaxería.
Base teórica
O deseño comeza coa definición de obxectivos e limitacións. O obxectivo principal non está na área de desenvolvemento en aras do desenvolvemento. Necesitamos obter unha ferramenta segura e escalable sobre a base da cal poidamos crear e, o máis importante, desenvolver aplicacións modernas de varios niveis: partindo de aplicacións dun único servidor ao servizo dun público reducido, que posteriormente poden desenvolverse en clústeres de ata 50 -60 nodos, rematando con federacións de clúster. Así, o obxectivo principal é maximizar os beneficios reducindo o custo de desenvolvemento e propiedade do sistema final.
Destaquemos 4 requisitos principais para o sistema final:
- Сorientado a eventos.
O sistema está sempre preparado para pasar polo fluxo de eventos e realizar as accións necesarias; - Мescalabilidade.
Os bloques individuais pódense escalar tanto vertical como horizontalmente. Todo o sistema debe ser capaz de crecemento horizontal infinito; - Оtolerancia a fallos.
Todos os niveis e todos os servizos deberían poder recuperarse automaticamente de fallos; - Гtempo de resposta garantido.
O tempo é valioso e os usuarios non deben esperar demasiado.
Lembras o vello conto de fadas sobre "O pequeno motor que podía"? Para que o sistema deseñado saia con éxito da fase do prototipo e sexa progresivo, a súa fundación debe cumprir os requisitos mínimos. SMOG.
Engádese un punto máis á mensaxería como ferramenta de infraestrutura e base de todos os servizos: a facilidade de uso para os programadores.
Orientado a eventos
Para que unha aplicación pase dun único servidor a un clúster, a súa arquitectura debe admitir un acoplamento solto. O modelo asíncrono cumpre este requisito. Nel, o remitente e o destinatario preocúpanse pola carga de información da mensaxe e non se preocupan pola transmisión e o enrutamento dentro do sistema.
Escalabilidade
A escalabilidade e a eficiencia do sistema están xuntos. Os compoñentes da aplicación deben poder utilizar todos os recursos dispoñibles. Canto máis eficiente poidamos utilizar a capacidade e canto máis óptimos sexan os nosos métodos de procesamento, menos diñeiro gastaremos en equipos.
Dentro dunha única máquina, Erlang crea un ambiente altamente competitivo. O equilibrio entre simultaneidade e paralelismo pódese establecer escollendo o número de fíos do sistema operativo dispoñibles para a máquina virtual Erlang e o número de programadores que utilizan estes fíos.
Os procesos de Erlang non comparten estado e operan en modo sen bloqueo. Isto proporciona unha latencia relativamente baixa e un maior rendemento que as aplicacións tradicionais baseadas no bloqueo. O programador de Erlang garante unha asignación xusta de CPU e E/S, e a ausencia de bloqueo permite que a aplicación responda mesmo durante os picos de carga ou fallos.
A nivel de cluster, tamén existe o problema coa eliminación. É importante que todas as máquinas do clúster estean cargadas uniformemente e que a rede non estea sobrecargada. Imaxinemos unha situación: o tráfico de usuarios chega aos equilibradores de entrada (haproxy, nginx, etc.), distribúen as solicitudes de procesamento da forma máis uniforme posible entre o conxunto de backends dispoñibles. Dentro da infraestrutura de aplicacións, o servizo que implementa a interface requirida é só a última milla e terá que solicitar outros servizos para responder á solicitude inicial. As solicitudes internas tamén requiren enrutamento e equilibrio.
Para xestionar eficazmente os fluxos de datos, a mensaxería debe proporcionar aos desenvolvedores unha interface para xestionar o enrutamento e o equilibrio de carga. Grazas a isto, os desenvolvedores poderán, mediante patróns de microservizos (agregador, proxy, cadea, rama, etc.), resolver tanto os problemas estándar como os que raramente xorden.
Desde o punto de vista empresarial, a escalabilidade é unha das ferramentas de xestión de riscos. O principal é satisfacer as solicitudes dos clientes mediante un uso óptimo do equipo:
- Cando a potencia dos equipos aumenta como resultado do progreso. Non estará inactivo debido ao software imperfecto. Erlang escala verticalmente ben e sempre poderá utilizar todos os núcleos da CPU e a memoria dispoñible;
- En contornas de nube, podemos xestionar a cantidade de equipos dependendo da carga actual ou prevista e garantir un SLA.
tolerancia a fallos
Consideremos dous axiomas: "Os fracasos son inaceptables" e "Sempre haberá fracasos". Para unha empresa, o fallo do software significa perda de diñeiro e, o que é peor, perda de reputación. Equilibrio entre as posibles perdas e o custo de desenvolvemento de software tolerante a fallos, moitas veces pódese atopar un compromiso.
A curto prazo, unha arquitectura que incorpore tolerancia a fallos aforra diñeiro na compra de solucións de clustering dispoñibles. Son caros e tamén teñen bichos.
A longo prazo, unha arquitectura tolerante a fallos paga por si mesma moitas veces en todas as fases de desenvolvemento.
A mensaxería dentro da base de código permítelle traballar en detalle a interacción dos compoñentes dentro do sistema na fase de desenvolvemento. Isto simplifica a tarefa de responder e xestionar os fallos, xa que todos os compoñentes críticos xestionan os fallos e o sistema resultante sabe como volver á normalidade automaticamente despois dun fallo por deseño.
Capacidade de resposta
Independentemente dos fallos, a aplicación debe responder ás solicitudes e cumprir o SLA. A realidade é que a xente non quere esperar, polo que as empresas deben adaptarse en consecuencia. Espérase que cada vez máis aplicacións sexan altamente sensibles.
As aplicacións sensibles funcionan en tempo case real. Erlang VM funciona en modo suave en tempo real. Para algunhas áreas, como o comercio de accións, a medicina e o control de equipos industriais, o modo duro en tempo real é importante.
Os sistemas sensibles melloran a UX e benefician á empresa.
Resumo preliminar
Ao planificar este artigo, quería compartir a miña experiencia na creación dun corredor de mensaxería e na construción de sistemas complexos baseados nel. Pero a parte teórica e motivacional resultou ser bastante extensa.
Na segunda parte do artigo, falarei dos matices da implementación de puntos de intercambio, os patróns de mensaxería e a súa aplicación.
Na terceira parte consideraremos cuestións xerais de organización dos servizos, enrutamento e equilibrio. Falemos do lado práctico da escalabilidade e da tolerancia a fallos dos sistemas.
Fin da primeira parte.
foto .
Fonte: www.habr.com