.webp)
.webp)
Микросервисы – это шаблон сервис-ориентированной архитектуры, в котором приложения создаются в виде наборов небольших и независимых сервисных единиц. Такой подход к проектированию сводится к разделению приложения на однофункциональные модули с четко прописанными интерфейсами. Небольшие команды, управляющие всем жизненным циклом сервиса могут независимо развертывать и обслуживать микросервисы.
Термин «микро» относится к размеру микросервиса – он должен быть удобным в управлении одной командой разработчиков (5-10 специалистов). В данной методологии большие приложения делятся на крошечные независимые блоки.
Что такое монолитная архитектура?
Если говорить простым языком, то монолитная архитектура – это как бы большой контейнер, в котором все компоненты приложения соединяются в единый пакет.
В качестве примера монолитной архитектуры давайте рассмотрим сайт для электронной торговли. Например, онлайн-магазин.
В любом таком приложении есть ряд типовых опций: поиск, рейтинг и отзывы, а также оплаты. Данные опции доступны клиентам через браузер или приложение. Когда разработчик сайта онлайн-магазина развертывает приложение, это считается одной монолитной (неделимой) единицей. Код различных опций (поиска, отзывов, рейтинга и оплаты) находится на одном и том же сервере. Чтобы масштабировать приложение, вам нужно запустить несколько экземпляров (серверов) этих приложений.
Что такое микросервисная архитектура?
Микросервисной архитектурой называется методика разработки архитектуры, позволяющая создавать приложения в виде набора небольших автономных сервисов для работы с конкретными предметными областями. Такой вариант структурированной архитектуры позволяет организовать приложения в множество слабосвязанных сервисов. Микросервисная архитектура содержит мелкомодульные сервисы и упрощенные протоколы.
Давайте рассмотрим пример приложения для онлайн-торговли с микросервисной архитектурой. В данном примере каждый микросервис отвечает за одну бизнес-возможность. У «Поиска», «Оплаты», «Рейтинга и Отзывов» есть свои экземпляры (сервер), которые взаимодействуют между собой.
В монолитной архитектуре все компоненты сливаются в одну модель, тогда как в микросервисной архитектуре они распределяются по отдельным модулям (микросервисам), которые взаимодействуют между собой (см. пример выше).
Коммуникация между микросервисами – это взаимодействие без сохранения состояния. Каждая пара запросов и ответов независима, поэтому микросервисы легко взаимодействуют друг с другом. Микросервисная архитектура использует федеративные данные. Каждый микросервис имеет свой отдельный массив данных.
Микросервисы и монолитная архитектура: сравнение
|
Микросервисы |
Монолитная архитектура |
|
Каждый блок данных создается для решения определенной задачи; его размер должен быть предельно малым |
Единая база кода для всех бизнес-целей |
|
Запуск сервиса происходит сравнительно быстро |
На запуск сервиса требуется больше времени |
|
Локализовать ошибки довольно просто. Даже если один сервис сломается, другой – продолжит свою работу |
Локализовать ошибки сложно. Если какая-то определенная функция не перестает работать, то ломается вся система. Чтобы решить проблему, придется заново собирать, тестировать и развертывать приложение. |
|
Все микросервисы должны быть слабо связанными, чтобы изменения в одном модуле никак не влияли на другой. |
Монолитная архитектура тесно связана. Изменения в одному модуле кода влияет на другой |
|
Компании могут выделять больше ресурсов на самые рентабельные сервисы |
Сервисы не изолированы; выделение ресурсов на отдельные сервисы невозможно |
|
Можно выделить больше аппаратных ресурсов на самые популярные сервисы. В примере выше посетители чаще обращаются к каталогу товаров и поиску, а не к разделу оплат. Таким образом, будет разумнее выделить дополнительные ресурсы на микросервисы каталога товаров и поиска |
Масштабирование приложения – задача сложная и экономически не выгодная |
|
Микросервисы всегда остаются постоянными и доступными |
Большая нагрузка на инструменты для разработки, поскольку процесс необходимо запускать с нуля |
|
Федеративный доступ к данным, благодаря чему под отдельные микросервисы можно подбирать наиболее подходящую модель данных |
Данные централизованы |
|
Небольшие целевые команды. Параллельная и ускоренная разработка |
Большая команда; требуется серьезная работа по управлению командой |
|
Изменения в модели данных одного микросервиса никак не сказывается на других микросервисах |
Изменения в модели данных влияют на всю базу данных |
|
Четко прописанный интерфейс позволяет микросервисам эффективно взаимодействовать между собой |
Не предусмотрено |
|
Микросервисы делают акцент на продуктах (модулях), а не проектах |
Сосредоточены на проекте в целом |
|
Отсутствие перекрестных зависимостей между базами кода. Для разных микросервисов можно использовать разные технологии |
Одна функция или программа зависит от другой |
Сложности в работе с микросервисами
- Микросервисы полагаются друг на друга, поэтому необходимо выстроить коммуникацию между ними.
- В микросервисах создается больше модулей, чем в монолитных системах. Эти модули пишутся на разных языках, и их необходимо поддерживать.
- Микросервисы – это распределенная система, так что, по сути, мы имеем дело со сложной системой.
- В разных сервисах используются свои механизмы; для неструктурированных данных требуется больший объем памяти.
- Для предотвращения каскадных сбоев необходимо эффективное управление и слаженная командная работа.
- Трудно воспроизвести ошибку, если она пропадает в одной версии и вновь появляется в другой.
- Независимое развертывание и микросервисы – вещи слабо совместимые.
- Микросервисная архитектура требует большего количества операций.
- Сложно управлять приложением, когда в систему добавляются новые сервисы.
- Для поддержки всевозможных распределенных сервисов требуется большая команда опытных специалистов.
- Микросервисы считаются дорогостоящими решениями, поскольку для разных задач создаются и поддерживаются разные серверные пространства.
Сервис-ориентированная архитектура (СОА) или микросервисы
СОА-сервисы (SOA - Service-oriented architecture) поддерживаются через реестр, который считается перечнем файлов каталога. Приложения должны найти сервис в реестре и вызвать его.
Иначе говоря, СОА похож оркестр: каждый музыкант играет на своем инструменте, а всеми артистами управляет дирижер.
Микросервисы – это разновидность СОА-стиля. Приложения создаются в виде набора небольших сервисов, а не цельной программы.
Микросервисы похожи на труппу артистов: каждый танцор знает свою программу и не зависит от других. Даже если кто-то забудет какое-то движение, вся труппа не собьется с ритма.
Теперь давайте поговорим о различиях между СОА и микросервисах.
|
Параметр |
СОА |
Микросервисы |
|
Тип проектирования |
В СОА компоненты приложения открыты для внешнего мира; они доступны в виде сервисов |
Микросервисы – это часть СОА. Такая архитектура считается реализацией СОА |
|
Зависимость |
Подразделения – зависимы |
Они не зависят друг от друга |
|
Размер приложения |
Размер приложения больше, чем у обычных программ |
Размер приложения всегда небольшой |
|
Стек технологий |
Стек технологий ниже, чем у микросервисов |
Стек технологий очень большой |
|
Сущность приложения |
Монолитная |
Полностековая |
|
Независимость и ориентированность |
СОА-приложения создаются для выполнения множества бизнес-задач |
Создаются для выполнения одной бизнес-задачи |
|
Развертывание |
Процесс развертывания растянут по времени |
Несложное развертывание, на которое тратится меньше времени |
|
Рентабельность |
Более рентабельно |
Менее рентабельно |
|
Масштабируемость |
Меньше, чем у микросервисов |
Высокая масштабируемость |
|
Бизнес-логика |
Компоненты бизнес-логики хранятся внутри одного сервисного домена. Простые проводные протоколы (HTTP с XML JSON). |
Бизнес-логика распределена между разными корпоративными доменами |
Микросервисные инструменты
Wiremock – тестирование микросервисов
WireMock – это гибкая библиотека для создания заглушек и сервисов-имитаций. В ней можно настроить ответ, который HTTP API вернет при получении определенного запроса. Также может использоваться для тестирования микросервисов.
Docker
Docker – это проект с открытым кодом для создания, развертывания и запуска приложений с помощью контейнеров. Использование такого рода контейнеров позволяет разработчикам запускать приложение в виде одного пакета. Кроме того, в одном пакете могут поставляться библиотеки и другие зависимости.
Hystrix
Hystrix – это отказоустойчивая Java-библиотека. Данный инструмент предназначен для разделения точек доступа к удаленным сервисам, системам и сторонним библиотекам в распределенной среде (микросервисах). Библиотека улучшает всю систему в целом, изолируя неисправные сервисы и предотвращая каскадный эффект от сбоев.
Лучшие примеры использования микросервисной архитектуры
- Отдельное хранение данных для каждого микросервиса.
- Поддержание кода на едином уровне зрелости
- Отдельная сборка для каждого микросервиса.
Заключение
- Микросервисы – это СОА-шаблон, в котором приложения создаются как набор малых и независимых серверных единиц.
- Микросервисная архитектура относится к стилям разработки архитектуры, позволяющим создавать приложение в виде небольших и автономных сервисов для определенных предметных областей.
- Монолитная архитектура похожа на большой контейнер, в котором все компоненты приложения собраны в один пакет.
- Каждый блок приложения в микросервисе имеет предельно малый размер и выполняет определенную функцию.
- Большая база кода в монолитной архитектуре замедляет процесс разработки. Выход новых версий может растянуться на месяцы. Поддерживать такую базу кода довольно сложно.
- Существует 2 типа микросервисов: Stateless (без сохранения состояния) и Stateful (с отслеживанием состояния)
- Микросервисы на Java полагаются друг на друга; они должны взаимодействовать между собой. Микросервисы позволяют в большей степени сконцентрироваться на определенных функциях или потребностях бизнеса.
- Сервисно-ориентированная архитектура, или СОА, – это усовершенствованные распределенные вычисления, основанные на проектной модели запроса/ответа в синхронных или асинхронных приложениях.
- Компоненты приложения в СОА открыты для внешнего мира и представлены в виде сервисов; микросервисы считаются частью СОА. Это реализация СОА.
- К популярным микросервисным инструментам относятся Wiremock, Docker и Hystrix.
