Определение границ микросервиса

Question

Я начал изучать и строить проект на основе микросервисов, но я всегда останавливался в ситуации, связанной с определением объема работ, и в конечном итоге создавал своего рода монолит. в приведенном ниже примере с foo-bar предложите, какой должна быть область видимости и как достичь желаемого результата.

Услуги или таблицы

• Сотрудники
• Отдел
• Сотрудник-Отдел-Сопоставление

Допущение

Employee или Department не имеет перекрестных ссылок друг на друга, все отношения поддерживаются в 3-й таблице Employee-Department-Mapping Связь может быть One-To-Many или Many-To-Many в зависимости от бизнеса, в этом примере это One-To-Many (Отдел с сотрудником)

Требование

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

Select d.DepartmentName, SUM(e.salary) 
from Employee e, Department d, Employee-Department-Mapping c 
where d.DepartmentName == c.DepartmentName 
AND e.Employee == c.Employee 
Group By c.DepatmentId 

ограничения

• таблица сотрудников содержит информацию о зарплате
• отношения сотрудников и отдела поддерживаются третьей таблицей.

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

Answer 1

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

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

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

Answer 2

Границы микросервисов - если у вас нет других причин масштабируемости - должны определяться бизнесом. И в этом конкретном случае - не зная каких-либо других требований - я бы сказал, что вам следует go для одного микросервиса, который управляет этими двумя объектами. Сказав, что у меня достаточно опыта, чтобы знать, что в реальном мире это решение не всегда осуществимо и возможно. К счастью, есть несколько шаблонов, которым вы можете следовать, чтобы исправить описанную вами ситуацию. Например, CQRS может быть решением https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing.