Compartir vía

Presentación de las cargas de trabajo (versión preliminar)

  • Artículo

En este capítulo se presentan los componentes clave de nuestro sistema y se proporciona información general sobre la arquitectura. Estos componentes funcionan juntos para crear una plataforma sólida y flexible para sus necesidades de desarrollo. Vamos a profundizar en estos componentes y sus roles dentro de nuestra arquitectura.

Arquitectura de cargas de trabajo de Fabric

Algunos de los aspectos clave de la arquitectura de cargas de trabajo de Fabric son los siguientes:

  • Controla el procesamiento, el almacenamiento y la administración de datos. Valida los tokens de identificador de Microsoft Entra antes de procesarlos e interactuar con servicios externos de Azure, como Lakehouse.

  • El front-end de carga de trabajo (FE) ofrece una interfaz de usuario para la creación, autoría, gestión y ejecución de trabajos.

  • Las interacciones del usuario a través de la FE inician solicitudes al BE, ya sea directa o indirectamente a través del back-end de Fabric (BE de Fabric).

Para obtener diagramas más detallados que representan la comunicación y autenticación de los distintos componentes, consulte los diagramas Descripción general de autenticación y autorización de back-end y Descripción general de autenticación.

Front-end (FE)

El front-end actúa como base de la experiencia del usuario (UX) y el comportamiento, que funciona dentro de un iframe en el portal de Fabric. Proporciona al asociado de Fabric una experiencia de interfaz de usuario específica, incluido un editor de elementos. El SDK del cliente de extensión proporciona las interfaces, API y funciones de arranque necesarias para transformar una aplicación web normal en una microaplicación web de front-end que funciona sin problemas en el portal de Fabric.

Back-end (BE)

El back-end es el centro de energía para el procesamiento de datos y el almacenamiento de metadatos. Utiliza operaciones CRUD para crear y administrar elementos de carga de trabajo junto con los metadatos, y ejecuta trabajos para rellenar los datos en el almacenamiento. El puente de comunicación entre el front-end y el back-end se establece a través de las API públicas.

Las cargas de trabajo pueden ejecutarse en dos entornos: local y en la nube. En local (devmode), la carga de trabajo se ejecuta en el equipo del desarrollador, con llamadas a la API administradas por la utilidad DevGateway. Esta utilidad también gestiona el registro de cargas de trabajo con Fabric. En el modo de nube, la carga de trabajo se ejecuta en los servicios de asociados, con llamadas API realizadas directamente a un punto de conexión HTTPS.

Entorno de desarrollo

  • Paquete de carga de trabajo en modo para desarrolladores: al compilar la solución de back-end en Visual Studio, use la configuración de compilación de depuración para crear un paquete BE NuGet, que se puede cargar en el inquilino de Fabric mediante la aplicación DevGateway.

Diagrama de la arquitectura del modo para desarrolladores.

  • Paquete de carga de trabajo en modo nube: al compilar la solución de BE en Visual Studio, use la configuración de compilación de versión para crear un paquete de carga de trabajo independiente (BE y FE). Este paquete se puede cargar directamente en el inquilino.

Diagrama de la arquitectura del modo nube.

Estructura de paquetes NuGet de carga de trabajo

La carga de trabajo se empaqueta como un paquete NuGet, combinando componentes de back-end y front-end. La estructura se adhiere a las convenciones de nomenclatura específicas y se aplica mediante Fabric para mantener la coherencia en los escenarios de carga. El paquete NuGet diseñado para representar cargas de trabajo está estructurado para incluir componentes de back-end y front-end.

Estructura de back-end

El segmento back-end consta de archivos .xml que definen la carga de trabajo y sus elementos asociados, que son esenciales para el registro con Fabric.

Componentes claves
  • WorkloadManifest.xml: El archivo de configuración de la carga de trabajo, necesario para tener este nombre exacto para la comprobación de Fabric.
  • Item1.xml, Item2.xml, ...: manifiestos para elementos individuales con nomenclatura flexible, siguiendo el formato XML.

Estructura de front-end

La sección front-end contiene archivos .json que detallan el producto y los elementos del front-end, junto con un directorio “assets” para los iconos.

