【问题标题】：Microservice along with kafka consumer Group微服务以及卡夫卡消费者组
【发布时间】：2019-03-11 14:51:40
【问题描述】：
我们正在开发一个使用 kafka 的应用程序。
Application的组件如下，
我们有一个微服务，它获取请求并将消息推送到 kafka 主题。 （假设是 ServiceA）
另一个使用来自主题的消息并将数据推送到数据存储的微服务。 （假设是 ServiceB）
我对应用程序的 ServiceA 部分很清楚，但在 ServiceB 部分有一些设计混乱。
作为 ServiceB，我们正在计划 REST API，
- 将消费者和控制器捆绑在一个应用程序中是否很好？
- 对于消费者，我计划使用具有多个消费者的消费者组来实现更高的吞吐量。有没有更好更有效的方法？
- 我是否应该取出 ServiceB 的 Consumer 部分并将其作为独立的单独服务？
- 如果我们将它捆绑在 ServiceB 中，我应该将 Consumer 配置为 Listener 吗？ （我们将使用 Spring Boot 进行微服务）
提前致谢！
【问题讨论】：
标签：
rest
spring-boot
apache-kafka
microservices
kafka-consumer-api
【解决方案1】：
将消费者和控制器捆绑在一个应用程序中是否很好
?
通过上下文捆绑在一起，有一个监听器，转发到另一个服务来控制在我看来是没有意义的。但如有必要，请考虑按不同的上下文拆分控制器。正如 Martin Fowler 所说：先从单体开始，然后再拆分 (https://martinfowler.com/bliki/MonolithFirst.html)
对于消费者，我计划与多个 ConsumerGroup 一起使用
消费者获得更多的吞吐量。有没有更好的和
有效的方法？
如果您考虑扩展您的服务 B，那么一个消费者群体是有意义的。如果您希望将来有这种可能性，请从消费者组内的一个 ServiceB 实例开始。如果您使用 Kubernetes 之类的东西，如果需要，稍后部署更多服务实例很简单。但不要在最终的未来投资太多。从简单的开始做一些监控，如果你发现了一些瓶颈，那就行动吧。要记住的另一件事是，kafka 默认情况下会保留消息很长时间（我猜默认为 7 天），因此，如果您采用经典的消息代理样式，您可能会得到很多重复的消息。考虑一下更新消息，如果发生变化，它会在您的 ServiceA 启动时引发。也许减少retention.ms 是一种选择，但请注意不要丢失消息。
我是否应该取出 ServiceB 的消费者部分并将其作为
独立的独立服务？
不，我认为不是。
如果我们将它捆绑在 ServiceB 中，我应该配置 Consumer
作为听众？ （我们将使用 Spring Boot 进行微服务）
是的:-)