Что такое микросервисная архитектура и когда ее применять

1
6171

Задумывались над тем, как в одном проекте могут совмещаться части на разных языках? Рассмотрим, что такое микросервисная архитектура.

Множество приложений, с которыми мы регулярно пересекаемся (интернет-банки, развлекательные сервисы вроде YouTube и так далее), часто созданы с использованием множества технологий, которые как-то уживаются под одной крышей и не выглядят разрозненно.

Что такое микросервисная архитектура

Микросервисы – это архитектурный шаблон. Все сервисы в этом шаблоне:

  1. Маленькие
    Сервис не должен требовать множества людей для разработки. Одна команда может разрабатывать несколько сервисов.
  2. Сфокусированные
    Один сервис – одна задача.
  3. Слабосвязанные
    Изменения в одном сервисе не влияют на другой.
  4. Высокосогласованные
    Компонент или класс создаются с учетом всех методов решения бизнес-задачи.

Классическое монолитное приложение обычно имеет стандартную структуру Интерфейс -> Бизнес-логика -> Данные.

Монолитное приложение

Микросервисы же отталкиваются от бизнес-логики:

Микросервисы

Один сервис должен решать одну задачу и эти задачи определяются частями ответственности приложения. Например, могут существовать разные сервисы для команд, работающих в рамках одного проекта (допустим, онлайн-магазина).

Когда применяется

Обычно микросервисная архитектура применяется как один из вариантов масштабирования приложения. Всего таких вариантов может быть три:

  • Sharding («разбиение» или просто «шардинг») – данные и инструменты для доступа к ним размещаются на разных узлах.
  • Mirroring (создание зеркал) – дублирование всех данных по множеству одинаковых узлов.
  • Собственно, микросервисы – функциональность разбита по бизнес-задачам, каждый сервис может быть создан своими средствами разработки.

Плюсы и минусы микросервисов

Микросервисный подход к проектированию приложений – не лучший выбор и не худший, а один из. Решать, строить ли приложение из множества несвязанных частей, нужно учитывая плюсы и минусы этого подхода.

Положительные стороны

  • Четкое деление по модулям. Всегда будет понятно, как работает та или иная часть кода. Просто добавлять новые функции.
  • Высокая доступность. Если какая-то часть монолита сломается – сломается все приложение. С микросервисами иначе: сервисы могут работать не все (не критические, вроде авторизации), но приложение при этом останется доступным.
  • Разнообразные технологии. При разработке каждого сервиса вы вольны выбирать инструменты, которые лучше всего подойдут для конкретной бизнес-логики в этом сервисе. Например, выбрать оптимальную базу данных и удобные инструменты для работы с ней. Микросервисная архитектура также позволяет попробовать какую-то новую технологию на отдельном сервисе, не переписывая при этом все приложение.
  • Относительная простота развертывания. Каждый сервис поднимается самостоятельно, что делает процесс развертывания и отладки более чистым.

Недостатки

  • Сложность разработки. Если вам нужно быстрое решение (прототип, небольшое приложение, сжатые сроки), то микросервисы вам не подойдут. Скорость разработки – высокая плата за доступность и модульность.
  • Сложность поддержки. Каждый микросервис нуждается в отдельном обслуживании, поэтому нужен постоянный автоматический мониторинг.

Полезные ссылки




1 комментарий