microsoft - porta azure

Comprender cuándo usar servicios con estado y cuándo confiar en la persistencia externa en Azure Service Fabric

Question

Me paso las tardes evaluando Azure Service Fabric como reemplazo de nuestra pila actual de WebApps / CloudServices, y me siento un poco inseguro sobre cómo decidir cuándo los servicios / actores con estado deberían ser actores con estado y cuándo deberían ser actores sin estado con estado persistente externamente (Azure SQL, Azure Storage y DocumentDB). Sé que este es un producto bastante nuevo (al menos para el público en general), por lo que probablemente todavía no haya muchas prácticas recomendadas con respecto a esto, pero he leído la mayoría de la documentation disponible por Microsoft sin encontrar un definitivo responde por esto.

El dominio del problema actual al que me estoy acercando es nuestra tienda de eventos; partes de nuestras aplicaciones se basan en el abastecimiento de eventos y CQRS, y estoy evaluando cómo trasladar esta tienda de eventos a la plataforma Service Fabric. El almacén de eventos contendrá muchos datos de series de tiempo, y como es nuestra única fuente de verdad para que los datos persistan allí, deben ser consistentes, replicados y almacenados en alguna forma de almacenamiento duradero.

Una forma en que he considerado hacer esto es con el actor "EventStream" con estado; cada instancia de un agregado que usa el abastecimiento de eventos almacena sus eventos dentro de una secuencia aislada. Esto significa que el actor con estado podría realizar un seguimiento de todos los eventos para su propio flujo, y habría cumplido mis requisitos en cuanto a cómo se almacenan los datos (transaccional, replicado y duradero). Sin embargo, algunas transmisiones pueden crecer mucho (cientos de miles, si no millones, de eventos), y aquí es donde estoy empezando a estar inseguro. Me imagino que tener un actor con una gran cantidad de estado tendrá un impacto en el rendimiento del sistema cuando estos grandes modelos de datos deben ser serializados o deserializados del disco.

Otra opción es mantener a estos actores sin estado y hacer que solo lean sus datos de algún almacenamiento externo como Azure SQL, o simplemente ir con servicios sin estado en lugar de actores.

Básicamente, ¿cuándo es "demasiado" la cantidad de estado para un actor / servicio y debe comenzar a considerar otras formas de manejar el estado?

Además, esta sección en el patrón de diseño de Service Fabric Actors: algunos documentos antipatrones me dejan un poco perplejo:

Trate a los actores de Azure Service Fabric como un sistema transaccional. Azure Service Fabric Actors no es un sistema basado en confirmación de dos fases que ofrece ACID. Si no implementamos la persistencia opcional, y la máquina en la que se ejecuta el actor muere, su estado actual irá con ella. El actor aparecerá en otro nodo muy rápido, pero a menos que hayamos implementado la persistencia de respaldo, el estado se habrá ido. Sin embargo, entre el aprovechamiento de reintentos, el filtrado duplicado y / o el diseño idempotente, puede lograr un alto nivel de confiabilidad y consistencia.

¿Qué indica aquí "si no implementamos la persistencia opcional"? Tenía la impresión de que mientras su transacción modificara el estado tuvo éxito, sus datos se conservaron en un almacenamiento duradero y se replicaron en al menos un subconjunto de las réplicas. Este párrafo me deja preguntándome si hay situaciones en las que el estado dentro de mis actores / servicios se perderá, y si esto es algo que necesito manejar. La impresión que obtuve del modelo con estado en otras partes de la documentación parece contrarrestar esta afirmación.

Answer 1

Para responder a la pregunta secundaria de @ Trond que es: " ¿Qué significa ''si no implementamos la persistencia opcional'' aquí?"

Un actor es siempre un servicio con estado, y su estado se puede configurar, utilizando un atributo en la clase de actor, para operar en uno de los tres modos:

1. Persistió El estado se replica en todas las instancias de réplica y también se escribe en el disco. Este estado se mantiene incluso si se cierran todas las réplicas.
2. Volátil. El estado se replica en todas las instancias de réplica, solo en memoria. Esto significa que mientras una instancia de réplica esté viva, el estado se mantendrá. Pero cuando se cierran todas las réplicas, el estado se pierde y no se puede recuperar después de reiniciar.
3. Sin persistencia. El estado no se replica a otras instancias de réplica, ni al disco. Esto proporciona la menor protección del estado.

Puede encontrar una discusión completa del tema en la documentación de Microsoft

Answer 2

Sé que esto ha sido respondido, pero recientemente me encontré en la misma situación con un sistema CQRS / ES y así es como lo hice:

1. Cada agregado era un actor con solo el estado actual almacenado en él.
2. En un comando, el agregado efectuaría un cambio de estado y generaría un evento.
3. Los eventos mismos fueron almacenados en un DocDb.
4. En la activación, las instancias de AggregateActor leen eventos de DocDb si están disponibles para recrear su estado. Obviamente, esto solo se realiza una vez por activación de actor. Esto se ocupó del caso en el que una instancia de actor se migra de un nodo a otro.

Answer 3

Una opción que tiene es mantener "parte" del estado en el actor (digamos lo que podría considerarse como datos activos que deben estar disponibles rápidamente) y almacenar todo lo demás en una infraestructura de almacenamiento "tradicional" como SQL Azure , DocDB, .... Es difícil tener una regla general sobre demasiado estado local pero, tal vez, ayuda pensar en datos calientes vs. fríos. Los actores confiables también ofrecen la capacidad de personalizar StateProvider para que también pueda considerar implementar un StateProvider personalizado (implementando IActorStateProvider) con las políticas específicas que necesita para ser más eficiente con los requisitos que tiene en términos de cantidad de datos, latencia , confiabilidad, etc. (nota: la documentación aún es muy mínima en la interfaz de StateProvider, pero podemos publicar un código de muestra si esto es algo que desea buscar).

Acerca de los antipatrones: la nota trata más sobre la implementación de transacciones entre múltiples actores. Reliable Actors ofrece una garantía total sobre la confiabilidad de los datos dentro de los límites de un actor. Debido a la naturaleza distribuida y poco acoplada del modelo de actor, implementar transacciones que involucren a múltiples actores no es una tarea trivial. Si las transacciones ''distribuidas'' son un requisito importante, el modelo de programación de Servicios confiables probablemente sea más adecuado.