Cómo IPF Maneja la Realidad

IPF utiliza Akka y como su documentación oficial estados, al emular Erlang,Akka hace explícita la falibilidad de la comunicación a través del paso de mensajes, por lo tanto, no intenta mentir y emular una abstracción con fugas, y el SDK de IPF ha adoptado esta filosofía con seriedad.

Al comunicarse con flujos construidos por IPF DSL Los desarrolladores de IPF deben considerar siempre las fallas de red. El código generado por IPF DSL proporciona reintentos configurables y controles de idempotencia por defecto, proporcionando a los desarrolladores los mecanismos para construir semánticas de entrega exactamente una vez cuando se trata de entradas de flujo.

Además, IPF DSL permite transiciones de flujo en timeouts, promoviendo así la gestión de tiempo de espera como un ciudadano de primera clase — más a menudo de lo que se podría pensar, qué hacer en caso de timeouts causado por la falta de respuesta de un sistema externo es un negocio decision y no uno técnico. Al configurar tiempos de espera los desarrolladores pueden crear diversas políticas de tiempo de espera y, por lo tanto, garantizar que se cumplan las demandas comerciales cuando se enfrentan a problemas de red.

Dado que en una aplicación típica de orquestación de IPF los flujos se integran estrechamente con Marco de Conectores IPF, aprovechando reintentos y timeouts en ambos enviar y receive connector s puede ayudarle a lidiar con interrupciones temporales de la red, mientras que para interrupciones más prolongadas, una estrategia de reintento basada en mensajes enviados a un apéndice de carta muerta puede ser más aplicable.

Akka Cluster también viene empaquetado con soporte integrado para particiones de red (y fallos de máquina, que se tratan de la misma manera que los inalcanzables a través de la red):

Finalmente, debe aplicar las mismas prácticas de desarrollo a sus flujos que utilizaría con sus funciones: prefiera flujos de orquestación más cortos que realicen una sola tarea de manera efectiva. Flujos complejos — flujos que consisten en muchos estados y generan mucha domain events a lo largo de su vida — a menudo tardan más en recuperarse cuando Akka los distribuye a nuevos nodos. Una buena regla general sería apuntar a flujos con no más de 20 estados — por ejemplo, si realiza una verificación de sanciones en su payment flow consiste en 8 estados, considere extraer esa lógica en un flujo propio, especialmente si es algo que puede ser reutilizado por otros flujos.

El marco de conectores IPF se basa en Akka Streams que — similar a otros Flujos Reactivos implementaciones — proporcione mecanismos de contrapresión para manejar latencias variables y asegurar un flujo de datos fluido. Akka Streams permite la definición de pipelines de procesamiento de datos que pueden adaptarse a la velocidad del componente más lento. Esto previene la sobrecarga de cualquier parte del sistema y asegura que los datos se procesen de manera eficiente, incluso en presencia de latencia de red.

Además, ambos Akka y el SDK de IPF se ha construido en torno a operaciones no bloqueantes, asegurando que no se desperdicien recursos del sistema esperando a que se completen las operaciones de E/S, sino que se utilicen para procesar el trabajo pendiente.

Viendo que rara vez es el caso que las operaciones comerciales deseen esperar indefinidamente a que una operación se complete, al considerar la latencia en sus soluciones, debe aplicar el mismo pensamiento de reintento y tiempo de espera ya expuesto en La red es confiable..

Finalmente, a menudo la mejor manera de lidiar con la latencia de la red es no utilizar la red en absoluto --caching El uso frecuente de datos localmente en lugar de realizar llamadas remotas repetidas suele ser una excelente manera de reducir el impacto de la latencia en su aplicación. IPF proporciona su propio en memoria caching biblioteca pero no le impide utilizar ningún otro caching tecnología que usted puede preferir. Tenga cuidado con el viejo dicho, sin embargo:

Muy similar a La latencia es cero, el existente mecanismos de contrapresión permitirá que las soluciones del SDK de IPF se desaceleren cuando la latencia aumente debido a que el ancho de banda empuja la red al límite. Pero el SDK de IPF también ofrece enfoques proactivos para controlar el ancho de banda antes de que comience a causar problemas:

