我正在使用 Azure Function 应用服务计划来满足客户端请求。选择 Azure 服务计划的原因是，请求运行时间较长，需要超过 10 分钟。
我正在寻找实现 Azure 架构，该架构将具有成本效益，并且对于大量请求性能更好。
有关我可以使用哪些 Azure 组件或我应该遵循哪些架构的任何建议。
最佳答案
有关工作负载的更多详细信息和特征确实有必要提供任何可靠的建议(例如，它是内存、CPU 密集型吗？它是否依赖于下游资源等)。根据您的工作负载，功能和/或应用服务可能不适合。
从较高的层面考虑是否可以选择重构这个 10 分钟的流程。很多时候，长时间运行的任务实际上是许多较小的任务，可以将其分解，以便它们各自的执行时间是合理的，然后您可以利用无服务器(Azure Functions)的扩展功能。如果是这种情况，但分解它太复杂而无法编排，请考虑使用耐用功能或逻辑应用之类的东西来为您提供编排。
一般来说，如果我有长时间运行的请求，这通常意味着从用户角度来看它是异步的，并且延迟不是问题，因此另一个选择是在按消耗计划运行的 Azure 函数上使用 Http 触发器 (API)，以便它将根据需要进行扩展，接受请求并将其放入队列中，但队列监听器位于专用计算上，没有时间限制(例如应用程序服务计划上的功能、Azure 容器实例等)。请记住，您需要小心队列长度，因为您的队列中可能会收到大量请求，但在可接受的时间范围内在专用计算上处理这些请求的资源有限。
归根结底，尽管“成本效益”和“性能”通常是一个艰难的要求(在无服务器之外)，但我的建议是如果可以的话重构您的工作负载。
关于azure - 如果我的 Web api/azure 函数要处理大量请求，我应该遵循什么 Azure 架构？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53102519/