多凭证场景下每次请求构建Google TextToSpeechClient是否合理？

我们正在开发一个高校统一TTS门户，用户可选择Google、Amazon Polly等提供商并提交对应访问密钥。配置完成后，调用/api/texttospeech接口时只需传入配置ID和待转换文本，服务端流程为：

1. 根据配置ID从数据库读取配置；
2. 识别对应的提供商；
3. 创建对应提供商的类实例，构建客户端并调用TTS接口。

目前每次请求都会构建TextToSpeechClient，代码如下：

public class GoogleCloudTextToSpeechVendorAsync : TTSVendor
{

    private TextToSpeechClient _client;
    private GoogleTTSConfig _googleTTSConfig;

    public GoogleCloudTextToSpeechVendorAsync(GoogleTTSConfig googleTTSConfig)
    {
        this._googleTTSConfig = googleTTSConfig;
    }

    /// <summary>
    /// 
    /// </summary>
    public async Task BuildAsync()
    {
        byte[] byteArray = Convert.FromBase64String(this._googleTTSConfig.Base64ServiceAccount);
        var serviceAccount = Encoding.UTF8.GetString(byteArray);
    
        serviceAccount = serviceAccount.Replace(@"\\", @"\");
        GoogleCredential googleCred = GoogleCredential.FromJson(serviceAccount.ToString());

        ChannelCredentials channelCreds = googleCred.ToChannelCredentials();
        TextToSpeechClientBuilder clientBuilder = new TextToSpeechClientBuilder()
        {
            ChannelCredentials = channelCreds,
            Endpoint = "texttospeech.googleapis.com"
        };
        _client = await clientBuilder.BuildAsync();
    }

    public async Task<byte[]> TrySpeak(string voiceName, string textToSpeak) 
    {
        var input = new SynthesisInput();
        input.Text = textToSpeak;
        VoiceSelectionParams voiceSelection = new VoiceSelectionParams();
        voiceSelection.Name = voiceName;
        voiceSelection.SsmlGender = SsmlVoiceGender.Unspecified;

        AudioConfig audioConfig = new AudioConfig();
        audioConfig.SampleRateHertz = 8000;
        audioConfig.AudioEncoding = AudioEncoding.Linear16;

        var synthesizeSpeechResponse = await _client.SynthesizeSpeechAsync(input, voiceSelection, audioConfig);
        return synthesizeSpeechResponse.AudioContent.ToByteArray();
    }
}

是否可行？ #

技术上这种方式能跑通，但性能缺陷很明显：

• 每次请求都要执行Base64解码、凭证解析、客户端初始化等耗时操作，会拉长单请求响应时间，高并发场景下服务整体性能会大幅下滑；
• 客户端初始化涉及网络连接建立、认证握手等开销，重复创建会浪费服务器资源，甚至可能触发服务商的连接数限制。

优化建议 #

1. 按配置ID缓存客户端实例 #

用线程安全的容器缓存每个配置对应的客户端实例，避免重复初始化：

• 比如用ConcurrentDictionary<string, GoogleCloudTextToSpeechVendorAsync>，key为配置ID；
• 请求处理时先查缓存：存在则直接复用，不存在则创建实例并初始化后存入缓存；
• 注意配置更新场景：用户修改配置密钥后，要及时清除对应缓存，确保下次请求使用新配置创建客户端。

示例缓存逻辑：

// 全局线程安全缓存
private static readonly ConcurrentDictionary<string, GoogleCloudTextToSpeechVendorAsync> _clientCache = new();

public async Task<GoogleCloudTextToSpeechVendorAsync> GetClientAsync(string configId)
{
    if (_clientCache.TryGetValue(configId, out var client))
    {
        return client;
    }

    // 从数据库读取配置
    var config = await FetchGoogleTTSConfigFromDb(configId);
    var newClient = new GoogleCloudTextToSpeechVendorAsync(config);
    await newClient.BuildAsync();
    
    // 并发安全地存入缓存
    _clientCache.TryAdd(configId, newClient);
    return newClient;
}

2. 优化凭证解析逻辑 #

当前代码中的serviceAccount.Replace(@"\\", @"\")属于重复操作，建议在配置存储到数据库时就处理好转义问题，避免每次初始化都做字符串替换。

3. 客户端生命周期管理 #

• 给缓存实例设置过期时间：对于长时间未使用的配置，自动清理对应客户端，释放资源；
• 异常自动重建：如果客户端调用时出现凭证过期、连接失败等异常，自动从缓存移除该实例，下次请求时重新创建。

4. 提前初始化（可选） #

如果系统中的配置数量不多，可以在服务启动后或用户创建配置完成时，提前初始化对应客户端并存入缓存，消除首次请求的初始化延迟。

内容的提问来源于stack exchange，提问作者coder