Микросервисы против монолитной архитектуры: Что лучше выбрать?
На современном гиперконкурентном рынке оптимальный путь развития бизнеса должен быть очевиден. Другими словами, вы хотите всегда идти в ногу со временем или опережать его. Это означает, что ваши разработчики и ИТ-персонал будут постоянно изучать новые технологии и лучшие практики. По мере приобретения новых навыков и внедрения новых программных стеков необходимо будет принимать ряд решений.
Одно из важных решений - выбор архитектуры микросервисов или монолитной архитектуры. Если вы сделаете правильный выбор, то получите серьезные преимущества. Неправильный выбор - и вы окажетесь в постоянной борьбе за бесперебойную работу своего центра обработки данных.
Такое неверное решение может стать кошмаром для ваших разработчиков, независимо от того, работают ли они на Java, JavaScript, Ruby или .NET. Это также может повлиять на весь процесс разработки приложений. Поэтому очень важно, чтобы те, кто принимает такие важные решения, понимали, во что они ввязываются.
Итак, что же представляют собой эти архитектуры? Давайте рассмотрим их и выясним, какая из них может подойти именно вам.
|
Критерии
|
Микросервисы | Монолитная |
|
Структура
|
Разделение приложения на небольшие, слабо связанные и независимые сервисы | Создает приложение как единое, неделимое целое |
|
Разработка
|
Обеспечивает независимую разработку и развертывание сервисов | Все компоненты взаимосвязаны, поэтому они должны разрабатываться совместно |
|
Масштабируемость
|
Отдельные компоненты могут масштабироваться по мере необходимости | Масштабирование всего приложения должно осуществляться даже при увеличении спроса только на одну функцию |
|
Стек технологий
|
Каждый сервис может использовать свой стек технологий | Все компоненты должны использовать один и тот же стек технологий |
|
Развертывание
|
Позволяет осуществлять непрерывное развертывание и интеграцию | Для обновления необходимо развертывание всего приложения |
|
Изоляция отказов
|
Сбой в одном сервисе не влияет на другие | Одна ошибка может вывести из строя все приложение |
|
Производительность
|
Высокая производительность и скорость работы благодаря легковесным сервисам | Производительность зависит от размера и сложности приложения |
|
Управление данными
|
Каждый сервис может иметь собственную базу данных | Единая база данных используется для всего приложения |
|
Сложность
|
Более сложная из-за проблем распределенных систем | На начальном этапе менее сложная, но со временем может стать трудноуправляемой |
|
Скорость разработки
|
Первоначально медленнее из-за необходимости тщательного планирования. | Первоначально быстрее из-за простоты |
|
Модификация
|
Легче обновлять или добавлять новые функции, не нарушая работу других служб | Обновления или модификации могут потребовать изменения всей системы. |
|
Тестирование и отладка
|
Легче тестировать и отлаживать отдельные сервисы независимо друг от друга | Тестирование и отладка могут быть более сложными из-за взаимосвязанности приложений |
| Межсервисное взаимодействие | Сервисы взаимодействуют через API, что может увеличить задержку | Компоненты взаимодействуют напрямую, что обычно обеспечивает меньшую задержку |
Монолитная архитектура
Мы начнем с монолитной архитектуры, потому что она наиболее проста для понимания. Почему? Потому что монолитная архитектура существует уже очень давно. Фактически, монолитные приложения - это то, что большинство людей понимает под словом "программное обеспечение".
Проще говоря, монолитное приложение - это приложение, созданное как единое целое, хотя это не обязательно означает, что в него включено все необходимое для работы приложения. Давайте разберемся в этом вопросе, чтобы лучше понять, что происходит.
Да, существуют приложения, которые устанавливаются как отдельные клиенты. Возьмем, к примеру, офисный пакет LibreOffice. Это приложение не зависит от сторонних программ или внешних служб. Все выполняется на локальной клиентской машине.
С другой стороны, для работы блог-платформы WordPress требуется следующее:
- Сервер базы данных
- Приложение на стороне сервера
- Пользовательский интерфейс на стороне клиента.
Каждый из этих компонентов является монолитным и работает вместе, создавая единое целое.
Запутались? Давайте упростим ситуацию, взглянув на нее с точки зрения разработчика.
Допустим, в вашей компании развернута монолитная система управления контентом, созданная собственными силами. Эта система включает в себя базу данных, приложение на стороне сервера и пользовательский интерфейс на стороне клиента. Она работает без сбоев, и ваши сотрудники зависят от нее каждый день.
Однако в какой-то момент разработчики захотели добавить новую функциональность в серверный компонент. Для этого разработчикам придется перестраивать и развертывать все серверное приложение. Хотя конечный результат может оказаться достойным, на весь процесс разработки (проектирование, разработка, тестирование в вопросах и ответах, развертывание) уходит значительное время.
Архитектура микросервисов
Теперь рассмотрим микросервисную архитектуру. Если монолитное приложение содержится в едином блоке, то микросервисы разбивают его на множество гораздо более мелких и независимых блоков. Каждый из этих блоков выполняет функцию обслуживания каждого сервиса приложения, который затем объединяется в единое целое.
Одним из лучших примеров микросервисной архитектуры являются контейнеры.