Suponer que la red es segura a menudo conduce a descuidar la encriptación de los datos en tránsito, ya que sin encriptación, la información sensible puede ser interceptada por actores maliciosos. Mientras que una aplicación típica construida con IPF SDK generalmente no estará ejecutándose dentro de un DMZ, todavía hay personas preocupadas por la seguridad decisions que usted podría estar realizando para reducir los riesgos de seguridad.

Además de soportar la encriptación a nivel de transporte en Akka, IPF SDK también le permite añadir cifrado a nivel de transporte a otros componentes:

Finalmente, si los consumidores objetivo lo apoyan, IPF Connectors permite enviar y consumir cargas útiles cifradas a través de etapas de cifrado. Uso de cargas útiles cifradas con JMS y Kafka también asegura que los datos estén cifrados en rest.

Como se mencionó anteriormente, IPF SDK se basa en Akka Cluster y sus complementos para bootstrap el clúster de servicios y luego adaptarse dinámicamente a los cambios en la red y la topología de la máquina, asegurando disponibilidad continua y escalabilidad. Akka Cluster y su descubrimiento mecanismos (incluyendo los de propiedad de IPF Descubrimiento basado en MongoDB) puede detectar automáticamente cuando los nodos se unen o abandonan el clúster y redistribuir datos y tareas en consecuencia. Esto asegura que el sistema permanezca operativo incluso a medida que la topología de la red cambia.

Mientras que los componentes mencionados cubren cambios de topología elegantes, al tratar con cambios no elegantes — es decir, fallos y caídas — la pérdida de mensajes, la falta de respuesta o el aumento de la latencia son síntomas comunes, por lo que se manejan de manera similar a lo descrito en La red es confiable. y La latencia es cero.

Además, dado que el SDK de IPF tiene como objetivo apoyar la escritura de aplicaciones nativas de la nube por diseño, ofrece algunas herramientas para ayudarle al desplegar en la nube:

A diferencia de las falacias anteriores, el SDK de IPF desempeña únicamente un papel de apoyo para ayudarle a superar los problemas presentados por esta, siendo las herramientas y prácticas de observabilidad y monitoreo las que desempeñan el papel principal. Como se mencionó en La topología no cambia y La latencia es cero, IPF viene con un amplio soporte de observabilidad, así como con características amigables para la automatización y nativas de la nube. HTTP puntos finales. Estos no solo le permiten hacer un seguimiento de sus SLA y KPI, sino que también pueden ser utilizados por herramientas de alerta y monitoreo para ayudarle a añadir una automatización robusta en CI/CD tuberías. Cuando su CI/CD incluye todas sus aplicaciones y también abarca infraestructura, se vuelve posible realizar retrocesos automáticos de cambios disruptivos. Incluso sin automatización, el IPF y Akka la telemetría debe permitirle crear reglas de alerta y operational dashboard s que pueden ayudar a identificar problemas.

Su enfoque aquí debe ser en reducir el número de llamadas a la red, el tamaño de las cargas útiles enviadas a través del cable y también en mejorar la localidad de los datos. Si todo eso le suena familiar, ¡ha estado prestando atención! El enfoque adoptado aquí es cómo El ancho de banda es infinito. se maneja.

La única diferencia entre los enfoques es lo que usted rastrea en sus herramientas de monitoreo e informes; usted querrá identificar las métricas que se correlacionan con sus costos y utilizarlas primero para guiar sus optimizaciones y luego para mantener un control cuidadoso sobre el presupuesto. Para implementaciones en la nube, puede que desee centrarse en una infraestructura de red dedicada como las puertas de enlace NAT y la comunicación entre centros de datos, ya que estas suelen generar costos significativos de transferencia de datos.

Esta falacia fue una adición tardía a la lista por James Gosling y, de alguna manera, une todas las falacias anteriores. La realidad es que las redes pueden incluir una mezcla de diferentes hardware, software, protocolos, configuraciones y costos asociados, y todos estos pueden cambiar en cualquier momento durante la vida útil de su aplicación.

Por lo tanto, las aplicaciones que usted construya deben ser capaces de manejar particiones de red or destinos volviéndose inalcanzables, cambiando latencias y congestiones repentinas, o los requisitos de seguridad se están volviendo más estrictos de la noche a la mañana.