Componentes claves
  • Product.json: El manifiesto principal del front-end del producto, que debe denominarse precisamente para la comprobación de Fabric.
  • Item1.json, Item2.json, ...: manifiestos para elementos individuales con nomenclatura flexible, siguiendo el formato JSON. Cada JSON corresponde a un manifiesto de back-end (p. ej., Item1.json a Item1.xml).
  • Archivo assets: almacena todos los iconos icon1.jpg, icon2.png, ... que usa el front-end.

Cumplimiento obligatorio de la estructura

La estructura, incluidos los nombres de subcarpeta específicos (“BE”, “FE”, “assets”), es obligatorio y se aplica mediante Fabric para todos los escenarios de carga, incluidos los paquetes de prueba y desarrollo. La estructura se especifica en los archivos .nuspec que se encuentran en el repositorio en el directorio Backend/src/Packages/manifest.

Límites

Los límites siguientes se aplican a todos los tipos de paquetes NuGet, tanto en modo de desarrollo como en modo de nube:

  • Solo se permiten las subcarpetas BE y FE. Cualquier otra subcarpeta o archivo ubicado fuera de estas carpetas produce un error de carga.
  • La carpeta BE solo acepta archivos .xml. Cualquier otro tipo de archivo produce un error de carga.
  • Se permite un máximo de 10 archivos de elementos, lo que significa que la carpeta BE puede contener un archivo WorkloadManifest.xml y hasta 10 archivos Item.xml. Si hay más de 10 archivos de elementos en la carpeta, se produce un error de carga.
  • La subcarpeta Assets debe estar dentro de la carpeta FE. Puede contener hasta 15 archivos, cada uno de ellos de un máximo de 1,5 MB.
  • Solo se permiten los siguientes tipos de archivo en la subcarpeta Assets: .jpeg, .jpg, .png.
  • La carpeta FE puede contener un máximo de 10 archivos de elementos más un archivo product.json.
  • Los archivos de elementos deben hacer referencia a todos los recursos de la carpeta Assets. Cualquier recurso al que se haga referencia desde un archivo de elemento que falte en la carpeta Assets producirá un error de carga.
  • Los nombres de archivo de los elementos deben ser únicos. Los nombres de archivo duplicados producen un error de carga.
  • Los nombres de archivo deben contener caracteres alfanuméricos (inglés) o guiones únicamente y no pueden superar una longitud de 32 caracteres. Si se usan otros caracteres o se supera esta longitud, se produce un error de carga.
  • El tamaño total del paquete no debe superar los 20 MB.
  • Consulte el manifiesto de carga de trabajo para conocer las limitaciones específicas del manifiesto.

Modo para desarrolladores local (devmode)

El back-end de carga de trabajo (BE) funciona en el equipo del desarrollador. Las llamadas a la API de carga de trabajo se transmiten a través de Azure Relay, y el lado de la carga de trabajo del canal de Azure Relay se administra mediante una utilidad de línea de comandos especializada, DevGateway. as llamadas a la API de control de carga de trabajo se envían directamente desde la carga de trabajo a Fabric, sin pasar por el canal Azure Relay. La utilidad DevGateway también supervisa el registro de la instancia de desarrollo local de la carga de trabajo con Fabric, en el contexto de una capacidad específica. Esto garantiza la disponibilidad de la carga de trabajo en todas las áreas de trabajo asignadas a esa capacidad. Tras la finalización de la utilidad DevGateway, el registro de la instancia de carga de trabajo se rescinde automáticamente. Para obtener más información, consulte la Guía de implementación del back-end.

Esquema de BE del modo para desarrolladores

Diagrama de la arquitectura del esquema de BE del modo para desarrolladores.

Modo para desarrolladores en la nube (modo de nube)

El back-end de carga de trabajo (BE) funciona dentro de los servicios del asociado. Las llamadas a la API de carga de trabajo se realizan directamente al punto de conexión HTTPS, como se especifica en el manifiesto de carga de trabajo. En este escenario, la utilidad DevGateway no es necesaria. El registro de la carga de trabajo en Fabric se realiza cargando el paquete NuGet de la carga de trabajo en Fabric y activando posteriormente la carga de trabajo para el inquilino. Para obtener más información, consulte Administración de una carga de trabajo en Fabric.

Esquema BE en modo de nube

Diagrama de la arquitectura de esquema BE en modo de nube.

Contenido relacionado