Что такое микросервисная архитектура и когда ее применять
Задумывались над тем, как в одном проекте могут совмещаться части на разных языках? Рассмотрим, что такое микросервисная архитектура.
Множество приложений, с которыми мы регулярно пересекаемся (интернет-банки, развлекательные сервисы вроде YouTube и так далее), часто созданы с использованием множества технологий, которые как-то уживаются под одной крышей и не выглядят разрозненно.
Что такое микросервисная архитектура
Микросервисы – это архитектурный шаблон. Все сервисы в этом шаблоне:
- Маленькие
Сервис не должен требовать множества людей для разработки. Одна команда может разрабатывать несколько сервисов. - Сфокусированные
Один сервис – одна задача. - Слабосвязанные
Изменения в одном сервисе не влияют на другой. - Высокосогласованные
Компонент или класс создаются с учетом всех методов решения бизнес-задачи.
Классическое монолитное приложение обычно имеет стандартную структуру Интерфейс -> Бизнес-логика -> Данные.
Микросервисы же отталкиваются от бизнес-логики:
Один сервис должен решать одну задачу и эти задачи определяются частями ответственности приложения. Например, могут существовать разные сервисы для команд, работающих в рамках одного проекта (допустим, онлайн-магазина).
Когда применяется
Обычно микросервисная архитектура применяется как один из вариантов масштабирования приложения. Всего таких вариантов может быть три:
- Sharding («разбиение» или просто «шардинг») – данные и инструменты для доступа к ним размещаются на разных узлах.
- Mirroring (создание зеркал) – дублирование всех данных по множеству одинаковых узлов.
- Собственно, микросервисы – функциональность разбита по бизнес-задачам, каждый сервис может быть создан своими средствами разработки.
Плюсы и минусы микросервисов
Микросервисный подход к проектированию приложений – не лучший выбор и не худший, а один из. Решать, строить ли приложение из множества несвязанных частей, нужно учитывая плюсы и минусы этого подхода.
Положительные стороны
- Четкое деление по модулям. Всегда будет понятно, как работает та или иная часть кода. Просто добавлять новые функции.
- Высокая доступность. Если какая-то часть монолита сломается – сломается все приложение. С микросервисами иначе: сервисы могут работать не все (не критические, вроде авторизации), но приложение при этом останется доступным.
- Разнообразные технологии. При разработке каждого сервиса вы вольны выбирать инструменты, которые лучше всего подойдут для конкретной бизнес-логики в этом сервисе. Например, выбрать оптимальную базу данных и удобные инструменты для работы с ней. Микросервисная архитектура также позволяет попробовать какую-то новую технологию на отдельном сервисе, не переписывая при этом все приложение.
- Относительная простота развертывания. Каждый сервис поднимается самостоятельно, что делает процесс развертывания и отладки более чистым.
Недостатки
- Сложность разработки. Если вам нужно быстрое решение (прототип, небольшое приложение, сжатые сроки), то микросервисы вам не подойдут. Скорость разработки – высокая плата за доступность и модульность.
- Сложность поддержки. Каждый микросервис нуждается в отдельном обслуживании, поэтому нужен постоянный автоматический мониторинг.