Можно развернуть сервер NGINX как монолитный сервис. Установите NGINX на сервер Linux - и вы готовы обслуживать свои сайты. Можно добавить базу данных, установив MariaDB. Однако при таком развертывании возникают две большие проблемы.
Во-первых, если вы захотите обновить свой веб-сервер, вам придется обновлять каждый компонент в целом - и веб-сервер, и базу данных. Во-вторых, такой тип развертывания может оказаться неспособным к масштабированию в соответствии с потребностями предприятия.
Другой путь - развертывание веб-сервера в виде набора микросервисов с помощью контейнеров. Можно развернуть в контейнере Kubernetes капсулу с веб-сервером NGINX, капсулу с базой данных, а затем соединить их между собой сетевым сервисом и томом хранения данных.
При необходимости увеличения масштаба развертывания Kubernetes может автоматически развернуть в кластере дополнительные контейнеры NGINX и MariaDB.
Помимо масштабируемости, одной из лучших особенностей архитектуры микросервисов является то, что в случае отказа одного из сервисов на его месте будет развернут другой. Таким образом, отказоустойчивость является встроенной. А поскольку все компоненты развертываются независимо друг от друга, перспектива обновления становится гораздо более плавной. Это особенно актуально для контейнеров, где простои, связанные с обновлением, практически отсутствуют.
Что лучше выбрать для вашей компании?
На этот вопрос можно ответить довольно просто:
Если вашей компании требуется высокая масштабируемость, отказоустойчивость и надежность, то вам необходимо использовать архитектуру микросервисов.
Если же вашей компании требуются в основном клиентские инструменты (устанавливаемые на настольные компьютеры) или вы не рассматриваете возможность масштабирования на уровне предприятия, то вам подойдет монолитная архитектура.
Оговорка
Здесь следует сделать оговорку. Микросервисную архитектуру не так-то просто развернуть. Kubernetes сложна практически на всех возможных уровнях. Поэтому, если вы заинтересованы в микросервисной архитектуре, вы должны быть уверены, что разработчики и ИТ-администраторы справятся с этой задачей, иначе вы окажетесь в состоянии постоянного решения проблем.
Кроме того, для успешного развертывания микросервисов необходимы ресурсы. Чтобы действительно воспользоваться преимуществами масштабируемости микросервисов, необходим центр обработки данных с достаточной мощностью для работы с такой архитектурой. Чаще всего это означает развертывание на стороннем облачном хосте, таком как Amazon AWS, Google Cloud, Linode, Rackspace или Microsoft Azure. Если у вас нет серьезного центра обработки данных, расположенного в помещении, вы не сможете достичь таких масштабов, как при использовании одного из этих хостов.
В конечном счете, выбор остается за вами. Но для большинства компаний, стремящихся к значительному росту, микросервисы - это путь вперед.


