Какого размера должны быть микросервисы?Несколько лет назад я
уже писала о своем опыте работы с MSA. Там про знакомство и взаимодействие аналитика с микросервисами. Сейчас опыта стало побольше и хочется поговорить про то, как размер сервисов влияет на разработку.
Название архитектурного паттерна как бы намекает, что сервисы в MSA должны быть небольшими. Но что значит небольшим? И в масштабах какой системы?
По
канонам, сервис может считаться микросервисом, если он соответствует основным принципам MSA:
- Он имеет чёткие границы и сферу ответственности,
- он независимо развертывается,
- у него своя база данных,
- он взаимодействует с другими сервисами через API.
То есть про размер ничего нет. Ни в большую, ни в меньшую сторону.
В рекомендациях часто косвенно связывают размер микросервиса с размером команды. То есть команда, разрабатывающая 1 (и в идеале только 1) микросервис, должна быть 6-12 человек
(правило 2х пицц). И, кажется, что это правило - результат сложного опыта и ошибок.
Иногда разработчики делают микросервисы настолько маленькими, что между ними возникает большая и разветвленная сеть APIs. Происходит много сетевых вызовов, сервисы ломают друг друга, команды много и неэффективно общаются между собой. То есть сервисы зависят друг от друга и мы получаем распределенный монолит. Хотя формально эти сервисы соответствуют принципам MSA, но фактически такая архитектура противоречит смыслу разработки микросервисов - она не избавляет систему от зависимостей, но увеличивает ее сложность за счет интеграций и инфраструктуры.
Бывают и обратные ситуации. В примерах микросервисов часто можно увидеть такие агрегаты, как Оплата, Заказ, Доставка, Склад и др.
При определенном масштабе системы такие бизнес-функции могут включать в себя много сложной логики.
Например, платежный микросервис будет содержать данные об оплатах, проверки транзакий, интеграции с платежными шлюзами, бухгалтерией, антифродом и пр. То есть на выходе получается не то чтобы “микро-” сервис.
И если с этим справляется одна двухпиццевая команда, то все отлично - сервис автономен, не сильно зависит от других сервисов и представляет сам по себе ценность для бизнеса.
Но системы имеют свойство развиваться. И в какой-то момент 12 человек уже может не хватать, чтобы поддерживать всю логику и контракты. Команда вырастет, незаметно для всех разобьется на подкоманды, каждая со своей зоной ответственности. Эти подкоманды начнут друг другу мешаться, долго разрабатывать и еще дольше деплоить. В результате получится мини-монолит в микросервисной шкуре.
Можно, конечно, попросить системных аналитиков держать всю эту махину под контролем. Но иногда и их ресурсов не хватает, чтобы осознать, запомнить и задокументировать весь контекст “микро-”сервиса. В таких случаях рекомендуют распиливать получившийся мини-монолит - скорее всего, образуя из подкоманд отдельные команды.
В общем, микросервисы это и так сложно, а тут еще приставка “микро-” сильно сбивает с толку.
Например, на одном моем проекте распределенную систему из “среднего” размера сервисов причисляли к SOA-паттерну. Хотя там не было ни ESB-шины, ни общих баз данных, ни централизованной оркестрации. По факту это была распределенная система из микросервисов и мини-монолитов, которые все вместе вполне отвечали принципам MSA.
По моему опыту все-таки лучше иметь дело с мини-монолитами, чем собирать слово “Вечность” из слишком мелких и сильно связанных микросервисов.
Многие эксперты тоже советуют “не мельчить”, например
здесь и
здесь.А с какими микросервисами вы сталкивались в своей практике? И как вам такой опыт?
