Introdução às cargas de trabalho
Este capítulo apresenta os principais componentes do nosso sistema e fornece uma visão geral da arquitetura. Esses componentes trabalham juntos para criar uma plataforma robusta e flexível para suas necessidades de desenvolvimento. Vamos nos aprofundar nesses componentes e suas funções dentro da nossa arquitetura.
Arquitetura de carga de trabalho de malha
Alguns dos principais aspetos da arquitetura de carga de trabalho do Fabric são:
Ele lida com processamento, armazenamento e gerenciamento de dados. Ele valida os tokens de ID do Microsoft Entra antes de processá-los e interage com serviços externos do Azure, como o Lakehouse.
O Frontend (FE) de carga de trabalho oferece uma interface de usuário para criação, criação, gerenciamento e execução de trabalhos.
As interações do usuário por meio do FE iniciam solicitações ao BE, direta ou indiretamente por meio do Fabric Backend (Fabric BE).
Para obter diagramas mais detalhados que descrevem a comunicação e a autenticação dos vários componentes, consulte a Visão geral de autenticação e autorização de back-end e os diagramas de visão geral de autenticação.
Frontend (FE)
O frontend serve como base da experiência do usuário (UX) e do comportamento, operando dentro de um iframe no portal Fabric. Ele fornece ao parceiro Fabric uma experiência de interface de usuário específica, incluindo um editor de itens. O SDK do cliente de extensão equipa as interfaces, APIs e funções de bootstrap necessárias para transformar um aplicativo Web regular em um aplicativo Web Micro Frontend que opera perfeitamente no portal Fabric.
Backend (BE)
O back-end é a potência para processamento de dados e armazenamento de metadados. Ele emprega operações CRUD para criar e gerenciar itens de carga de trabalho juntamente com metadados e executa trabalhos para preencher dados no armazenamento. A ponte de comunicação entre o frontend e o backend é estabelecida por meio de APIs públicas.
As cargas de trabalho podem ser executadas em dois ambientes: local e nuvem. No local (devmode), a carga de trabalho é executada na máquina do desenvolvedor, com chamadas de API gerenciadas pelo utilitário DevGateway. Este utilitário também lida com o registro de carga de trabalho com o Fabric. No modo de nuvem, a carga de trabalho é executada nos serviços do parceiro, com chamadas de API feitas diretamente para um ponto de extremidade HTTPS.
Ambiente de desenvolvimento
- Pacote de carga de trabalho do modo de desenvolvimento: ao criar a solução de back-end no Visual Studio, use a configuração de compilação Debug para criar um pacote BE NuGet, que pode ser carregado no locatário do Fabric usando o aplicativo DevGateway.
- Pacote de carga de trabalho do modo de nuvem: ao criar a solução BE no Visual Studio, use a configuração de compilação Release para criar um pacote de carga de trabalho autônomo (BE e FE). Este pacote pode ser carregado diretamente para o locatário.
- Para obter mais detalhes sobre as configurações de compilação Debug e Release, consulte alterar a configuração de compilação
Estrutura do pacote NuGet de carga de trabalho
A carga de trabalho é empacotada como um pacote NuGet, combinando componentes de back-end e frontend. A estrutura adere a convenções de nomenclatura específicas e é imposta pelo Fabric para consistência em cenários de carregamento. O pacote NuGet projetado para representar cargas de trabalho é estruturado para incluir componentes de back-end e frontend.
Estrutura de back-end
O segmento de back-end compreende .xml arquivos que definem a carga de trabalho e seus itens associados, que são essenciais para o registro no Fabric.
Componentes principais
WorkloadManifest.xml- O arquivo de configuração da carga de trabalho, necessário para ter esse nome exato para a verificação do Fabric.Item1.xml,Item2.xml,...- Manifestos para itens individuais com nomenclatura flexível, seguindo o formato XML.
Estrutura frontend
A seção frontend contém arquivos .json detalhando o produto e os itens para o frontend, juntamente com um diretório 'assets' para ícones.
Componentes principais
Product.json- O manifesto principal para o frontend do seu produto, que deve ser nomeado precisamente para verificação do Fabric.Item1.json,Item2.json,...- Manifestos para itens individuais com nomenclatura flexível, seguindo o formato JSON. Cada json corresponde a um manifesto de back-end (por exemplo, Item1.json a Item1.xml).assetsfolder - Armazena todos os íconesicon1.jpg,icon2.png,...usados pelo frontend.
Conformidade obrigatória com a estrutura
A estrutura, incluindo nomes específicos de subpastas ('BE', 'FE', 'assets'), é obrigatória e imposta pelo Fabric para todos os cenários de upload, incluindo pacotes de teste e desenvolvimento. A estrutura é especificada nos .nuspec arquivos encontrados no repositório sob o Backend/src/Packages/manifest diretório.
Limites
Os limites a seguir se aplicam a todos os tipos de pacotes NuGet, tanto no modo de desenvolvimento quanto no modo de nuvem:
- Apenas
BEeFEsubpastas são permitidas. Quaisquer outras subpastas ou arquivos localizados fora dessas pastas resultam em um erro de upload. - A
BEpasta aceita apenas.xmlarquivos. Qualquer outro tipo de arquivo resulta em um erro de upload. - Um máximo de 10 arquivos de item é permitido, o que significa que a
BEpasta pode conter umWorkloadManifest.xmle até 10Item.xmlarquivos. Ter mais de 10 arquivos de item na pasta resulta em um erro de upload. - A
Assetssubpasta deve residir sob aFEpasta. Pode conter até 15 ficheiros, sendo que cada ficheiro não tem mais de 1,5 MB. - Somente os seguintes tipos de arquivo são permitidos na
Assetssubpasta:.jpeg,.jpg,.png. - A
FEpasta pode conter um máximo de 10 arquivos de item mais umproduct.jsonarquivo. - Cada ativo dentro da
Assetspasta deve ser referenciado dentro dos arquivos de item. Qualquer ativo referenciado de um arquivo de item que esteja faltando naAssetspasta resultará em um erro de carregamento. - Os nomes dos arquivos dos itens devem ser exclusivos. Nomes de arquivos duplicados resultam em um erro de upload.
- Os nomes dos ficheiros devem conter apenas carateres alfanuméricos (inglês) ou hífenes e não podem exceder um comprimento de 32 carateres. Usar outros caracteres ou exceder esse comprimento resulta em um erro de upload.
- O tamanho total da embalagem não deve exceder 20 MB.
- Consulte o manifesto da carga de trabalho para obter as limitações específicas do manifesto.
Modo de desenvolvimento local (devmode)
O back-end de carga de trabalho (BE) opera na máquina do desenvolvedor. As chamadas de API de carga de trabalho são transmitidas por meio do Azure Relay, com o lado da carga de trabalho do canal de Retransmissão do Azure gerenciado por um utilitário de linha de comando especializado, o DevGateway. As chamadas de API de controle de carga de trabalho são enviadas diretamente da carga de trabalho para o Fabric, ignorando o canal de Retransmissão do Azure. O utilitário DevGateway também supervisiona o registro da instância de desenvolvimento local da carga de trabalho com o Fabric, dentro do contexto de um espaço de trabalho específico. Após o encerramento do utilitário DevGateway, o registro da instância de carga de trabalho é automaticamente rescindido. Para obter mais informações, consulte Guia de implementação de back-end.
Esquema DevMode BE
Modo de desenvolvimento na nuvem (modo na nuvem)
O backend de carga de trabalho (BE) opera dentro dos serviços do parceiro. As chamadas de API de carga de trabalho são feitas diretamente para o ponto de extremidade HTTPS, conforme especificado no manifesto da carga de trabalho. Nesse cenário, o utilitário DevGateway não é necessário. O registro da carga de trabalho com o Fabric é realizado carregando o pacote NuGet de carga de trabalho no Fabric e, posteriormente, ativando a carga de trabalho para o locatário. Para obter mais informações, consulte Gerenciar uma carga de trabalho na malha.
Esquema do CloudMode BE
