Комментарии 11
Отлично. Теперь вместо жесткой гарантии получения данных мы получили слабое связывание и отстутствие гарантий вообще. Для страничек в интернете - прекрасно. Для финансовой системы немедленная смерть. (Да есть паттерны типа event sourcing, но они настолько сложны в разработке... и избыточны в большенстве случаев)
Вот пример - синий сервис требует данные фиолетового и они на pub/sub. От фиолетового ничего не пришло. Это он лежит? Это ничего не случислось? Или еще: все то-же самое, но от фиолетового пришло. Ура? А это точно последние данные? Ах там таймстамп-же есть? Ну и что - обновиться через милисекунду оно все равно могло.
Вот и получаются гибридные pub/sub и request/response. А там не только все плюсы, но и все минусы обоих.
Нет счастья. Надо думать над каждой связью.
Не согласен. На такой случай придумали Saga. Да, Saga не совсем простая, но она позволяет построить в купе с машиной состояний отличную связку с откатом транзакции.
Без машины состояний или иной технологии с отменой данный метод не стоит применять и применим он не везде, но ниша его может быть достаточно обширной. Например, можно реализовать оплату покупки через Saga + MassTransit
Подход так себе. Мы так задублируем урезанный склад в заказах со всемы вытекающими проблемами.
База склада пухнет - придется держать всю инфу по связанным сервисам.
Неактуальные данные - количество на складе отстает на время обработки consumer.
Связанные данные (например поставщик) которые раньше тянулись через graphql недоступны либо их придется тянуть всегда и держать у себя (опять же причина того что база пухнет).
Модификация данных (надо поле добавить или поменять) превратится в пляски с бубном для синхронного обновления всех связанных баз.
Пробросить доп поле в заказ птребует модификации базы.
Я бы сказал предложенное решение очень спорное и применять надо ссильно подумава, а надо ли нам это.
Если автор (не переводчик) предлагает Pub/Sub + кеширование, то решение не ново. Имеет массу подводных камней и по подпискам и по валидации кеша.
Не понятно, почему сфокусировали на микросервисах если проблема классическая для любого веб-приложения: Pub/Sub + кеширование на клиенте.
Я сознательно сделал одну большую систему на REST и не жалею. У каждого подхода есть свои недостатки к которым можно сделать соответствующие подпорки. Например, в критичных местах прописать механизмы повторных запросов.
Более того, на рынке даже существуют специальные готовые сетевые решения, которые решают проблему обрывов, например Istio для докера.
Асинхронные сообщения я тоже использую, там где скорость достижения согласованности не принципиальна.
Было бы более грамотно всё-таки более непредвзято посмотреть на обе альтернативы и описать плюсы и минусы каждой.
Все эти танцы с перекладыванием ответственности с одного сервиса на другой всегда ведут к одному и тому же - к неэффективности. К счастью для начинающих "архитекторов" владельцы бизнесов ни в зуб ногой в этих ваших брокерах, а потому легко выделяют огромные бюджеты на то, что наблюдали в соседнем бизнесе, а там такой же "архитектор" сочинил такое же перекладывание ответственности. Ну и распространяется эта волна бессмысленного раскладывания по очередям на весь мир.
Либо у вашего бизнеса есть нормальный архитектор, и тогда у вас всё быстро, дёшево и надёжно, либо вы наняли модного "архитектора", делающего "как у всех", и тогда ваши затраты увеличиваются на порядок в сравнении со случаем, где есть нормальный архитектор.
Ну да не будем мешать бизнесу сливать деньги акционеров. Благо, чем больше они сольют, тем больше айтишников останутся довольными.
Вернемся на шаг назад. Почему же Blue, чтобы справиться с поставленной перед ним задачей, нужно стабильно получать данные от Purple? В соответствии с Постулатами сервис-ориентированной архитектуры (SOA), каждый сервис должен быть автономен.
Может быть Blue, не может справиться с поставленной перед ним задачей, без данных от Purple,потому что функциональность не правильно разделили между микросервисами?
Получается: нарушили
Постулат сервис-ориентированной архитектуры (SOA): каждый сервис должен быть автономен
и пытаемся выкрутиться, может просто не надо было нарушать?
Странно, что используются постулаты SOA в микросервисах... Это же разные подходы. Но избежать тут сложно, по крайней мере в микросервисах, допустим у вас есть сервис конвертер валют и сервис цен, и тут для того, чтобы вернуть пользователю цену в нужной валюте как раз нужна зависимость между сервисами, вопрос какая она будет (синхронная или асинхронная) но так или иначе зависимости между микросервисами есть практически всегда, тут важно знать меру и смотреть насколько сильно разрастаются зависимости.
А как поддерживать актуальность данных в Fulfilment без временной связности? Допустим развернули сервис пуляем первый запрос оказывается что в локальном хранилище нет инфы по запрошенному товару, что дальше? Идем на склад за инфой? Через брокер? Почему не сделать синхронный запрос ведь информация нужна здесь и сейчас. Я не помню как в предложенной реализации решить эту проблему. Предполагается делать БД в двух экземплярах для Fulfilment и для Warehouse, или как?
Пример в статье по обмену сообщениями имеет место быть, но как заметили комментаторы данный пример весьма плох в реализации.
Сервис Fulfillment занимается выполнением заказа. Вот только остаётся непонятным почему этот сервис вдруг стал решать может ли он что-то взять со склада.
Тут не хватает бизнес логики, а именно: 1. при создании заказа мы должны зарезервировать товар на складе, если это возможно 2. при положительном резервировании заказ подтверждается. 3. при не возможности резервации товара заказ отклоняется.
В соответствии с этими требованиями, сервис Fulfillment при получении заказа должен опубликовать сообщение, что заказ был создан, а самому заказу необходимо добавить статус "в обработке". Сервис Warehouse подписывается на это сообщение и проверяет у себя может ли он зарезервировать товар. Если товара достаточно на складе, то публикуется сообщение, что заказ был зарезервирован. На это сообщение уже подписан Fulfillment и при получении его меняет статус заказа на "обработан". Если Склад не может подтвердить заказ, он так же публикует сообщение, что заказ не может быть выполнен. А сервис по работе с заказами, получив это сообщение, должен сменить статус заказа на "отклонён".
При такой реализации мы не "таскаем" чужие данные из необходимых сервисов, что является слабой связанностью и автономностью. Решение о резервировании товара принимает только один ответственный микросервис, т.к. только он владеет этими данными. Можно "играть" с бизнес правилами. При сбоях в сети/шине данных/сервисах приложение остаётся работоспособным. Т.е. при не рабочем складе, мы можем получать заказы, а сообщения к складу придут позже, как он заработает, тут стоит оговориться, что только при условии если будет реализован механизм доставки сообщения как минимум один раз.
Микросервисы это инструмент, и любым инструментом необходимо уметь пользоваться. К сожалению данная статья показывает только то, что автор не разобрался с вопросом в полной мере.
REST API в микросервисной архитектуре