evento
Participe do Desafio Microsoft Learn
19/11, 23 - 10/01, 23
Ignite Edition - Desenvolva habilidades no Microsoft Azure e ganhe um selo digital até 10 de janeiro!
Registe-se agoraEste browser já não é suportado.
Atualize para o Microsoft Edge para tirar partido das mais recentes funcionalidades, atualizações de segurança e de suporte técnico.
Este artigo ajuda você a entender os problemas de segurança de thread ao usar o SDK do Azure. Ele também discute como o design do SDK afeta o gerenciamento do tempo de vida do cliente. Você aprenderá por que é desnecessário descartar objetos de cliente do SDK do Azure.
Todos os objetos de cliente do SDK do Azure são thread-safe e independentes uns dos outros. Esse design garante que a reutilização de instâncias de cliente seja sempre segura, mesmo entre threads. Por exemplo, o código a seguir inicia várias tarefas, mas é thread safe:
var client = new SecretClient(
new Uri("<secrets_endpoint>"), new DefaultAzureCredential());
foreach (var secretName in secretNames)
{
// Using clients from parallel threads
Task.Run(() => Console.WriteLine(client.GetSecret(secretName).Value));
}
Os objetos de modelo usados pelos clientes SDK, sejam modelos de entrada ou saída, não são thread-safe por padrão. A maioria dos casos de uso envolvendo objetos de modelo usa apenas um único thread. Portanto, o custo de implementar a sincronização como um comportamento padrão é muito alto para esses objetos. O código a seguir ilustra um bug no qual acessar um modelo a partir de vários threads pode causar um comportamento indefinido:
KeyVaultSecret newSecret = client.SetSecret("secret", "value");
foreach (var tag in tags)
{
// Don't use model type from parallel threads
Task.Run(() => newSecret.Properties.Tags[tag] = CalculateTagValue(tag));
}
client.UpdateSecretProperties(newSecret.Properties);
Para acessar o modelo de threads diferentes, você deve implementar seu próprio código de sincronização. Por exemplo:
KeyVaultSecret newSecret = client.SetSecret("secret", "value");
// Code omitted for brevity
foreach (var tag in tags)
{
Task.Run(() =>
{
lock (newSecret)
{
newSecret.Properties.Tags[tag] = CalculateTagValue(tag);
}
);
}
client.UpdateSecretProperties(newSecret.Properties);
Como os clientes do SDK do Azure são thread-safe, não há razão para construir vários objetos de cliente SDK para um determinado conjunto de parâmetros do construtor. Trate os objetos de cliente do SDK do Azure como singletons depois de construídos. Essa recomendação geralmente é implementada registrando objetos de cliente do SDK do Azure como singletons no contêiner Inversion of Control (IoC) do aplicativo. A injeção de dependência (DI) é usada para obter referências ao objeto do cliente SDK. O exemplo a seguir mostra um registro de objeto de cliente singleton:
var builder = Host.CreateApplicationBuilder(args);
var endpoint = builder.Configuration["SecretsEndpoint"];
var blobServiceClient = new BlobServiceClient(
new Uri(endpoint), new DefaultAzureCredential());
builder.Services.AddSingleton(blobServiceClient);
Para obter mais informações sobre como implementar DI com o SDK do Azure, consulte Injeção de dependência com o SDK do Azure para .NET.
Como alternativa, você pode criar uma instância de cliente SDK e fornecê-la a métodos que exigem um cliente. O objetivo é evitar instanciações desnecessárias do mesmo objeto cliente SDK com os mesmos parâmetros. É desnecessário e desperdiçador.
Duas perguntas finais que surgem frequentemente são:
Internamente, todos os clientes do SDK do Azure usam uma única instância compartilhada HttpClient
. Os clientes não criam outros recursos que precisem ser ativamente liberados. A instância compartilhada HttpClient
persiste durante todo o tempo de vida do aplicativo.
// Both clients reuse the shared HttpClient and don't need to be disposed
var blobClient = new BlobClient(new Uri(sasUri));
var blobClient2 = new BlobClient(new Uri(sasUri2));
É possível fornecer uma instância personalizada de para um objeto de cliente do SDK do HttpClient
Azure. Neste caso, você se torna responsável por gerenciar a HttpClient
vida útil e descartá-la corretamente no momento certo.
var httpClient = new HttpClient();
var clientOptions = new BlobClientOptions()
{
Transport = new HttpClientTransport(httpClient)
};
// Both clients would use the HttpClient instance provided in clientOptions
var blobClient = new BlobClient(new Uri(sasUri), clientOptions);
var blobClient2 = new BlobClient(new Uri(sasUri2), clientOptions);
// Code omitted for brevity
// You're responsible for properly disposing httpClient some time later
httpClient.Dispose();
Orientações adicionais para o gerenciamento e o descarte adequados de HttpClient
instâncias podem ser encontradas na HttpClient documentação.
Comentários do .NET
O .NET é um projeto código aberto. Selecione um link para fornecer comentários:
evento
Participe do Desafio Microsoft Learn
19/11, 23 - 10/01, 23
Ignite Edition - Desenvolva habilidades no Microsoft Azure e ganhe um selo digital até 10 de janeiro!
Registe-se agoraFormação
Módulo
Os 5 principais itens de segurança que deve ter em conta antes de enviar para a produção - Training
Saiba mais sobre a abordagem de Engenharia de Confiabilidade do Site perante o desafio de garantir a confiabilidade e obter uma melhor compreensão da sua importância.
Certificação
Microsoft Certified: Azure Developer Associate - Certifications
Crie soluções de ponta a ponta no Microsoft Azure para criar Funções do Azure, implementar e gerenciar aplicativos Web, desenvolver soluções utilizando o Armazenamento do Microsoft Azure e muito mais.