Комментарии 9
Эх, ещё бы примеры кода на распространённых языках… но это я уже размечтался, при желании всё можно найти в интернетах :))
А за список спасибо, интересно было почитать. Добавил бы сюда ещё redis, и возможно, бд как средство общения между сервисами. Сам на одном проекте кладу данные в MySQL одним сервисом, а забираю и обрабатываю другим.
Ну и плюс в облаках свои сервисы для очередей, вроде aws sqs, тоже можно добавить в статью
Недавно был отличный опыт с комбинацией gRPC + golang, после этого если честно на REST даже смотреть не хочется. Часть положительных моментов уже расписана в статье, но хотелось бы еще добавить:
отличный тулинг для кодогенерации, как сервера, так и клиента, меньше рууами писать бойлерплейтов
очень удобный и гибкий API (в отличие от гошного net.http - правда это скорее камень в огород net.http), легко реализуются такие штуки как реконнекты, походы по разным эндпоинтам (если один отвалился), распределенная трассировка запросов
если прям очень надо именно HTTP - тулинг позволяет накодогенерить и сопутствующий HTTP сервак, причем реализацию контроллера переписывать не надо - она будет общей и для gRPC и для HTTP
Я бы накидал рекомендаций. Для того что вы описываете, как мессаджинг, отделяя от кафки, есть отличное слово AMQP-брокер. Посмотрите еще лекций как работает кафка,
кажется, что он оптимален там, где стоимость трафика выше, чем затраты на то, чтобы заставить разработчиков читать документацию Protobuf (чтобы они не модифицировали поля там, где нельзя этого делать).
Не расшифруете, что вы тут имеете в виду под «чтобы они не модифицировали поля там, где нельзя этого делать»?
Про gRPC, кажись, одну из главных деталей не упомянули — отсутствие null в качестве значений полей
В 3.15.0 снова завезли optional fields, стало как в proto2
Дополнение к мессенджерам. Есть ещё Postgres Notify, тоже простейшая шина данных, которую можно использовать если pg уже прикручен и используется в проекте.
А что именно за книга была по Кафке?
Способы общения микросервисов для самых маленьких