Pull to refresh

Comments 9

Может, тупой вопрос, но.. Зачем между сервисами может понадобиться гонять несколько сотен гигабайт данных?

В общем смысле ответ таков. Каждый сервис занимается своими задачами, поддерживается отдельной командой и отвечает за выделенную предметную область.

Но различные процессы в одних сервисах могут запускаться как реакция на изменения в других. Именно для отправки сообщений о подобных изменениях и нужна шина данных

Я понимаю зачем нужна шина данных. Меня смутил в статье пункт про обмен файлами через общее хранилище данных

Это один из паттернов возможных обменов. Например, недоступна шина, сервисы живут на одном физическом сервере или имеется особый характер данных, скажем вы выгружает видео файл и передаёте его другому сервису.

Файл это просто носитель информации

В статье описано применение RPC, но что насчёт обычных REST запросов? То есть каждый микросервис имеет свои эндпоинты и другие микросервисы шлют на него запрос как на какой-нибудь удаленный сервис, не зная, что они находятся в "одной экосистеме". Большая ли разница в производительности, и может есть еще какие-нибудь подводные камни?

Разница между RPC и REST лишь в понятийной области. Вполне можно использовать REST, но обычно сложно уложить многообразие действий в парадигму REST, да и не особо нужно.

В нашем случае, да, у каждого сервиса свой набор эндпоинтов, которые вызываются другими. Другие сервисы, разумеется, знают в какой сервис они шлют запросы.

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

на правах ИМХО

REST он для внешних клиентов(наших пользователей, браузеров итд), не для внутренних

Внутренним лучше подходит именно RPC - меньше ограничений навязанных парадигмой и протоколом.

Ну Enterprise Service Bus бывают и вполне себе синхронные. А на случай изменения интерфейсов - версионирование. Видел такое в банке (там Оракл EA) и оно даже работало лет 10 назад.

Sign up to leave a comment.