Как управлять отношениями «многие ко многим» в архитектуре микросервисов?

Question

Если у меня есть следующие сущности на двух отдельных микросервисах:

class Employee {
@Id
private Long employeeId;

private String name;
...
}

class Department {
@Id
private Long deptId;

private String name;
...
}

Как я могу добавить отношение многие ко многим между сущностями?

Я думал объединить две сущности водин объект на шлюзе:

class Empl_Dept{
List<Long> employeeIds;
List<Long> departmentIds;
}

, поэтому таблица соединений будет на стороне шлюза.

Есть ли лучшее решение ??

Answer 1

Если у вас правильно смоделированы домены, это кажется простым исправлением с помощью событий интеграции.

Добавьте таблицу EmployeeIds к вашей службе департаментов и таблицу DepartmentIds к вашей службе сотрудников. Когда вы делаете, нарушаете или изменяете назначение между Employee и Department, публикуйте событие EmployeeDepartmentUpdated, на которое подписываются обе службы. Затем каждая служба может обработать событие и обновить свои собственные данные для синхронизации.

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

Охватите Окончательная согласованность и ваш путь к микросервисам будет для вас лучше!

РЕДАКТИРОВАТЬ:

На ваш вопрос о влиянии событий на производительность и сложность, ответы «нет» и «да».

Во-первых, нет, я бы не ожидал, что использование событий будет иметь негативное влияние на производительность системы. Фактически, их асинхронный характер делает обработку событий отдельной задачей от отзывчивости API.

Я уверен, что есть способы построения сервис-ориентированной архитектуры (SOA, микросервисы которой по существу являются подмножеством) без плоскости обмена сообщениями. , но, по моему опыту, наличие одного из них - фантастический способ обеспечить слабосвязанную связь.

Любые прямые вызовы между службами - независимо от протокола (HTTP, gRPC и т. д.) означают тесную связь между этими службами. Имена конечных точек, аргументы и т. Д. - это все возможности для прерывания изменений. Когда вы используете обмен сообщениями, каждая служба отвечает за отправку обратно-совместимых событий, а каждая другая служба может выбирать, какие события она заботит, подписываться на них и никогда не знать, работает ли отправляющая служба, не работает ли она, изменена и т. Д.

На ваш второй вопрос ответ «да» - обработка событий - дополнительная сложность. Однако это часть сложности, на которую вы подписываетесь (и далеко не худшая), когда выбираете стиль архитектуры микросервисов. Распределенная авторизация, поддержание работоспособности пользовательского интерфейса с несколькими внутренними вызовами, организованными между несколькими службами, отказоустойчивость и мониторинг работоспособности / производительности - все (по крайней мере, по моему опыту) большие проблемы.

Для записи мы используем хостингэкземпляр RabbitMQ из CloudAMQP.com и он прекрасно работает. Производительность хорошая, у них есть множество масштабируемых пакетов на выбор, и у нас не было проблем с производительностью или простоем. Последний выпуск RabbitMQ 3.8 теперь также включает в себя OAuth, поэтому в настоящее время мы работаем над интеграцией наших потоков Authz с нашим брокером сообщений и будем иметь хорошее комплексное решение для обеспечения безопасности.

Answer 2

1. Я предполагаю, что эта карта много-много требуется в третьем микросервисе. Тогда очень просто создать таблицу сопоставления между сотрудником и отделом
2. Если у вас есть только эти 2 микросервиса, вам придется добавить employee_department_map в одну службу и department_employee_map во вторую службу.

При проектировании микросервиса всегда учитывайте, что вы не можете ничего изменить в другом сервисе (скажем, если это API стороннего производителя)

Answer 3

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

Вы можете рассмотреть один из этих двух подходов, если Empl_Dept является объектом Domain, вы должны поместить егов третьем микросервисе, если он не помещает отношение сотрудников в отдел и наоборот.

Надеюсь, это поможет.