Я относительно новичок в микросервисной архитектуре. У нас есть веб-приложение умеренного размера, и я взвешиваю все за и против того, чтобы разбить его на микросервисы вместо монолитной системы, которую мы сейчас продвигаем.
Насколько я понимаю, рассмотрит microservices A
и B
каждый из которых полагается на подмножестве данных, а другие имеют. Если сообщение отправлено с сообщением о A
том, что что-то изменилось, B
можно использовать это сообщение и реплицировать локальную копию A
информации и использовать ее для выполнения любых B
задач.
Однако, что, если B
происходит сбой / сбой и через некоторое время возвращается снова. За это время A
опубликовал еще два сообщения. Как B
узнать, как обновить локальную копию A
информации?
Конечно, если он B
является единственным потребителем в A
очереди, он может начать читать его, как только вернется в оперативный режим, но что, если в этой очереди есть другие потребители и эти сообщения потребляются?
В качестве более конкретного примера, если у Users
службы обновляется адрес электронной почты, когда Billing
микросервис не работает, если Billing
микросервис возвращается снова, как он узнает, что электронная почта обновлена?
Когда возвращаются микросервисы, происходит ли трансляция с сообщением «Эй, я вернулся, дай мне всю свою текущую информацию?»
В целом, каковы лучшие отраслевые практики для синхронизации данных?
источник
Orders
нужно что-то знать оUsers
?Ответы:
Я бы поставил под сомнение всю вашу идею «передачи данных на все другие микросервисы».
Обычно, если платежной службе требуется адрес электронной почты, он просто запрашивает адресную службу для адреса электронной почты конкретного клиента. Ему не нужно хранить копию всех данных об адресе, и он не будет проинформирован, если что-то изменится. Он просто спрашивает и получает ответ из новейших данных.
источник
Проведя немного больше исследований, я наткнулся на эту статью, из которой я вытащил некоторые цитаты, которые, на мой взгляд, полезны для того, чего я хочу достичь (и для любых будущих читателей). Это дает возможность принять модель реактивного программирования вместо модели императивного программирования.
Event-источников
Это помогает достичь того, что если микросервис выходит из строя, а другие относящиеся к нему события публикуются, и события потребляются, скажем, другими экземплярами этого микросервиса, когда этот микросервис возвращается, он может обратиться к нему,
event store
чтобы получить все события, которые он пропустил за период, когда он пошел вниз.Apache Kafka как брокер событий
Рассмотрим использование Apache Kafka, который может хранить и отправлять тысячи событий в секунду и имеет встроенные механизмы репликации и отказоустойчивости. Он имеет постоянное хранилище событий, которые могут храниться на диске неограниченное количество раз и использоваться в любое время (но не удаляться) из темы (необычная очередь Кафки), в которую они были доставлены.
Фактически, когда потребители идентифицируют себя с Kafka, Kafka будет записывать, какие сообщения были доставлены тому или иному потребителю, чтобы он не доставлял его снова.
Саги
Это когда сага вступает в игру. Сага - это последовательность локальных транзакций. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие для запуска следующей локальной транзакции в саге. Если локальная транзакция терпит неудачу из-за нарушения бизнес-правила, тогда сага выполняет серию компенсирующих транзакций, которые отменяют изменения, сделанные предыдущими локальными транзакциями. Прочитайте это для получения дополнительной информации.
источник
Даже если я опоздаю, я бы поставил свои 2 цента на аргумент, потому что я думаю, что это важный момент, когда вы хотите оценить и разработать архитектуру управляемых событиями микросервисов. Каждый микросервис точно знает, какие события влияют на его состояние, и способен их ждать. Когда микросервис недоступен, должен существовать компонент, который хранит сообщения, необходимые от неисправного микросервиса, до тех пор, пока он не сможет их «потреблять». На самом деле это модель «производитель / потребитель», а не «публикация / подписка». Брокеры сообщений (такие как Kafka, RabbitMQ, ActiveMQ и т. Д.) Обычно являются наилучшим способом достижения такого поведения (если вы не реализуете что-то другое, например, получение событий), обеспечивая постоянные очереди и механизм подтверждения.
Теперь микросервис знает, что сообщение в конечном итоге доставляется, но этого недостаточно: каким образом он ожидает доставку одного сообщения? может ли он управлять доставкой нескольких копий одного и того же уведомления о событии? Это вопрос доставки семантический (хотя бы один раз, ровно один раз)
Последние мысли):
Когда вы добавляете микросервис в вашу архитектуру, которая должна получать события от других, вы должны выполнить первую синхронизацию
Даже брокер может потерпеть неудачу, в этом случае сообщения теряются
для обоих сценариев было бы полезно иметь простые механизмы для повторного увлажнения вашего состояния микросервиса. Это может быть REST API или скрипт, который отправляет сообщения, но самое главное - иметь средства для выполнения какой-либо задачи обслуживания.
источник
Вы можете заменить обычную очередь событий моделью издателя / подписчика, где
A
служба публикует новое сообщение темы T, аB
тип микросервисов будет подписываться на ту же тему.В идеале это
B
была бы служба без сохранения состояния, и в ней использовалась бы отдельная служба персистентности, так что сбойныйB
экземпляр службы был бы заменен созданием одного или несколькихB
экземпляров службы для продолжения работы, считывания из той же общей службы персистентности.источник
Если вы хотите, чтобы B мог получить доступ к внутренним данным A, вам лучше всего дать ему доступ к внутренним базам данных A.
Однако вам не следует этого делать, весь смысл сервис-ориентированной архитектуры состоит в том, что сервис B не может видеть внутреннее состояние сервиса A и ограничен в выполнении запросов через API REST (и наоборот).
В вашем случае вы можете иметь службу пользовательских данных, которая несет ответственность за хранение всех пользовательских данных. Другие службы, которые хотят использовать эти данные, запрашивают их только тогда, когда им это нужно, и не хранят локальную копию (что, кстати, действительно полезно, если вы думаете о соответствии GDPR). Служба пользовательских данных может поддерживать простые операции CRUD, такие как «Создать нового пользователя» или «Изменить имя для user_id 23», или может иметь более сложные операции: «Найти всех стандартных пользователей, у которых в ближайшие 2 дня будет день рождения, и дать им». Премиум пробный статус ". Теперь, когда вашей платежной службе нужно отправить электронное письмо пользователю 42, она спросит службу пользовательских данных «Какой адрес электронной почты для user_id 42», использует свои внутренние данные со всей платежной информацией для обработки электронной почты, а затем может передать адрес электронной почты и тело почтового сервера.
источник