深入探究异步 API 的计划与实现

一、API 模式简介：同步与异步的对比

API 是客户端和服务器之间通讯的桥梁。大多数 API 接纳同步模式，实验的流程如下：

• 客户端发送哀求。
  
• 服务器处置处罚哀求。
  
• 服务器返反相应。
  

同步模式对快速操纵非常有用，好比数据查询或简单更新。但是，当遇到耗时较长的操纵时，题目就显现出来了。比方：

• 处置处罚大文件（比方视频编码、音频分析）。
  
• 大规模的数据分析与陈诉天生。
  
• 图像处置处罚（比方天生缩略图、优化图片）。
  

在这些场景中，客户端必须长时间等待，大概导致超时错误；而服务器也会由于单个长时间运行的哀求而低沉团体吞吐量。
二、同步模式的范围性

同步模式有几个焦点题目：

• 客户端等待时间过长： 哀求处置处罚时间过长，用户体验不佳。
  
• 超时风险： 网络不稳固或数据量较大时，哀求容易超时，导致失败。
  
• 服务器资源占用： 单个长时间哀求会占用服务器资源，影响其他用户哀求的相应时间。
  

这些题目促使我们探求更高效的办理方案，这就是异步 API。
三、异步 API 的概念与实现

3.1 什么是异步 API？

异步 API 的核生理念是将哀求的吸取与处置处罚分离。异步模式包罗以下两个阶段：

• 吸取哀求并快速相应： 服务器立即返回一个状态或追踪 ID，体现哀求已被吸取。
  
• 配景异步处置处罚： 哀求的现实工作在配景完成，客户端可以通过状态查询接口获取处置处罚进度。
  

3.2 异步 API 的关键上风

• 即时相应： 客户端能快速得到反馈，而不须要长时间等待。
  
• 非壅闭操纵： 服务器可以并行处置处罚多个哀求，不会由于单个使命耗时过长而壅闭其他哀求。
  
• 机动的扩展性： 配景处置处罚使命可以单独扩展，进步体系的吞吐量。
  
• 更好的错误处置处罚： 假如使命失败，可以生存进度并重试，不会影响其他哀求。
  

3.3 同步模式的具体题目示例

以下是一个常见的同步 API 示例，处置处罚图片上传及优化：

1. [HttpPost]
2. public async Task<IActionResult> UploadImage(IFormFile file)
3. {
4.     if (file is null)
5.     {
6.         return BadRequest();
7.     }
9.     // 保存原始图片
10.     var originalPath = await SaveOriginalAsync(file);
12.     // 生成缩略图
13.     var thumbnails = await GenerateThumbnailsAsync(originalPath);
15.     // 优化所有图片
16.     await OptimizeImagesAsync(originalPath, thumbnails);
18.     return Ok(new { originalPath, thumbnails });
19. }

复制代码

此模式的题目在于：

• 客户端必须等待整个流程完成。
  
• 网络毗连或图片较大时，哀求容易超时。
  
• 假如图片处置处罚失败，客户端需重新上传，浪费资源。
  

3.4 异步 API 的办理方案

• 新的图片上传接口计划
  异步模式将操纵拆分为两部门：快速吸取哀求与配景处置处罚。以下是改进后的接口：
  1. [HttpPost]
  2. public async Task<IActionResult> UploadImage(IFormFile? file)
  3. {
  4.     if (file is null)
  5.     {
  6.         return BadRequest("未上传文件。");
  7.     }
  9.     if (!imageService.IsValidImage(file))
  10.     {
  11.         return BadRequest("无效的图片文件。");
  12.     }
  14.     // 阶段 1：接收请求
  15.     var id = Guid.NewGuid().ToString();
  16.     var folderPath = Path.Combine(_uploadDirectory, "images", id);
  17.     var fileName = $"{id}{Path.GetExtension(file.FileName)}";
  18.     var originalPath = await imageService.SaveOriginalImageAsync(
  19.         file,
  20.         folderPath,
  21.         fileName
  22.     );
  24.     // 将阶段 2 的任务加入后台队列
  25.     var job = new ImageProcessingJob(id, originalPath, folderPath);
  26.     await jobQueue.EnqueueAsync(job);
  28.     // 返回状态 URL
  29.     var statusUrl = GetStatusUrl(id);
  30.     return Accepted(statusUrl, new { id, status = "queued" });
  31. }

  复制代码
