Хорошо ли объединять потребителя и контроллеры в одном приложении?
В моем мнении нет смысла связывать воедино по контексту, имея слушателя, который перенаправляет в другой сервис для управления. Но рассмотрите возможность разделения контроллера на другой контекст, если это необходимо. Как говорит Мартин Фаулер: сначала начните с монолита, а потом разделитесь (https://martinfowler.com/bliki/MonolithFirst.html)
Для потребителя я планирую использовать ConsumerGroup с несколькими
Потребитель должен достичь большей пропускной способности. Есть ли лучше и
эффективный подход?
Группа потребителей имеет смысл, если вы задумываетесь о расширении услуг B. Если вы хотите иметь такую возможность в будущем, начните с одного экземпляра ServiceB внутри группы потребителей. Если вы используете что-то наподобие kubernetes, то позже просто разверните больше экземпляров вашего сервиса, если потребуется. Но не стоит много вкладывать в возможное будущее. Начните с простого и проведите некоторый мониторинг, и если вы обнаружите несколько бутылочных горлышек, то действуйте. Еще одна вещь, которую нужно иметь в виду, это то, что kafka по умолчанию хранит сообщения в течение длительного времени (я думаю, по умолчанию 7 дней), поэтому, если вы работаете в классическом стиле брокера сообщений, вы можете получить много дубликатов ваших сообщений. Подумайте об сообщении об обновлении, если что-то изменится, которое появляется при запуске ServiceA. Возможно, было бы целесообразно уменьшить retention.ms, но будьте осторожны, чтобы не потерять сообщения.
Должен ли я взять Потребительскую часть ServiceB и сделать ее как
отдельный сервис, который независим?
Нет, я так не думаю.
Если мы связываем его внутри ServiceB, я должен настроить Consumer
как слушатель? (Едем с пружинной загрузкой для микросервиса)
Да: -)