如何管理 Web 应用程序中的长进程
How to manage a long processes in web app
我正在尝试在 Go 中实现以下功能。
我有一个带有表单的网页，用于上传 .csv 文件。
Gorilla mux 用于路由到一个处理程序，该处理程序获取文件并对其进行解析，对数据进行一系列操作，最后生成一份报告，其中包含已解析的行数、拒绝行数等。
我的问题是，即使它可以在我的机器上运行，但在服务器上 Apache 会在我完成所有操作之前超时：文件上传本身不是问题，但我必须等待用于完成数据转换。
我尝试使用 Gorilla websocket 从流程中获取反馈（例如，增加解析和处理的行数）并保持连接打开，但这是一个 POST 请求，而 Gorilla除非有 GET 请求，否则 websocket 不会从 http 升级到 websocket。
我什至不确定我是否在正确的轨道上使用 websockets 来做这类事情。
我可以有一个 goroutine 用于处理本身和 return goroutine 完成之前的处理程序，但是我如何在 UI 中显示过程的结果？
所以在这个阶段，我的问题归结为：在 Go 中，当您需要时，什么是最好的方法：
- 上传文件，
- 等待一个漫长的过程完成
- 并在网页中显示结果？
将不胜感激关于正确方向的线索。
您遇到了一个非常重要的问题。有很多可能的解决方案，具有不同的用户体验、实施复杂性和副作用。这是一个很大的话题，所以这个答案主要是作为进一步研究的起点。
最简单的选择
首先，无论解决方案如何，您都必须为每个长运行 任务提供一个唯一的 ID，浏览器可以使用该 ID 稍后获取状态更新。任务运行器本身可以将作业标记为已完成，或者如果您想向用户展示进度，它可以定期发布进度更新。
最容易实现的可能是让您的表单提交立即响应页面，任务 ID 包含在 URL 中，其处理程序检查任务状态，并且 a) returns带有 "still working" 或类似效果的页面并在几秒钟后自动刷新，或者 b) returns 页面显示 "completed" 并且不刷新。这并不是很难实现，但也不是特别顺利。如果这是一个简单的内部使用项目，具有简单的用户体验和操作要求，我会这样做。否则，我们继续深入兔子洞！
实时更新
您可以通过几种不同的方法在不重新加载页面的情况下进行实时更新：
- 定期 AJAX 请求检查任务状态，根据响应更新 UI。这将在后端有一个 REST 风格的处理程序。
- 您可以使用 WebSockets 通过单个连接执行相同的操作。
- 您可以使用 HTTP 长轮询来模拟类似 WebSocket 的行为，但这通常已被 WebSocket 取代。
任一选项都需要处理程序来提供状态更新信息，并且需要前端的一些 JavaScript 魔法来调用处理程序、解析响应并更新页面。
副作用
根据此服务的规模和要求，需要考虑一些副作用；主要是 long-运行 任务实际上是一种应用程序状态，使您的应用程序有状态，这在可用性、扩展和部署方面有一些严重的操作缺点。如果您是 运行 多个负载平衡实例，则必须使用粘性会话或以某种方式在实例之间共享任务状态。
大规模处理长时间 运行 任务的最常见方法是使用某种工作队列（在数据库或专用消息代理（如 Rabbit 或Kafka）来管理任务。这使得获取状态更新变得有点复杂，因为您正在跨流程工作，但它为您提供了更多的操作灵活性。
我猜这是一个比您预期的更复杂的答案 "requests are timing out"，但这是一个具有非平凡解决方案的微不足道的问题。您当然不是唯一一个解决这个问题的人；研究在 Web 应用程序中处理长 运行 任务将产生大量您可以利用的信息。
我正在尝试在 Go 中实现以下功能。
我有一个带有表单的网页，用于上传 .csv 文件。 Gorilla mux 用于路由到一个处理程序，该处理程序获取文件并对其进行解析，对数据进行一系列操作，最后生成一份报告，其中包含已解析的行数、拒绝行数等。
我的问题是，即使它可以在我的机器上运行，但在服务器上 Apache 会在我完成所有操作之前超时：文件上传本身不是问题，但我必须等待用于完成数据转换。
我尝试使用 Gorilla websocket 从流程中获取反馈（例如，增加解析和处理的行数）并保持连接打开，但这是一个 POST 请求，而 Gorilla除非有 GET 请求，否则 websocket 不会从 http 升级到 websocket。
我什至不确定我是否在正确的轨道上使用 websockets 来做这类事情。
我可以有一个 goroutine 用于处理本身和 return goroutine 完成之前的处理程序，但是我如何在 UI 中显示过程的结果？
所以在这个阶段，我的问题归结为：在 Go 中，当您需要时，什么是最好的方法：
- 上传文件，
- 等待一个漫长的过程完成
- 并在网页中显示结果？
将不胜感激关于正确方向的线索。
您遇到了一个非常重要的问题。有很多可能的解决方案，具有不同的用户体验、实施复杂性和副作用。这是一个很大的话题，所以这个答案主要是作为进一步研究的起点。
最简单的选择
首先，无论解决方案如何，您都必须为每个长运行 任务提供一个唯一的 ID，浏览器可以使用该 ID 稍后获取状态更新。任务运行器本身可以将作业标记为已完成，或者如果您想向用户展示进度，它可以定期发布进度更新。
最容易实现的可能是让您的表单提交立即响应页面，任务 ID 包含在 URL 中，其处理程序检查任务状态，并且 a) returns带有 "still working" 或类似效果的页面并在几秒钟后自动刷新，或者 b) returns 页面显示 "completed" 并且不刷新。这并不是很难实现，但也不是特别顺利。如果这是一个简单的内部使用项目，具有简单的用户体验和操作要求，我会这样做。否则，我们继续深入兔子洞！
实时更新
您可以通过几种不同的方法在不重新加载页面的情况下进行实时更新：
- 定期 AJAX 请求检查任务状态，根据响应更新 UI。这将在后端有一个 REST 风格的处理程序。
- 您可以使用 WebSockets 通过单个连接执行相同的操作。
- 您可以使用 HTTP 长轮询来模拟类似 WebSocket 的行为，但这通常已被 WebSocket 取代。
任一选项都需要处理程序来提供状态更新信息，并且需要前端的一些 JavaScript 魔法来调用处理程序、解析响应并更新页面。
副作用
根据此服务的规模和要求，需要考虑一些副作用；主要是 long-运行 任务实际上是一种应用程序状态，使您的应用程序有状态，这在可用性、扩展和部署方面有一些严重的操作缺点。如果您是 运行 多个负载平衡实例，则必须使用粘性会话或以某种方式在实例之间共享任务状态。
大规模处理长时间 运行 任务的最常见方法是使用某种工作队列（在数据库或专用消息代理（如 Rabbit 或Kafka）来管理任务。这使得获取状态更新变得有点复杂，因为您正在跨流程工作，但它为您提供了更多的操作灵活性。
我猜这是一个比您预期的更复杂的答案 "requests are timing out"，但这是一个具有非平凡解决方案的微不足道的问题。您当然不是唯一一个解决这个问题的人；研究在 Web 应用程序中处理长 运行 任务将产生大量您可以利用的信息。