Procedimientos recomendados para el diseño de aplicaciones de Azure Service Fabric

  • Artículo

En este artículo se proporciona una guía de procedimientos recomendados para compilar aplicaciones y servicios en Azure Service Fabric.

Familiarizarse con Service Fabric

Guía de diseño de aplicaciones

Familiarícese con la arquitectura general de las aplicaciones de Service Fabric y sus consideraciones de diseño.

Elegir una puerta de enlace de API

Use un servicio de puerta de enlace de API que se comunique con servicios de back-end y que, a continuación, se pueda escalar horizontalmente. Los servicios de puerta de enlace de API más comúnmente utilizados son:

Servicios sin estado

Se recomienda que siempre comience compilando servicios sin estado mediante el estado de almacenamiento Reliable Services en una instancia de Azure Database, Azure CosmosDB o Azure Storage. El estado externalizado es el enfoque más familiar para la mayoría de los desarrolladores. Este enfoque también permite aprovechar las capacidades de consulta en el almacén.

Cuándo usar servicios con estado

Considere la posibilidad de elegir servicios con estado cuando tenga un escenario de baja latencia y necesite mantener los datos cerca del proceso. Algunos escenarios de ejemplo incluyen dispositivos gemelos digitales de IoT, estado de juego, estado de sesión, almacenamiento en caché de datos de una base de datos y flujos de trabajo de larga duración para realizar el seguimiento de las llamadas a otros servicios.

Decida el período de tiempo de retención de los datos:

  • Datos en caché. Usa el almacenamiento en caché cuando la latencia a los almacenes externos es un problema. Use un servicio con estado como caché de datos propia o considere la posibilidad de usar caché distribuida de SoCreate Service Fabric de código abierto. En este escenario, no necesita preocuparse por si pierde todos los datos de la memoria caché.
  • Datos enlazados en tiempo. En este escenario, necesita mantener los datos cerca de proceso debido a la latencia durante un período de tiempo, pero puede permitirse perder dichos datos en un escenario de desastre. Por ejemplo, en muchas soluciones de IoT, los datos deben estar cerca del proceso, por ejemplo, al calcular la temperatura media durante los últimos días; sin embargo, si estos datos se pierden, los puntos de datos concretos registrados no son tan importantes. Además, en este escenario normalmente no le interesa realizar una copia de seguridad de los puntos de datos individuales. Solo realiza copias de seguridad del promedio de los valores calculados que periódicamente se escriben en un almacenamiento externo.
  • Datos a largo plazo. Las colecciones de confianza pueden almacenar sus datos permanentemente. Sin embargo, en este caso deberá prepararse para la recuperación ante desastres, incluida la configuración de directivas de copia de seguridad periódicas para sus clusters. En efecto, configura qué pasará si su clúster se destruye en un escenario de desastre, en el que necesitaría crear un nuevo clúster, y cómo implementar nuevas instancias de aplicación y recuperar los datos de la copia de seguridad más reciente.

Ahorrar costos y mejorar la disponibilidad:

  • Puede reducir los costos con servicios con estado, ya que no se incurre en costos de acceso y transacciones de datos desde el almacén remoto, y porque no es necesario usar ningún otro servicio como Azure Cache for Redis.
  • Usar servicios con estado principalmente para el almacenamiento y no para el proceso es costoso y no se recomienda. Considere la posibilidad de utilizar los servicios con estado como proceso con un almacenamiento local económico.
  • Al quitar las dependencias en otros servicios, puede mejorar la disponibilidad del servicio. Tener un estado administrado con alta disponibilidad en el clúster le protege de los tiempos de inactividad o problemas de latencia de otros servicios.

Cómo trabajar con Reliable Services

Service Fabric Reliable Services le permite crear fácilmente servicios con estado y sin estado. Para más información, consulte Introducción a Reliable Services.

  • Respete siempre el token de cancelación en el método RunAsync() para los servicios con estado y sin estado y el método ChangeRole() para los servicios con estado. En caso contrario, Service Fabric no sabe si se puede cerrar el servicio. Por ejemplo, no respetar el token de cancelación puede dar lugar a tiempos de actualización de aplicaciones mucho más prolongados.
  • Abra y cierre los clientes de escucha de comunicación de manera oportuna y respete los tokens de cancelación.
  • Nunca mezcle código sincrónico con código asincrónico. Por ejemplo, no use .GetAwaiter().GetResult() en las llamadas asincrónicas. Use la asincronía totalmente en toda la pila de llamadas.

Cómo trabajar con Reliable Actors

Service Fabric Reliable Actors le permite crear fácilmente actores con estado virtuales. Para más información, consulte Introducción a Reliable Actors.

  • Considere seriamente la posibilidad de utilizar la mensajería publicada y enviada entre los actores para escalar la aplicación. Entre las herramientas que ofrecen este servicio se incluyen SoCreate Service Fabric Pub/Sub de código abierto y Azure Service Bus.
  • Haga que el estado de los actores sea lo más pormenorizado posible.
  • Administre el ciclo de vida del actor. Elimine actores si no piensa usarlos nunca más. La eliminación de actores innecesarios es especialmente importante cuando se usa el proveedor de estado volátil, ya que todos los estados se almacenan en memoria.
  • Debido a su simultaneidad basada en turnos, los actores son más útiles como objetos independientes. No cree gráficos de llamadas al método multiactor sincrónico (cada una de las cuales probablemente se convierte en una llamada de red independiente) ni solicitudes de actor circular. Esto afectará significativamente al rendimiento y la escala.
  • No mezcle código sincrónico con código asincrónico. Usar la asincronía de una manera coherente para evitar problemas de rendimiento.
  • No realice llamadas de larga duración en actores. Las llamadas de larga duración en actores bloquearán otras llamadas para el mismo actor debido a la simultaneidad basada en turnos.
  • Si se está comunicando con otros servicios mediante la comunicación remota de Service Fabric y está creando un ServiceProxyFactory, cree la fábrica al nivel del servicio de actores y no al nivel del actor.

Diagnósticos de aplicaciones

Sea exhaustivo sobre la adición del registro de aplicaciones en las llamadas al servicio. Le ayudará a diagnosticar escenarios de servicios que se llaman entre sí. Por ejemplo, cuando A llama a B que llama a C que llama a D, podría generarse un error en la llamada en cualquier lugar. Si no tiene suficiente registro, los errores son difíciles de diagnosticar. Si los servicios están realizando demasiados registros debido al volumen de llamadas, al menos asegúrese de registrar los errores y las advertencias.

Guía de diseño sobre Azure