微服务以及kafka消费者小组

Question

我们正在研究使用kafka的应用程序。

应用程序的组件如下，

1. 我们有一个微服务，它获取请求并将消息推送到kafka主题。 （假设是ServiceA）

2. 另一个微服务，该微服务使用主题中的消息并将数据推送到数据存储中。 （假设是ServiceB）

我很清楚应用程序的ServiceA部分，但ServiceB部分有一些设计混乱。

作为ServiceB，我们正在计划REST API，

1. 将消费者和控制器捆绑在一个应用程序中是否很好？
2. 对于消费者，我正计划与具有多个消费者的ConsumerGroup一起使用，以实现更高的吞吐量。有没有更好，更有效的方法？
3. 我应该删除ServiceB的“消费者”部分并将其作为独立的独立服务吗？
4. 如果我们将其捆绑在ServiceB内，是否应该将Consumer配置为侦听器？ （我们将使用用于微服务的spring boot）

预先感谢！

Answer 1

  

在单个应用程序中捆绑使用者和控制器是否很好   ？

在上下文中将其捆绑在一起，拥有一个侦听器，将其转发到另一个服务进行控制是很好的，这对我的选择来说毫无意义。但如有必要，请考虑按不同的上下文拆分控制器。就像马丁·福勒（Martin Fowler）所说：首先从整体开始，然后分裂（https://martinfowler.com/bliki/MonolithFirst.html）

  

对于消费者，我计划与ConsumerGroup一起使用多个   消费者可以实现更高的吞吐量。有没有更好的选择   有效的方法？

如果考虑扩展服务B，那么一个消费群体是有意义的。如果希望将来有这种可能性，请从使用者组中的一个ServiceB实例开始。如果您使用kubernetes之类的东西，稍后在需要时部署更多服务实例将很简单。但是不要在将来最终投入太多。从简单开始并进行一些监视，如果发现瓶颈，则不要采取行动。需要记住的另一件事是，默认情况下，kafka会将消息保留很长时间（我估计默认情况下为7天），因此，如果您使用经典的消息代理风格，则可能会收到很多重复消息。考虑一下更新消息（如果发生了某些变化），该消息会在ServiceA启动时引发。也许可以减少保留时间。ms是一种选择，但请注意不要散乱邮件。

  

我应该删除ServiceB的“消费者”部分并将其作为   独立的服务是独立的吗？

不，我不认为。

  

如果我们将其捆绑在ServiceB内，我应该配置Consumer吗   作为听众？ （我们将使用用于微服务的spring boot）

是：-）