Какого размера должен быть микросервис
Хотя «микросервис» стал популярным названием для одноименного архитектурного стиля, его название приводит к ложному пониманию о размере сервиса и спорам о том, что же значит «микро». Зачастую любое небольшое приложение разработчики называют микросервисом.
В статье я хочу ответить на вопрос о размере микросервиса, опираясь на свой опыт и опыт крупных компаний.
В статье я хочу ответить на вопрос о размере микросервиса, опираясь на свой опыт и опыт крупных компаний.
Популярные версии
В разных источниках можно встретить разные мнения по поводу размера микросервиса:
- Это сервис, в котором не должно быть больше 10k строк кода
- Сервис такого размера, что его можно переписать на другой язык за 2 недели
- Сервис такого размера, что его может поддерживать команда из 2 пицц
- Сервис такого размера, что 1 человек в состоянии осознать все приложение полностью
- Сервис должен полностью реализовывать свою бизнес-функцию, быть автономным, а размер не так важен
Two Large Pizza team
Очевидные ошибки в размере
На практике я видел такие кейсы:
Ни первый, ни второй случай не позволяют достичь основных преимуществ применения микросервисной архитектуры, следовательно с размером что-то не так.
- Команда из 6 человек развивает 20 микросервисов. И зачастую такая команда работает неэффективно, так как инфраструктурные издержки на разработку, координацию и выкладку 20 микросервисов съедают большую часть их времени.
- Система разбита на сервисы настолько мелкозернисто, что ни один из сервисов не отвечает полностью за определенную бизнес возможность. Это приводит к излишним коммуникациям между сервисами. Изменять, проводить рефакторинг, тестирование таких сервисов становится все труднее. В итоге это также негативно влияет на систему.
Ни первый, ни второй случай не позволяют достичь основных преимуществ применения микросервисной архитектуры, следовательно с размером что-то не так.
Итоги
Учитывая выше сказанное, мы можем сделать вывод, что физический размер сервиса имеет далеко не первостепенное значение. По этим критериям определять размер микросервиса не стоит:
Но крайне важно, чтобы сервис был автономным, самодостаточным и реализовывал полностью определенную бизнес возможность, он может быть совсем не маленьким, но такого размера, что его может эффективно развивать команда из 5-9 человек. При этом команда не должна владеть больше чем 1-2 сервисами. Написать огромный монолит таким составом крайне проблематично, поэтому размер команды не явно определяет размер микросервиса.
- Это сервис, в котором не должно быть больше 10k строк кода
- Сервис такого размера, что его можно переписать на другой язык за 2 недели
Но крайне важно, чтобы сервис был автономным, самодостаточным и реализовывал полностью определенную бизнес возможность, он может быть совсем не маленьким, но такого размера, что его может эффективно развивать команда из 5-9 человек. При этом команда не должна владеть больше чем 1-2 сервисами. Написать огромный монолит таким составом крайне проблематично, поэтому размер команды не явно определяет размер микросервиса.
Размер команды не явно определяет размер микросервиса.
Если члены команды все больше и больше понимают, что не осознают размеров сервиса, который они развивают — это также является той гранью, когда сервис достиг своего максимума и его необходимо декомпозировать.
Понравилась статья? Поделись в соцсетях!