Я создаю новое приложение и читал об архитектуре микро-сервисов. Сама архитектура имеет большой смысл с точки зрения разработки, развертывания и управления жизненным циклом. Однако возникла одна проблема, связанная с обработкой основных данных.
Например, у меня есть 2 приложения - например, приложение «Продажи» и приложение «Продажа билетов». Предположим, что оба эти приложения созданы как собственные микро-сервисы. Однако оба этих приложения при развертывании (при условии, что они развернуты отдельно, скажем, Sales использует MongoDB, а Ticketing использует MariaDB), должны будут иметь доступ к одним и тем же экземплярам основных данных, например, «Счета», «Продукты». Это будет означать, что для данного объекта основных данных будет существовать приложение-владелец (например, для Учетных записей это может быть приложение «Продажи») и заинтересованная сторона (например, приложение «Билетная заявка» должно иметь информацию об Учетных записях).
Это может быть достигнуто несколькими способами: - репликация данных от мастера к заинтересованной стороне - синхронное чтение от заинтересованной стороны к мастеру (зависимость от синхронизации не рекомендуется парадигмой архитектуры микросервисов) - собственный централизованный репозиторий
Также даже в рамках Учетных записей может существовать основная часть, которая является общей как для Продаж, так и для Билетов (например, имя учетной записи, адрес и т. Д.). Однако некоторые аспекты Учетной записи могут быть ТОЛЬКО релевантными для продаж, а другие - ТОЛЬКО для продажи билетов.
Какие-нибудь мысли / лучшие практики / мнения относительно любого из вышеупомянутых вариантов?
Ответы:
Я был частью команды, которая успешно построила архитектуру микросервисов, используя служебную шину.
Первоначально мы полагали, что микросервисы и управляемая событиями архитектура позволят нам исправить основную общую базу данных общих данных.
Мы узнали, что микросервисы и управляемая событиями архитектура требовали от нас избавления от лежащей в основе базы данных общих данных.
Я считаю, что с микросервисами невероятно сложно делиться общими данными - для меня это непомерно сложно. Я рекомендую не разрешать сервисам видеть данные друг друга. Если вы не можете запросить его, вы не можете случайно ввести зависимость.
Если вы делаете данных о проценте, конечно , только одна услуга может когда - либо СВОЯ запись; это единственный сервис, который пишет в запись, и любые другие пользователи с такими же данными должны иметь доступ только для чтения.
К сожалению, даже этот небольшой управляемый объем обмена обеспечивает существенную связь между вашими услугами. Что делать, если один сервис не хочет данных в этой форме? Возможно, он хочет агрегации. Получаете ли вы свой сервис «владелец / запись» для записи совокупных данных в пользу другого сервиса? Я бы посоветовал нет.
Что если владелец хочет сохранить данные в другой форме? Тогда каждый сервис чтения должен быть обновлен. Это кошмар обслуживания.
Нашим лучшим решением было значительное дублирование и денормализация наших данных. Микро-сервисы сохраняли свои собственные копии данных, о которых они заботились.
Сообщения часто публиковались с достаточным количеством сопроводительных данных для их обработки.
Например, вы можете представить, что службе почтовой отправки может потребоваться отслеживать изменения в адресе клиента, в случае, если ему необходимо что-то опубликовать. Но если ваше сообщение «товар готов к отправке» включает в себя адрес пункта назначения как часть данных сообщения, тогда службе отправки больше не нужно отслеживать изменения адресов, связанных с клиентами; просто адреса на определенный момент времени, относящиеся к элементам по мере их отправки.
Я не могу предложить, как разрабатывать решения с синхронизированными данными. Наши решения для обработки данных были основаны на идее «возможной согласованности».
Поэтому, когда клиент обновляет свой адрес, служба адресов обрабатывает начальную команду из пользовательского интерфейса. Как только его данные верны, он публикует событие для уведомления всех других заинтересованных служб «Адрес клиента обновлен» - с полным адресом, прикрепленным в качестве данных. Эти сервисы будут обновлять свои собственные хранилища данных теми частями данных, которые им нужны.
Идея состоит в том, что каждый раз, когда службе требуется предпринять какое-либо важное действие, она должна иметь копию обновленной информации, достаточной для того, чтобы действовать правильно, либо отслеживаться независимо, либо как часть сообщения, на которое она отвечает.
источник
Совместное хранение данных будет противоречить архитектуре микросервиса. Дело в том, что если есть Учетные записи, должна быть служба для их обслуживания, и не должно быть другого способа взаимодействия с этой Учетной записью, кроме тщательного обслуживания. Ваши микросервисы не были бы независимыми, если бы они совместно использовали общее хранилище, и любые изменения в механизме хранения, валидации или других ограничениях должны были бы быть реализованы в обеих службах. На практике это никогда не происходит и вскоре приводит к тому, что оба приложения не могут быть подвергнуты серьезным изменениям.
Таким образом, используйте сервис в качестве единственного способа доступа к вашим данным, например, учетные записи. Может случиться так, что для реализации функции в каком-либо другом сервисе требуется изменение сервиса учетных записей, и это нормально. Просто помните, что логика, специфичная для любого сервиса, должна быть в этом сервисе, и как можно меньше специфических вещей должно попадать в микросервис Accounts.
источник
Не то же самое. Каждый микросервис должен выполнять свое собственное сопоставление для учетных записей, продуктов и т. Д. Мы предполагаем, что у каждого микросервиса будет свой способ работы с объектами.
В доменно-управляемом дизайне это распространено, когда каждый ограниченный контекст (в одном приложении!) Может отображать одну и ту же сущность по-своему.
Если вам нужна дополнительная информация, я рекомендую книгу « Создание микросервисов: проектирование мелкозернистых систем».
источник
Рассматривали ли вы концепцию скелетных записей на основе мастер-сета?
Например, один микросервис обрабатывает учетные записи, а другой - продукты. Третий может хранить записи из обоих в своих конкретных целях домена.
источник