• 配景使命处置处罚
  现实的图片处置处罚使命移交到配景实验，使用独立的线程或服务完成繁重的操纵：
  1. public class ImageProcessor : BackgroundService
  2. {
  3.     protected override async Task ExecuteAsync(CancellationToken ct)
  4.     {
  5.         await foreach (var job in jobQueue.DequeueAsync(ct))
  6.         {
  7.             try
  8.             {
  9.                 await statusTracker.SetStatusAsync(job.Id, "processing");
  11.                 // 生成缩略图
  12.                 await GenerateThumbnailsAsync(job.OriginalPath, job.OutputPath);
  14.                 // 优化图片
  15.                 await OptimizeImagesAsync(job.OriginalPath, job.OutputPath);
  17.                 await statusTracker.SetStatusAsync(job.Id, "completed");
  18.             }
  19.             catch (Exception ex)
  20.             {
  21.                 await statusTracker.SetStatusAsync(job.Id, "failed");
  22.                 logger.LogError(ex, "图片处理失败 {Id}", job.Id);
  23.             }
  24.         }
  25.     }
  26. }

  复制代码

四、实时状态更新的实现

4.1 状态查询接口

客户端可以通过以下接口查询使命的状态：

1. [HttpGet("{id}/status")]
2. public IActionResult GetStatus(string id)
3. {
4.     if (!statusTracker.TryGetStatus(id, out var status))
5.     {
6.         return NotFound();
7.     }
9.     var response = new
10.     {
11.         id,
12.         status,
13.         links = new Dictionary<string, string>()
14.     };
16.     if (status == "completed")
17.     {
18.         response.links = new Dictionary<string, string>
19.         {
20.             ["original"] = GetImageUrl(id),
21.             ["thumbnail"] = GetThumbnailUrl(id, width: 200),
22.             ["preview"] = GetThumbnailUrl(id, width: 800)
23.         };
24.     }
26.     return Ok(response);
27. }

复制代码

4.2 实时关照：镌汰轮询

固然状态查询接口是一个办理方案，但它增长了客户端和服务器的负担。特别是客户端须要频仍轮询状态，导致大量无效的哀求。
使用 SignalR 和 WebSocket 可以实现实时关照。状态厘革时，服务器主动向客户端推送更新，镌汰网络流量并进步相应速率。比方：

• 当图片处置处罚完成时，服务器通过 WebSocket 关照客户端。
  
• 用户可以立即获取完成的结果，而无需多次革新页面。
  

4.3 其他关照方式

• 电子邮件关照： 实用于长时间运行的使命，用户可在使命完成时收到关照，而无需保持欣赏器页面开启。
  
• Webhook 回调： 实用于体系间通讯，使命完成时服务器主动关照其他体系，实现主动化工作流。
  

五、性能优化与扩展性

5.1 使命队列计划

对于单服务器应用，可以使用 .NET 的 Channel 管理内存中的使命队列：

1. public class JobQueue
2. {
3.     private readonly Channel<ImageProcessingJob> _channel;
5.     public JobQueue()
6.     {
7.         var options = new BoundedChannelOptions(1000)
8.         {
9.             FullMode = BoundedChannelFullMode.Wait
10.         };
11.         _channel = Channel.CreateBounded<ImageProcessingJob>(options);
12.     }
14.     public async ValueTask EnqueueAsync(ImageProcessingJob job,
15.         CancellationToken ct = default)
16.     {
17.         await _channel.Writer.WriteAsync(job, ct);
18.     }
20.     public IAsyncEnumerable<ImageProcessingJob> DequeueAsync(
21.         CancellationToken ct = default)
22.     {
23.         return _channel.Reader.ReadAllAsync(ct);
24.     }
25. }

复制代码

对于分布式体系，可以使用 RabbitMQ 或 Redis 实现分布式使命队列，进步扩展性。
5.2 错误处置处罚与重试机制

使用 Polly 等库实现重试战略。比方：

• 图片优化失败时，体系可以主动重试多次，制止用户操纵制止。
  
• 假如某个使命失败，可以记载进度并重新列队，确保体系稳固性。
  

5.3 动态扩展

异步 API 的计划使得配景使命处置处罚可以独立扩展。比方，增长更多的服务器专门处置处罚使命，而主服务器则专注于吸取哀求。这种分离进步了整个体系的吞吐量和可靠性。
六、总结

同步 API 简单高效，实用于快速操纵，但在处置处罚耗时使命时暴袒露等待时间长、超时风险高、资源占用严肃等范围性。为办理这些题目，异步 API 应运而生，其焦点是将哀求吸取与处置处罚分离。通过即时相应和配景异步处置处罚，异步 API 提供了更好的用户体验和体系性能。联合使命队列、实时状态更新（如 SignalR）以及动态扩展等技能，异步 API 实现了高并发、低耽误和机动扩展，恰当处置处罚复杂使命场景。同时，配套的错误重试和关照机制提拔了体系的可靠性和用户满足度。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金