我们正在用 Java 构建一个微服务。微服务的职责是通过处理传入的请求来发送电子邮件。为了不影响性能，我们希望异步发送电子邮件。所以我们将消息排队到一个队列（在另一个微服务中）。我们将不得不支持数百个租户，每个租户有数十个队列。因此，随着租户和队列数量的增长，设计应该具有可扩展性。
现有解决方案：
我们将在 k8s 中部署。因此，我们在 pod 上的 docker 容器中运行了多个服务实例。假设我们创建了 100 个队列（在其他微服务中 - 比如说队列服务），
我们有一个后台作业，每 10 秒在每个 Pod 上定期运行一次，以检测新队列。 对于每个队列，我们启动 2 个线程 - a) 轮询线程——负责从队列服务轮询消息并将其放入本地队列 b) 处理线程——负责处理来自本地队列的消息。消息处理意味着在我们的用例中发送电子邮件
对于每个队列，我们最终都会旋转轮询和处理线程
这个解决方案显然不可扩展，因为我们不能继续为每个 Pod 上的每个队列创建新线程
我的观察： 我遇到了一个框架 Akka，它似乎解决了类似的问题 - a) 在集群中的所有可用 Pod 之间共享工作负载 - Akka 集群模块 b) 在集群拓扑变化时重新平衡工作负载
我不熟悉 Akka 和基于 actor 的模型和其他概念
想知道 Akka 是否适合解决手头的问题？如果是，以及如何使用 Akka 在高层次上为我的问题建模 - 特别是围绕如何在每个 pod 上分配租户和队列，以及如何在队列服务中存在的每个队列上轮询消息以及如何处理消息？
答案 0 :(得分：0)
我将采用的一般方法是将每个租户建模为一个集群分片actor，这将为与该租户关联的每个队列生成一个actor。为队列生成的角色将管理检查队列、从队列中拉出消息和确认消息的过程。
至于队列参与者对拉取的消息执行的操作，一般的方法是将向不同参与者发送电子邮件的实际工作移交给它。根据要求，从仅出于管理发送的目的而产生参与者（如果没有任何可重用的基础设施用于发送电子邮件）到为租户维护池（如果有一些昂贵的基础设施可以启动，则很好）每个演员一次并分摊多次发送）到移交给一个流（这是在演员的幕后实现的，但你可以在交易中获得很多潜在有用的流量控制和资源消耗控制）来发送电子邮件。< /p>