如何在无服务器架构中批量处理下游操作？
我们有一个多租户解决方案，分为多个内部服务。这些内部服务（微服务，如果您愿意的话...）都是使用 Azure Functions (Node.js) 和队列（Azure 服务总线和 Azure 存储队列）构建的。
对于我们的一项服务，负载分布非常不均匀。对于任何单个租户，我们可以在几分钟内看到 40 万次操作，然后几个小时（甚至几天）内没有任何操作。对于我们的内部服务来说，这不是问题——我们将所有操作放在一个服务总线队列上，并尽快一一处理。问题在于，每个操作处理后还需要传递给第三方服务，而这个服务无法应对微服务架构的高频处理。第三方服务通过 HTTP 调用，并要求在单个请求中批处理多个操作（最多 500 个操作/请求）。当操作发送到第三方服务时，还需要按租户进行分组，因此我们无法在单个请求中发送来自多个租户的操作。
解决此问题的一种方法可能是将每个已处理的操作临时存储在 CosmosDB 或表存储中，然后使用单独的 Azure Function 持续查询该存储以查找新操作，一次获取 500 个操作，并将它们传递给第三个操作。聚会服务。这可能会起作用，但由于我们希望尽快向下游发送操作（理想情况下在几秒钟内，而不是超过几分钟），并且我们必须查询每个租户以检查是否有新的操作要发送，因此由于操作分布非常不均匀，将会浪费大量周期。
另一种方法可能是使用服务总线并为每个租户创建一个主题。然后，我们可以将所有已处理的操作放在正确的主题上，然后批量使用这些消息并将它们传递给第三方服务。这样做的好处是我们不必不断查询新操作。缺点是我们必须有很多主题，而主题感觉不像是适合这项工作的正确工具 - 但我可能是错的。
对于这个问题有更好的解决方案吗？
We have a multi-tenant solution, split over a number of internal services. These internal services (microservices if you wish...) are all built with Azure Functions (Node.js) and queues (Azure Service Bus and Azure Storage Queues).
For one of our services, the load distribution is very uneven. For any single tenant, we can see 400k operations in a matter of minutes, and then nothing for hours (or even days). For our internal service, this is not a problem - we put all operations on a Service Bus queue and process them one by one as quickly as possible. The problem is that every operation also needs to be passed to a third-party service after processing, and this service cannot handle the high-frequency processing of a microservice architecture. The third-party service is called over HTTP, and requires that multiple operations are batched in a single request (maximum 500 ops / request). The operations also need to be grouped by tenant when sent to the third-party service, so we cannot send operations from more than one tenant in a single request.
One way to solve this might be to temporarily store every processed operation in CosmosDB or Table Storage, and then have a separate Azure Function that continuously queries that storage for new operations, fetch them 500 at a time, and pass them along to the third-party service. This would probably work, but since we want to send operations downstream as quickly as possible (ideally within seconds, and not more than minutes), and we would have to query for every single tenant to check if there are new operations to send, there would be a lot of wasted cycles given the very uneven distribution of operations.
Another way might be to use Service Bus and create a topic for every tenant. We could then put all processed operations on the right topic, and then consume those messages in batches and pass them along to the third-party service. The upside of this is that we wouldn't have to continuously query for new operations. The downside is that we would have to have A LOT of topics, and topics don't feel like the right tool for the job - but I might be wrong.
Are there any better solutions to this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论