Durante la última semana, me he aventurado en el desarrollo de software investigando el concepto de actores virtuales. Al final me fijé en dos marcos diferentes: Dapr y Orleans.
Ambos son proyectos muy concisos con un montón de casos de uso interesantes. Ambos utilizan la idea de actores "virtuales". Un actor virtual es una unidad de estado y lógica que:
- Puede identificarse de forma única por el ID
- Es de un solo hilo
- Puede ser en memoria o persistente: su ciclo de vida está gestionado por el framework
Me gusta mucho la idea de los actores virtuales y los encuentro muy útiles para explorar la creación de herramientas escalables y fiables para manejar flujos de trabajo complejos de tareas. Si cada tarea es un participante virtual de un solo hilo, el problema de la condición de raza desaparece.
Como Orleans y Dapr son ambos proyectos de Microsoft, me imagino un día al estilo Western Story en la cafetería de Microsoft.
Orleans
Empecé con Orleans porque llevo tiempo en mi radar después de ver algunos vídeos sobre ella en YouTube. Empezó muy mal porque pensaba que iba a usar la versión 4.x de todos sus paquetes NuGet. Sin embargo, absolutamente ninguna de sus documentaciones funciona con el paquete 4.x. Al final usé la versión 3.6.2.
Granos / Estado / Temporizadores
Crear un grano que rastree su propio estado y realice acciones es muy sencillo. Incluso pude seguir la documentación sobre persistencia de grano y crear mi propia implementación de CosmosDB (API SQL) de IGrainStorage.
Recordatorios
Los recordatorios también son fáciles de configurar. Hasta que intenté configurar la persistencia real para ellos. En este punto de mi investigación, intento mantener todo ordenado y guardar todo en ComsosDB. Desafortunadamente, no consigo que el paquete de recordatorio de persistencia de Orleans funcione en absoluto. Al final tuve que cambiarme al paquete AzureStorage. Así que ahora mis datos están mitad en la cuenta de la API SQL y la mitad en la cuenta de API de tabla.
Arroyos
Ahí fue donde no me fue bien. En Orleans, los flujos se identifican mediante un GUID y un espacio de nombres opcional. Seguro que hay una buena razón por la que los arroyos tienen que identificarse con un GUID, pero vaya, eso es poco práctico.
Estoy muy frustrado con los streams porque podía crearlos fácilmente, pero en cuanto paro y reinicio mi proyecto y activo un nuevo evento, todo se bloquea.
A esto le sigue una información muy valiosa, ya que me llevó 8 horas descifrar el código de Orleans para averiguarlo:
Cuando un grano es suscriptor de stream, debe llamar a ResumeAsync en el handle de suscripción de su método OnActivateAsync, o se bloqueará con un error no reconocido.
También tuve el problema de que la misma suscripción estaba duplicada, así que usé el código para borrar todas las suscripciones del grano y luego lo recreé:
Otros consejos y puntos de Orleans
Streams funciona bien con Azure Event Hubs (a través de AddEventHubStreams).
¡No uses / ni otros caracteres especiales en el nombre Grain de la API SQL de CosmosDB!
Conclusión de Orleans
Me gusta Orleans y creo que tiene potencial. Sin embargo, tiene una curva de aprendizaje muy pronunciada. Debido a mi larga lucha con el streaming, no tengo tiempo para estudiar cómo funcionan los clústeres o los despliegues.
Dapr
Encontré Dapr buscando alternativas a Orleans. Es un poco extraño que también sea un proyecto patrocinado por Microsoft. Quizá estén aquí para adoptar un enfoque de supervivencia del más apto. Si es así, creo que Dapr será un superviviente.
En primer lugar, el diseño basado en REST/gRPC de Dapr permite implementar actores usando cualquier lenguaje de programación. También me resultó trivial ejecutar todo (participantes, estados, temporizadores, recordatorios, eventos) en una sola instancia de Redus. Además, solo me llevó aproximadamente un tercio del tiempo empezar a usar Dapr. Un tiempo de arranque tan rápido se debe a la excelente documentación de Dapr.
Actores / Cronometradores / Recordatorios
¿Acabo de decir que la documentación de Dapr es excelente? Bueno, está en todas partes, excepto en ejemplos de JavaScript. Paso la mayor parte del tiempo en Dapr, intentando averiguar cómo llamar los métodos a los actores. El código para el ejemplo de Dapr Javascript es el siguiente:
Esto está claramente desactualizado. Tuve que pasar mucho tiempo guiando estas tres líneas a través de la exploración de código de prueba/ejemplo de Dapr
Los ejemplos de código para obtener/configurar estados tienen problemas similares, así que creé un problema en GitHub para ellos.
Salvo por esos pequeños problemas, preparar a los actores es pan comido.
Poner temporizadores y recordatorios para mi lanzamiento también es muy sencillo.
Estado
Pude configurar Dapr para que persistiera con Postgres muy fácilmente.
Una cosa que he notado es que puede haber problemas de escalabilidad en cómo se almacenan los recordatorios. Dapr almacena todas las alertas de un tipo específico de participante en un solo array JSON. ¿Qué pasa si alguien tiene un montón de recordatorios?
Otros trucos / consejos de Dapr
Una cosa que noté al navegar por el código del SDK de JavaScript es que no hay muchos comentarios en la base de código. Esto hace que sea casi imposible averiguar algo. Por ejemplo, en el método addOrUpdateState del gestor de estados, hay un tercer parámetro llamado updateValueFactory. Si no hay comentarios en el código, es casi imposible saber para qué es la llamada de regreso.
Tampoco estoy seguro de cuánto me gusta el comando "dapr init" que intenta configurar y ejecutar un contenedor Redis para mí. ¿Y si ya tengo un contenedor de Redis? ¿Y si prefiero usar postgres en su lugar? No encuentro documentación que explique cómo cambiar la función de inicio DAPR.
Una nota para quien tenga problemas usando pubsub. Debes usar "dapr run" para gestionar tanto a tu editor como a tu suscriptor:
Para actores y pubsub, ten en cuenta que es importante usar el parámetro --app-port para que DAPR sepa en qué puerto se está ejecutando tu servicio. Los eventos de pubsub y las llamadas de actores se envían a tu servicio desde el sidecar de Dapr a través de llamadas http, así que necesita saber dónde enviarlas:
Probé un pequeño "clúster" autoalojado de Dapr lanzando mi instancia de suscriptor de pubsub en dos máquinas diferentes de mi red doméstica. ¡Simplemente funcionó!
Conclusión Dapr
Si quieres saber más ideas sobre aplicaciones distribuidas o actores virtuales, te recomiendo que empieces por Dapr. Orleans fue el pionero original, mientras que Dapr fue un reinicio que llevó las cosas al siguiente nivel.
Enlace original:El inicio de sesión del hipervínculo es visible.
|
Publicado en 29/12/2022 14:24:52
|
|
|
|
Propietario|
Publicado en 29/12/2022 14:25:28
|
