Микросервисы -> подход к фичам/PRs от разных команд к вашему сервису?
Всем привет. В своей работе столкнулся вот с какой штукой. В лайве >500 микросервисов. За каждой группой сервисов (3-10) закреплена команда.
Допустим, есть фича - её нужно "провести" через, допустим, три сервиса. Есть два пути реализации :
1) команда, которой нужно сделать свою локальную "фичу" - разбивает задания между "своими" и они делают во все три репозитория пулл-реквесты с нужными изменениями
2) команда разбирается в каких сервисах нужно сделать ченджи и какие - перекидывает эти требования в три команды, где уже сами владельцы сервисов пилят функционал, нужный другим командам.
3) гибрид #1 и #2, в зависимости от загрузки - владельцы микросервисов могут "дать совет" как делать, если это возможно и ждать PR, либо решить, что лучше они сам это сделают, но позже - т.е. решает "принимающая" сторона, но базово, если команда не загружена - делают изменения сами владельцы сервисов.
Почему возник такой вопрос : у нас используется подход #1. Имхо - это боль и страдания. Притом для всех.
а) для тех, кому нужна "фича" - им каждый раз нужно "выкачивать" чужие репы, стараться понять как там организован код и тесты, читать архитектуру (что не все могут), всё это запускать как-то и тестировать локально, потом напрягать команду - овнера, чтобы они ревьювнули - они тоже тратят обычно много времени чтобы объяснить, что нужно бы вот так и почему.
б) те, кто овнят сервисы - невозможно "стоять насмерть" против "так себе пулл реквестов". Это те, которые работают, но в идеале, допустим, нужен рефакторинг - но это нереально сделать ни в рамках этого пуллреквеста, ни часто в рамках конкретного пулл реквестера - ему просто не хватает скилла. В итоге имеем то что имеем - часто грязный код, на чистку и поддержку которого уходят силы самих овнеров, а потом и тех, кто делает новые PR'ы.
Всё это приводит к полному рефакторингу через какое-то время. И хорошо если приводит. Т.е. в минусе - все. Плюс - кому фича нужна, тот и масштабирует кол-во сил, вброшенных в неё - удобно. Но по итогу - даже среднесрочно - это не окупается. Гайдлайны, ранбуки, стандартизация репозиториев и подходов помогает лишь очень частично, т.к. по итогу - каждый пишет чуть по-другому и под свои команды. Был реальный кейс, когда в бэкендовый сервис пришёл с фичёй человек из фронтенда (сервис на nodejs) - сделал pr, который в целом работает, но архитектурно - это небольшой ад. Все закрыли глаза, т.к. токсиком никто особо и не хочет быть - вы сами понимаете. В итоге через полгода саппортать это уже было невозможно и был полный рефакторинг под стиль команды и "рядом стоящих" сервисов.
И мне очень интересно, есть ли тут люди, которые работают в подполье >50 микросервисов + разные команды и юзают #2 или #3 подходы.
Может есть ссылочки на хабр/зарубежные ресурсы с дискуссиями? Был бы благодарен.
почему одна фича может затрагивать более одного микросервиса? кто является клиентом этой фичи с точки зрения инфраструктуры? можете привести какой-то реальный пример?
@zhainar
>почему одна фича может затрагивать более одного микросервиса
допустим нужно что-то на фроне поменять. оно тянет смену формата данных. данные тянутся через бэк фронта и сервис данных (где, допустим +1 поле запросить нужно например)
Т.е. уже 3 сервиса (фронт, апи1, апи2-dal уровня). Первые два обычно в рамках одной команды (не всегда), а третий уже точно под data тимой скорее всего.
>кто является клиентом этой фичи с точки зрения инфраструктуры?
не очень понял, но видимо фронт. изменения ему нужны, бэки лишь "подстраиваются" и допиливаются
если честно, то не был в такой ситуации. Если были нужны какие-то поля, то они всегда создавались в наших сервисах, а не в сервисах овнеров. В чужие сервисы редко лезли, потому что они выдавали полную информацию, а как использовать эти данные решалось на нашей стороне. Не могу сказать как вам точно помочь, тут нужно сидеть и разбирать архитектуру и области ответственности подробнее. Возможно вам нужен более опытный коллега в команде.
Простой
Простой
Простой
