Comments 9
Привет! Крутая статья) Я бы добавил в список хабов Java. Это агрегатор всех Java-технологий, включая JVM-бэкенд.
ОЗУ для Docker не менее 8 Гб
ОЗУ для микросервисов не менее 8 Гб. (Точно запускается на Ubuntu 22.04 с 64 Гб ОЗУ и 8 ядрами процессора)
Господи, какая БОЛЬ
Тут еще нужно про процессор ноутбука и систему охлаждения минимальные системные требования
У меня сейчас стоит ноут молотит микросервисы, я боюсь к нему прикасаться, работаю на нем через удаленный рабочий стол с другого ноутбука
Хорошая статья, много подробностей описали. Думаю будет интересно новичкам в стримминге данных. Ну и, раз уж столько элементов не поленились реализовать, единственное, что, на мой взгляд, упущено из важного - это БД для хранения заказов.
Хранить всю историю заказов в Кафке и использовать ее как хранилище (точнее стейт сторы на основе нескольких топиков) будет не очень правильным в данном случае.
Если случится перебалансировка партиций в Kafka Streams, стейт стор будет восстанавливаться, причем довольно долго, если топик большой. А значит, получить информацию по заказу будет невозможно. Плюс надо подумать о транзакциях, заказы вещь такая. Если использовать exactly once semantics в Kafka Streams, то причин для перебалансировки будет ещё больше)) Механизм довольно прихотливый. С БД будет проще и надёжнее.
В целом, я бы первый сервис сделал со своей БД и без KS, слал бы заказы в Кафку после записи в БД, слушал бы топики с результатами от всех остальных тропиков и менял статус заказа. Вынес бы KS в отдельный сервис и это сделало бы архитектуру стабильнее.
Желаю Вам удачи!
Правда теперь тут появляется проблема двойной записи (Dual Writes) и нам нужна CDC (change data capture) или SAGA, например. Да, реальность сурова.
Спасибо за замечание! Да, действительно с таким подходом будет более стабильная архитектура. Тут можно было бы использовать, например, Postgres в качестве основной базы для заказов и Debezium в качестве source / sink Kafka connector. В статье же я придерживался того подхода, который предлагают в Confluent, где они используют саму Kafka в качестве single source of truth.
Можно ещё сильно упростить бизенес-логику за счет workflow-as-code, которые превращает простой Java код в Kafka Stream процессор - https://github.com/javactrl/javactrl-kafka
Страшно представить, какая боль это дебажить, добавлять фичи и искать баги, особенно после того, как на подобном начнет работать какой-нибудь реальный проект (с адекватной БД и синхронизацией транзакций между всей этой событийной мешаниной)
P.S. статья, кстати, классная, интересно расписано
Микросервисы на основе событий с Kafka Streams и Spring Boot