Из статьи You're not actually building microservices
Итак, вы создаете микросервисы?
Взгляните на некоторые из этих симптомов и проставьте галочки, где вы согласны:
- Изменение одного микросервиса часто требует изменений в других микросервисах (сильная связанность)
- Развертывание одного микросервиса требует одновременного развертывания других микросервисов
- Наши микросервисы слишком болтливы (много общаются друг с другом)
- Одни и те же разработчики работают с большим количеством микросервисов
- Многие из наших микросервисов совместно используют хранилище данных
- Наши микросервисы имеют один и тот же код или модели
Если у вас есть хотябы одна галочка - у вас проблема... конечено, всегда есть исключения. Но по большей части, если вы киваете головой в некоторых из приведенных выше пунктов, возможно, вы не работаете с микросервисами.
Подробно в статье Is your microservice a distributed monolith? (2020) Вкратце: попробовать пошатать систему с "Chraos Engenering" подходом.
Если вы начинаете с монолита, ваша цель должна быть в том, чтобы не дать ему стать чудовищем.
Ключ к этому - просто слушать свое приложение!
Я знаю, что легче сказать, чем сделать, но по мере роста вашего монолита задавайте себе несколько вопросов:
- Есть ли что-нибудь, что масштабируется с иной скоростью, чем остальные части системы?
- Есть ли что-нибудь, что кажется «привязанным» к внешней части системы?
- Что-нибудь меняется намного быстрее, чем остальные части системы?
- Есть ли в системе часть, требующая более частого развертывания, чем остальные части системы?
- Есть ли в системе часть, внутри которой независимо работает один человек или небольшая команда?
- Есть ли подмножество таблиц в хранилище данных, не связанных с остальными частями системы?
По мере увеличения размера системы и количества разработчиков вы обнаружите, что разделение сервисов станет обычным делом.
Из статьи Segment's Goodbye Microservices
Некоторые проблемы с которыми вы столкнетесь в микросервисах по мере роста:
Чтобы облегчить бремя разработки и поддержки этих кодовых баз, мы создали общие библиотеки, чтобы упростить и сделать общими преобразования и функциональные возможности, такие как обработка HTTP-запросов, в местах использования проще и единообразнее.
...
Общие библиотеки ускорили создание новых направлений. Знакомство с единым набором общих функций сделало обслуживание менее проблемным.
Однако стала возникать новая проблема. Тестирование и развертывание изменений в этих общих библиотеках повлияло на все наши направления. На его обслуживание стали уходить много времени и усилий. Вносить изменения для улучшения наших библиотек, зная, что нам придется тестировать и развертывать десятки сервисов, было рискованным делом. При нехватке времени инженеры включали только обновленные версии этих библиотек в одном месте кода (single destination’s codebase).
Со временем версии этих общих библиотек начали расходиться в разных целевых базах кода. Огромное преимущество, которое мы когда-то получали, заключающееся в сокращении настройки каждой целевой кодовой базы, начало меняться. В конце концов, все они использовали разные версии этих общих библиотек. Мы могли бы создать инструменты для автоматизации развертывания изменений, но на этом этапе не только снизилась производительность труда разработчиков, но и мы начали сталкиваться с другими проблемами с микросервисной архитектуры.
По моему опыту, самым большим преимуществом микросервисов является разделение команд. В монолитном приложении очень сложно поддерживать продуктивность разработчиков, поскольку количество разработчиков увеличивается, а унаследованный код накапливается. Разделение сервисов и предоставление каждой команде разработчиков контроля над собственными кодовыми базами позволяет им разрабатывать собственные продукты в своем собственном темпе.
Если у вас всего одна команда разработчиков, микросервисы будут намного менее привлекательными. Тем не менее, все же есть некоторые преимущества, такие как возможность изолированного рефакторинга частей вашей кодовой базы (включая, возможно, переписывание их на разных языках) и возможность индивидуально настраивать масштаб времени выполнения различных частей вашей кодовой базы.