Comments 11
Сложнее обеспечить гибкую отказоустойчивость, быстродействие и масштабирование.
Хм, а в чем сложность-то? Вроде горизонтальное масштабирование, и отказоустойчивость делается плюс-минус одинаково, что для мелких микросервисов, что для крупных, что для монолитов. Наоборот, если нарезать слишком мелко, то можно легко нарваться на необходимость в распределённых транзакциях и вот тут уже проседает быстродействие и появляется геморрой.
При чтении статьи возникла мысль, что самое правильное разбиение приведенной функциональности на микросервисы — оставить её в покое, и не пытаться её пилить пока в этом не возникло необходимости.
Сложности с определением точек разделения, по опыту, говорят в первую очередь о недостатке информации, то есть о преждевременности распила.
Стоило бы дождаться пока потребности себя проявят, и пилить после этого по уже понятным лекалам.
Самая большая трудность при распиле будет заключаться в разделении данных, поэтому по возможности стоит избегать возникновения связей в подозрительных местах.
да, только дело в том, что в живых проектах потребности, как правило, постоянно растут и видоизменяются. Тут главное не пересидеть — пока будем ждать промежуточного или окончательного устаканивания потребностей (которого может и не произойти), техдолг будет всё расти и расти, увеличивая сложность и стоимость требуемого рефакторинга
Так и есть, однако не стоит сбрасывать со счетов, что выбор неверных точек разделения на начальной стадии проекта приводит к бо́льшим трудозатратам на протяжении всей жизни проекта, ну и при рефакторинге появится необходимость сливать части системы, а не только разделять их.
Я эмпирическим путём пришёл к тому, что для крупного рефакторинга нужно не менее 3 сценариев, не укладывающихся в исходную архитектуру, иначе очень велик риск неверного обобщения.
естественно, если всё работает — ничего не трогай ) работает в плане стабильного time-to-market и качества при внесении изменений. В данной статье как раз и постарался выделить сигналы и моменты, когда пора не только разделять, но и объединять сервисы.
Про более общую тему рефакторинга архитектуры микросервисов (а не только про объединение/разделение) я говорю в следующем докладе (пока в открытом доступе есть только описание и слайды), надеюсь в будущем так же его опубликовать на хабр
мне всё таки кажется, что важный момент ещё кадровый. Сомнительная идея делать по 10 микросервисов на одного программиста (и я такое видел)
Опыт команды безусловно важен, я его и упоминаю во внешних факторах, которые необходимо учитывать. При этом вовсе необязательно, чтобы все разработчики были синьорами: при высоком уровне инфраструктуры добавление нового микросервиса сводится только к программированию бизнес-логики, и в случае мелкой гранулярности эти несколько строк кода легко можно поручить и менее опытному коллеге.
На мой взгляд, нельзя сказать что 10 сервисов на человека или 10 человек на сервис — плохо, опять же оптимальность соотношения будет зависеть от многих факторов. Главное избегать жесткой привязки: что конкретный микросервис знает и изменяет только конкретный разработчик, т.е. 20 микросервисов на двоих лучше, чем 10 на каждого. На некоторых проектах у нас примерно такое соотношение и получается (~40 микросервисов на 4 бэкенд разработчика)
Вопрос по пункту
2. Отделение бизнес‑логики от данных и состояния. Это принцип из классического программирования. Если сервис является мастер‑системой, то он отвечает за хранение данных, их обновление и предоставление доступа к чтению. Не нужно в тот же сервис вмещать бизнес‑логику, лучше её вынести в отдельный микросервис.
То есть предлагается извлекать данные из бд одним микросервисом, а потом полученные данные передавать другому микросервису, который реализует бизнес-логику?
Но микросервис - это же в общем случае полнофункциональное приложение и при необходимости вполне логично, что он извлекает данные из бд, потом применяет к ним алгоритмы бизнес-логики и результат отдаёт консюмеру, который сделал запрос. Не совсем понятно зачем бизнес-логику вынести в отдельный микросервис.
постараюсь выделить несколько причин:
- потребителями одних и тех же данных могут быть несколько разных бизнес-логик;
- нагрузка и ресурсоёмкость операций извлечения и обработки данных обычно разные. В случае совмещения, мы не сможем смасштабировать, к примеру, только операции обработки данных;
- оба пункта выше являются конкретными примерами возможных проблем нарушения базового принципа единственности ответственности
- потребителями одних и тех же данных могут быть несколько разных бизнес-логик;
Это вопрос многослойности приложения. Данные из бд извлекаются при помощи persistence layer, который могут использовать разные микросервисы. А доменная логика у каждого микросервиса своя.
Мне интересна сама логика работы консюмера в вашем примере. Чтобы выполнить один use case консюмер вначале обращается к микросервису, который извлекает данные из бд,
а потом полученные данные консюмер передаёт в другой микросервис, который реализует доменную логику этого use case? Правильно понимаю?
Гранулярность микросервисов. Насколько мелко нарезать?