Как стать автором
Поиск
Написать публикацию
Обновить

Часть 2: Как я реализовал взаимодействие микросервисов — Kafka и gRpc

Уровень сложностиСредний
Время на прочтение21 мин
Количество просмотров12K
Всего голосов 58: ↑58 и ↓0+83
Комментарии7

Комментарии 7

Как будто бы уже пора переходить с ZooKeeper на Raft, нет?

Всё так, docker образ использовал с ним, пример на github по ссылке в статье, а рассказал про ZooKeeper, так как по сей день используется в legacy

Глянул репозиторий, вижу, что там Spring Security с Jwt и авторизацией. А как между микросервисами аутентификация реализовали?

Для Kafka передавал JWT в хедерах, для gRPC через интерцептор, заполняя метаданные

Планируете про Security модуль + KeyCloak рассказывать? В целом чего ждать по схеме взаимодействия дальше?

В планах покрыть эту тему целиком, но в ближайшее время будет статья на другую тему, не менее интересную)

Если смотреть на это с точки зрения DDD - то доменная область у картинок для инцидентов может быть одна и та же. И выделение отдельного сервиса для хранения картинок может сыграть плохую шутку. Сначала этот сервис использует только одно приложение. Дальше два и больше. В него начинают добавляться новые юз кейсы, которые усложняют сервис и он может стать похожим на Big Ball of Mud.

У меня был очень хороший пример с сервисом биллинга. Сначала он хранил и рассчитывал сделки для платежей. Потом для возвратов. Потом комиссии за сделки, не связанные с платежами... И слово "микро" (микро сервис) было к нему уже не применимо

P.S. Я не говорю что так делать не надо - но выделение переиспользуемого сервиса это двоякий вопрос

Зарегистрируйтесь на Хабре, чтобы оставить комментарий