Переход на микросервисную архитектуру

[shachneff]

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

P.S. Являюсь владельцем монолита, 6 лет промышленной эксплуатации в логистической компании, в мечтах о декомпозиции в микросервисы.

[BezrukovD]

Добрый день! Спасибо за внимание к нашей публикации. Постараюсь помочь Вам с этим вопросом в ближайшие дни.

[devopg]

да статья как в газете для всех.
ожидал схемы \ схемы \ архитектуры схем \ схемы )

[PaulIsh]

Казалось бы очевидный вывод, что не надо строгать 10 сервисов и ждать год. Соберите вместе 2 команды: монолита и микросервисов. Согласуйте api. Возьмите в работу обеими командами. Когда готовы сервисы проведите тестирование и доводку двумя командами.

[atomic1989]

Жаль, что не указали хотя бы причин. Это больше всего и волнует)

[revealyan]

Всегда интересовал вопрос про БД. Микросервисы подразумевают, что у каждого БД своя отдельная, но при таком подходе может нарушиться целостность данных из-за отсутствия тех же внешних ключей.

Собственно, какой подход вы применили/думаете принять(оставили одну БД, разделили без FK или ещё какое решение) и почему?

P.S. Хотел бы услышать ответы не только автора, спасибо)

[BezrukovD]

Добрый день! Спасибо за интерес.
Мы храним части сущностей в микросервисах, и только те части что нужны. В основном это ключи сущностей из мастер системы. Каждый сервис обогащает(или нет) эти ключи своим набором полей, специфичных для его доменной области

Например, сервис логистики получает офисы из профильного сервиса и обогащает своими данными, делая из безликих, не связанных офисов — логистические цепи компании.
Сервис курьеров — берет эти же офисы и навешивает на них расписания, тарифные сетки и прочие дополнения/ограничения

Синхронизация сервисов с мастер системой основана на эвентах, которые мастер система продьюсит. Все заинтересованные сервисы подписываются на эти эвенеты и в соответствии с ними добавляют/изменяют/удаляют данные о связанной сущности у себя в бд.
p.s. с ответом помог один из наших лучших архитекторов :)

[VolCh]

Обычно базы разделяют и FK только на уровне сервиса. Например у order_item.order_id есть FK на order.id, а у order.customer_id нет, только значение. Если сервису заказов нужно больше информации о клиенте, то или делает запросы к сервису клиентов (простой, но не оптимальный по многим метрикам способ) или хранит локально свою (неполную) копию как-то (обычно через mq, kafka и подобные сервисы в роли шины) синхронизируя её с сервисом клиентов.

[BezrukovD]

Добрый день!
На данный момент команда по микросервисам — 10 человек. Ребята разбиты на маленькие команды в зоне ответственности каждой из которых своя группа микросервисов.

Больших монолита у нас два, команды на них 50 — 60 человек на каждом.
С точки зрения реализации нового функционала на микросервисах, мы получили кратный прирост в скорости разработки. Тем не менее сама интеграция микросервисов и монолитов занимает существенное время, плюс сопутствующие рефакторинги на самих монолитах — все это несколько нивелирует полученный прирост в скорости разработки.
Но мы понимаем что это нормально для своего рода переходного периода и готовы к этому. Основной профит мы получили в быстродействии работы систем и повышения их масштабируемости. Кое-какие данные скину чуть позднее, ответом на один из комментариев выше.