我们正在用java构建一个微服务。微服务的职责是通过处理传入的请求来发送电子邮件。为了不影响性能，我们希望异步发送电子邮件。因此，我们将把消息排队到一个队列（在另一个微服务中）。我们将必须支持数百个租户，并且每个租户有数十个队列。因此，该设计应该随着承租者和队列数量的增长而可伸缩。
现有解决方案：
我们将在k8中进行部署。因此，我们有多个服务示例在pod上的Docker容器中运行。假设我们创建了100个队列（在其他微服务中--比如说队列服务），
我们有一个后台作业，每10秒在每个pod上定期运行一次，以检测新队列。对于每个队列，我们启动2个线程- a）轮询线程-负责轮询来自queu-service的消息，并将其放入本地队列b）处理线程-负责处理来自本地队列的消息。处理消息意味着在我们的用例中发送电子邮件
对于每一个队列，我们最终都会旋转轮询和处理线程
这种解决方案显然是不可扩展的，因为我们无法继续为每个单元上的每个队列创建新线程
我的观察：我遇到过一个框架Akka，它似乎可以解决类似的问题- a）在群集中的所有可用单元之间共享工作负载- Akka群集模块b）在群集拓扑发生更改时重新平衡工作负载
我不熟悉Akka和基于演员的模型等概念
想知道Akka是否适合当前的问题？如果是，以及如何使用Akka在高级别上为我的问题建模设计-特别是围绕如何在每个pod上分配租户和队列，以及如何轮询队列服务中存在的每个队列上的消息以及如何处理消息？
1条答案
按热度按时间tquggr8v1#
我所采用的一般方法是将每个承租者建模为一个集群分片的参与者，这将为与该承租者关联的每个队列产生一个参与者。为队列产生的参与者将管理检查队列、从队列中提取消息以及确认消息的过程。
至于排队参与者如何处理提取消息，一般的方法是将发送电子邮件的实际工作交给另一个参与者，从为了管理发送而生成参与者（如果确实没有任何可重用的基础架构用于发送电子邮件，则效果很好）到为租户维护池（如果有一些昂贵的基础设施，您可以为每个参与者启动一次，并在多次发送中分摊，这是很好的选择）到传递到一个流（它是在参与者的引擎盖下实现的，但您可以获得许多潜在有用的流控制和资源消耗控制）来发送电子邮件。