Эксперт расскажет об опыте компании CUSTIS по разработке приложений на основе микросервисной архитектуры, рассмотрит примеры, где целесообразно её использовать, а в каких проектах этого лучше не делать.
В начале 2010-х годов микросервисная архитектура произвела настоящий фурор в области разработки ПО. Тогда казалось, что найден идеальный рецепт для решения проблемы неповоротливости громоздких приложений, когда любое новое требование выливалось в месяцы работы.
Но у микросервисов, как и у любого другого подхода, оказались свои плюсы и минусы, своя область применения. В этой статье я расскажу об опыте компании CUSTIS по разработке приложений на основе микросервисной архитектуры, рассмотрю примеры, где целесообразно её использовать, а в каких проектах этого лучше не делать.
Плюсы и минусы монолита и микросервисов
Микросервисная архитектура предполагает построение приложения как ряда частей, которые разворачиваются независимо друг от друга. Ключевой характеристикой такой архитектуры является её модульность: мы можем заменить любую часть системы, не оказывая влияния на другие её части. Противоположностью микросервисов является монолит — приложение, которое можно развернуть только целиком. При этом у каждого из этих подходов есть преимущества и недостатки.
Ресурсоёмкость
Главный минус микросервисов — необходимость выделения дополнительных ресурсов при работе с ними. Команде требуется значительное время на то, чтобы грамотно разграничить бизнес-области, выделить API, поднять инфраструктуру, которая позволит управлять разворачиванием сервисов и т. п. При разработке монолита затраты на это, как правило, ниже. Однако в долгосрочной перспективе грамотно спроектированные микросервисы позволят легче и дешевле вносить изменения в систему. В ряде случаев для доработок нужно будет погрузиться в работу только одного модуля, что снизит порог входа для новых членов команды.
Параллельная работа
Работу над приложениями в микросервисной архитектуре легче распараллелить. Над каждым микросервисом может трудиться специально выделенная команда, за счёт чего возможно сокращение общих календарных сроков проекта. В монолите же вероятность того, что при параллельной работе разработчики будут мешать друг другу, выше, например, если они меняют один и тот же код.
Использование под разные проекты
С точки зрения вендора преимущество использования микросервисов состоит в том, что разные части такого приложения могут быть легко заменены под разных клиентов. Например, если двум компаниям необходимы принципиально разные бизнес-процессы в области Х, то вендор напишет два принципиально разных микросервиса, у которых будет одно API, но индивидуальная реализация. Кстати, сами заказчики также могут дорабатывать приложение, заменяя его части.
Взаимодействие частей системы
В микросервисах описание API позволяет верхнеуровнево смотреть на приложение и понимать, как его части взаимодействуют друг с другом. При этом API должно быть универсальным и подходить для реализации разных бизнес-процессов, а его проработка, как правило, требует дополнительных трудозатрат. А ещё могут возникнуть сложности с поддержкой сразу двух API при внесении изменений. В данном случае у работы с монолитом есть преимущество: лёгкое изменение взаимодействия разных частей системы, поскольку они связаны через вызовы функций, а не через API.
Разделение областей ответственности
При работе с микросервисной архитектурой важно делать чёткое разграничение областей ответственности между модулями. Без этого мы получим сетевой монолит, который с микросервисами будет иметь сходство лишь в необходимости разворачивания его частей по-отдельности. В хорошо декомпозированном приложении изменения при решении задач вносят, как правило, только в одну его часть.
В случае с монолитом можно пренебречь разделением его на части, однако это выльется в сложность доработки, когда изменения в одной из функций могут приводить к последствиям в совершенно неожиданных его частях. В этом плане микросервисы легче поддерживать и дорабатывать: в ряде случаев для понимания работы одного из модулей достаточно погрузиться только в его работу, а не приложения целиком.
Технологическая гибкость
С технологической точки зрения архитектура микросервисов позволяет легче внедрять новые технологии, например фреймворки или языки программирования. В случае монолита внедрение может быть затруднено, если это потребует большого объёма работ...