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

Способы общения микросервисов для самых маленьких

Время на прочтение8 мин
Количество просмотров64K
Всего голосов 10: ↑9 и ↓1+8
Комментарии9

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

Эх, ещё бы примеры кода на распространённых языках… но это я уже размечтался, при желании всё можно найти в интернетах :))

А за список спасибо, интересно было почитать. Добавил бы сюда ещё redis, и возможно, бд как средство общения между сервисами. Сам на одном проекте кладу данные в MySQL одним сервисом, а забираю и обрабатываю другим.

Ну и плюс в облаках свои сервисы для очередей, вроде aws sqs, тоже можно добавить в статью

Недавно был отличный опыт с комбинацией gRPC + golang, после этого если честно на REST даже смотреть не хочется. Часть положительных моментов уже расписана в статье, но хотелось бы еще добавить:

  • отличный тулинг для кодогенерации, как сервера, так и клиента, меньше рууами писать бойлерплейтов

  • очень удобный и гибкий API (в отличие от гошного net.http - правда это скорее камень в огород net.http), легко реализуются такие штуки как реконнекты, походы по разным эндпоинтам (если один отвалился), распределенная трассировка запросов

  • если прям очень надо именно HTTP - тулинг позволяет накодогенерить и сопутствующий HTTP сервак, причем реализацию контроллера переписывать не надо - она будет общей и для gRPC и для HTTP

Я бы накидал рекомендаций. Для того что вы описываете, как мессаджинг, отделяя от кафки, есть отличное слово AMQP-брокер. Посмотрите еще лекций как работает кафка,

чертов встроенный редактор хабра.) Я хотел сказать, что важно понимать как связаны слова kafka и лог с указателем) И если уже вы касаетесь древнего SOAP, то было бы круто взять более современный аналог с аналогичным подходом - GraphQl

Про gRPC, кажись, одну из главных деталей не упомянули — отсутствие null в качестве значений полей (они всегда инициализируются дефолтными для типа значениями, как и структуры в Go, т.е. никакой вам троичной логики). Какой-нибудь аналог PATCH (когда необходимо обновить только часть полей объекта, в зависимости от того, какой набор полей в запросе пришел) устанете делать, прийдется флагами на каждое поле обвеситься.

кажется, что он оптимален там, где стоимость трафика выше, чем затраты на то, чтобы заставить разработчиков читать документацию Protobuf (чтобы они не модифицировали поля там, где нельзя этого делать).

Не расшифруете, что вы тут имеете в виду под «чтобы они не модифицировали поля там, где нельзя этого делать»?

Про gRPC, кажись, одну из главных деталей не упомянули — отсутствие null в качестве значений полей

В 3.15.0 снова завезли optional fields, стало как в proto2

Ого, как-то мимо меня прошло. Спасибо!

Дополнение к мессенджерам. Есть ещё Postgres Notify, тоже простейшая шина данных, которую можно использовать если pg уже прикручен и используется в проекте.

А что именно за книга была по Кафке?

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