что такое монолитная архитектура
Монолитная vs Микросервисная архитектура
Что такое монолитная архитектура?
Монолитное приложение (назовем его монолит) представляет собой приложение, доставляемое через единое развертывание. Таким является приложение, доставленное в виде одной WAR или приложение Node с одной точкой входа.
Пример
Давайте представим классический интернет-магазин. Стандартные модули: UI, бизнес-логика и дата-слой. Возможны способы взаимодействия с сервисом: API REST и веб-интерфейс.
При построении монолита все эти вещи будут управляться внутри одного и того же модуля. Я не написал «один и тот же процесс», так как это было бы неверно для сценариев, в которых несколько экземпляров нашего модуля будут работать для более высоких нагрузок.
Рассмотрите пример на следующем рисунке, где все части находятся в одном и том же модуле развертывания:
Достоинства
Большим преимуществом монолита является то, что его легче реализовать. В монолитной архитектуре вы можете быстро начать реализовывать свою бизнес-логику, вместо того чтобы тратить время на размышления о межпроцессном взаимодействие.
Еще одна вещь — это сквозные (E2E) тесты. В монолитной архитектуре их легче выполнить.
Говоря об операциях, важно сказать, что монолит прост в развертывании и легко масштабируется. Для развертывания вы можете использовать скрипт, загружающий ваш модуль и запускающий приложение. Масштабирование достигается путем размещения Loadbalancer перед несколькими экземплярами вашего приложения. Как вы можете видеть, монолит довольно прост в эксплуатации.
Теперь давайте рассмотрим негативный аспект монолитной архитектуры.
Недостатки
Монолиты, как правило, перерождаются из своего чистого состояния в так называемый «большой шарик грязи». Вкратце это описывается как состояние, возникшее, потому что архитектурные правила были нарушены и со временем компоненты срослись.
Это перерождение замедляет процесс разработки: каждую будущую функцию будет сложнее развивать. Из-за того что компоненты растут вместе, их также необходимо менять вместе. Создание новой функции может означать прикосновение к 5 различным местам: 5 мест, в которых вам нужно написать тесты; 5 мест, которые могут иметь нежелательные побочные эффекты для существующих функций.
Ранее я говорил, что в монолите легко масштабировать. Это действительно так до тех пор, пока он не перерастёт в «большой шарик грязи», как упоминалось ранее. Масштабирование может быть проблематичным, когда только одной части системы требуются дополнительные ресурсы, ведь в монолитной архитектуре вы не можете масштабировать отдельные части вашей системы.
В монолите практически нет изоляции. Проблема или ошибка в модуле может замедлить или разрушить все приложение.
Строительство монолита часто протекает с помощью выбора основы. Отключение или обновление вашего первоначального выбора может быть затруднительным, потому что это должно быть сделано сразу и для всех частей вашей системы.
Что такое микросервисная архитектура?
В микросервисной архитектуре слабо связанные сервисы взаимодействуют друг с другом для выполнения задач, относящихся к их бизнес-возможностям.
Микросервисы в значительной степени получили свое название из-за того, что сервисы здесь меньше, чем в монолитной среде. Тем не менее, микро — о бизнес-возможностях, а не о размере.
По сравнению с монолитом в микросервисах у вас есть несколько единиц развертывания. Каждый сервис развертывается самостоятельно.
Пример
Давайте вновь рассмотрим в качестве примера Интернет-магазин.
Как и раньше, у нас есть: UI, бизнес-логика и дата-слой.
Здесь отличие от монолита состоит в том, что у всех вышеперечисленных есть свой сервис и своя база данных. Они слабо связаны и могут взаимодействовать с различными протоколами (например, REST, gRPC, обмен сообщениями) через свои границы.
На следующем рисунке показан тот же пример, что и раньше, но с разложением на микроуслуги.
Каковы преимущества и недостатки этого варианта?
Достоинства
Микросервисы легче держать модульными. Технически это обеспечивается жесткими границами между отдельными сервисами.
В больших компаниях разные сервисы могут принадлежать разным командам. Услуги могут быть повторно использованы всей компанией. Это также позволяет командам работать над услугами в основном самостоятельно. Нет необходимости координировать развертывание между командами. Развивать сервисы лучше с увеличением количества команд.
Микросервисы меньше, и благодаря этому их легче понять и проверить.
Меньшие размеры помогают, когда речь идет о времени компиляции, времени запуска и времени, необходимом для выполнения тестов. Все эти факторы влияют на производительность разработчика, так как позволяют затрачивать меньше времени на ожидание на каждом этапе разработки.
Более короткое время запуска и возможность развертывания микросервисов независимо друг от друга действительно выгодны для CI / CD. По сравнению с обычным монолитом он намного плавнее.
Микросервисы не привязаны к технологии, используемой в других сервисах. Значит мы можем использовать лучшие технологии подгонки. Старые сервисы могут быть быстро переписаны для использования новых технологий.
В микросервисах изолируемые разломы лучше по сравнению с монолитным подходом. Хорошо спроектированная распределенная система переживет сбой одного сервиса.
Недостатки
Все звучит довольно хорошо, но есть и недостатки.
Распределенная система имеет свою сложность: в ней вам приходится иметь дело с частичным отказом, более затруднительным взаимодействием при тестировании (тесты E2E), а также с более высокой сложностью при реализации взаимодействия между сервисами.
Транзакции легче проводить в монолите. Решением этой проблемы на микросервисах является Saga Pattern. Хорошее решение, но все же слишком громоздкое для реализации на практике.
Существуют эксплуатационные накладные расходы, а множество микросервисов сложнее в эксплуатации, чем несколько экземпляров сигнального монолита.
Помимо вышеперечисленных сложностей, для микросервисов также может потребоваться больше оборудования, чем для традиционных монолитов. Иногда микросервисы могут превзойти один монолит, если есть его части, которые требуют масштабирования до предела.
Изменения, затрагивающие несколько сервисов, должны координироваться между несколькими командами, а это может быть сложно, если команды еще не имели контактов.
Заключение
Все зависит от вашей организационной структуры. У вас есть 6 команд, которые будут работать над одним продуктом? Микросервисы могут подойти.
У вас есть команда из 3 разработчиков? Вероятно, они будут хорошо строить и поддерживать монолит.
Другими факторами являются скорость изменения и сложность. Высокие темпы изменений и высокая сложность могут быть факторами, которые заставляют выбрать архитектуру микросервиса.
Напротив, когда вы не очень хорошо знакомы с предметной областью, начать с монолита может быть полезно. Просто сделайте себе одолжение и постарайтесь сохранить его модульным. Это облегчит задачу, если вы когда-нибудь решите разделить свой монолит на несколько сервисов.
Монолитная архитектура. Традиционный метод разработки приложений
Выражение «монолитная архитектура» сразу ассоциируется со словом «монолит». А монолитом еще с давних пор называют большой единый блок из камня или бетона. Монолит — это что-то большое и единое, имеющее общую и мощную структуру. Монолит — это сила и на века.
В программировании «монолитная архитектура» также подразумевает наличие общей и единой платформы, где сконцентрированы все компоненты одной программы. Сколько бы н и насчитывалось подобных компонентов, все они унифицированы и при этом управляются из одного места. В этом и определяется сила «монолитных» приложений.
Монолитная архитектура
Многие современные стартапы выбирают именно монолитную архитектуру приложения, потому что она комфортна при работе небольшими группами разработчиков. При ее использовании все компоненты программы взаимосвязываются и взаимозаменяются — это помогает развивать программу автономной и самодостаточной. Монолитная архитектура считается традиционной и проверенной при разработке приложений, но в то же время многие разработчики считают такой подход в реализации приложений старомодным и уже никуда не годным.
Чтобы понимать, подойдет ли вам такой способ разработки или нет, нужно рассмотреть достоинства и недостатки монолитной архитектуры.
Д остоинства монолитной архитектуры
Простая разработка и простой запуск программы. Из-за того, что вся разработка сконцентрирована в одном месте, легче интегрировать инструменты для облегченной разработки, те же каталоги или библиотеки. Плюс при необходимости изменить элементы программы не нужно вносить изменения по отдельности в разных местах — все делается в одном месте.
Сквозные проблемы практически отсутствуют. Большое количество приложений имеют зависимость от задач, которые совершаются между компонентами программы: логи, ограничения скорости, контрольные журналы и т. д. При монолитной архитектуре эти проблемы практически отсутствуют, так как все сконцентрировано в одном коде и все работает в одном приложении.
Недостатки монолитной архитектуры
Большой объем кода. Если разрабатываемый продукт довольно большой и постоянно масштабируется, то со временем его код разрастается до огромных размеров. Это утяжеляет его понимание и дальнейшее обслуживание. Плюс может наступить момент, когда код будет «перегружен» и потеряет от этого свое качество.
Сложно модернизируется. Иногда нужно добавить в приложение какую-то новую «фишку». При монолитной архитектуре можно столкнуться со множеством препятствий, чтобы это реализовать. Потому что в некоторых случаях добавить какую-то «фишку» означает полностью переписать приложение. А это долго и дорого.
Заключение
Монолитная архитектура хоть и «старая» по своему происхождению, но до сих пор актуальн а и используется многими компаниями. Такая архитектура идеально подходит для стартапов и разработок:
когда нужно быстро развернуть небольшое приложение;
когда создается непроверенный продукт и нужно его быстро создать, чтобы протестировать;
когда просто нет опыта работы с микросервисами;
если изначально известно, что приложение не будет разрастаться до колоссальных масштабов;
если в приоритете разработки программного обеспечения наход я тся именно скорость его работы и производительность.
Поэтому перед использованием монолитной архитектуры нужно все тщательно взвесить. Иногда продумывают такой ход: запуск приложения осуществляют при использовании монолитной архитектуры, а чуть позже, если оно «зашло» пользователю, дробят приложения на микросервисы для удобного масштабирования, тем самым меняя его архитектуру.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Как построить микросервисную инфраструктуру
На рынке сейчас существует два вида организации приложений, о которых мы поговорим в докладе, это:
Монолитная архитектура и ее недостатки
Итак, монолитная архитектура – это архитектура, где приложение представлено в виде единого компонента и представляет собой разрез бизнес-логики, которая модульно прошита.
Все клиенты, как правило, обращаются только к одному приложению.
Казалось бы, если мы сделали приложение, и все работает, то почему бы так дальше и не жить?
Какие проблемы мы выявили в процессе эксплуатации приложения?
Микросервисная архитектура
Чтобы побороть минусы монолитной архитектуры, используется подход, который позволяет распиливать большие куски монолита на микросервисы.
Что вообще такое микросервис? Это небольшая программа, запущенная на своем сервере и работающая только над одним типом задач. Например, сервис авторизации, который принимает на вход логин/пароль и далее решает – давать пользователю доступ в систему или нет. Или, например, сервис отправки SMS.
Любое монолитное приложение можно разбить на множество сервисов, которые должны как-то между собой взаимодействовать.
Сервисы могут общаться между собой любым удобным способом:
Как правило, в основном сервисы общаются по HTTP.
Так как сервисы маленькие, ненагруженные, то они могут работать на множестве сравнительно недорогих машин. Более того, под каждый конкретный микросервис можно подобрать железо подходящей конфигурации.
Если в случае с монолитом нам с течением времени придется переходить на очень большой сервер, то здесь мы можем просто выпиливать второстепенную логику, перекладывая ее на небольшое, не сильно производительное железо. И освобождать тем самым ресурсы большого сервера, чтобы он решал более конкретные задачи – расчет себестоимости, расчет зарплаты (какие-то высоконагруженные вещи, которые до сих пор должны оставаться на серьезном железе).
Например, если мы написали для какого-то проекта сервис авторизации – то для другого проекта мы не дублируем код, а просто дергаем этот сервис по REST-протоколу, и он нам возвращает данные.
Допустим, ваше приложение – это магазин, состоящий из набора сервисов (таких, как корзина, формирование заказов, платежный шлюз). И вот в течение дня у вас отваливается шлюз платежной интеграции. Но бизнес позволяет клиентам дальше формировать заказы, видеть витрину товаров. Просто в момент оплаты клиент будет видеть сообщение, что у вас сейчас проблемы с оплатой: «Вы сможете оплатить заказ позже». И когда сервис поднимется, можно будет уведомить клиентов, тем самым, какая-то часть из них может вернуться.
А в случае монолитной архитектуры – при проблеме в основном приложении встает все.
Если мы нашли какую-то функциональность в другом стеке – в Node.js или в Python (что-то, что позволит нам нарисовать красивый дашборд или использовать машинное обучение, которое сейчас актуально), мы можем просто запустить этот сервис рядом и использовать его. При этом основная бизнес-логика остается работать в 1С. Тем самым мы можем брать лучшее из разных технологических миров, взаимодействовать со всем этим в нашей экосистеме, и все будет просто хорошо.
Плюсы-плюсами, но есть и минусы.
Мониторинг микросервисов – Flask Monitoring Dashboard
В качестве REST-шлюза мы используем Flask. Есть OpenSource библиотека Flask Monitoring Dashboard. С ее помощью мы мониторим количество вызовов методов – например, на скриншоте видно, сколько раз происходил вызов определенного метода сервиса. Если в течение двух месяцев мы видим, что этот метод никто не вызывает, мы можем просто его выпилить.
Этот дашборд также позволяет нам смотреть нагрузку на метод в разрезе часов и дней.
Есть профайлер, который собирает в себе, какие входные параметры передавались в метод, и сколько чего выполнилось – это облегчает расследование проблем с производительностью.
Мониторинг шины данных– Kafka Manager от Yahoo
Сервисы обмениваются сообщениями через шину данных – мы используем в качестве шины Apache Kafka.
Шина данных – это такая сущность, которая соединяет собой поставщиков сообщений и их потребителей. Например, когда вы пишете письмо, в качестве шины выступает «Почта России».
Само сообщение выглядит как письмо. Есть тема, которая указывает на название события, и есть данные, и есть потребители. Шина видит, что на эту тему подписаны эти потребители, и она им скидывает эти сообщения по сети.
Шину мониторим через Kafka Manager от Yahoo – он собирает метрики по сообщениям.
Архитектура обмена сообщений между 1С и шиной данных Apache Kafka
Встает логичный вопрос – как подключить Apache Kafka к 1С.
Мы реализовали подключение без использования внешних компонент:
Соответственно, 1С стучит GET и POST-запросами в Kafka через такой же прокси-сервис, который имеет соответствующий REST-интерфейс, и этот прокси-сервис скидывает эти сообщения в шину данных.
Вот так можно решить вопрос интеграции 1С и Kafka.
Вот пример, как собирает метрики по сообщениям Kafka Manager от Yahoo. Здесь показаны как раз метрики на то событие, которое выгребает прокси-сервис.
Конечно же, и 1С можно использовать как микросервис, потому что стек 1С ничем не хуже других. И мы можем наши куски монолита распиливать на какие-то отдельные конфигурации, выносить туда бизнес-логику или делать еще какие-то вещи. Тем самым, мы можем дорабатывать одну часть нашей инфраструктуры, и при этом основная логика работы не будет валиться, и наш бизнес не будет останавливаться.
Примеры использования микросервисов. Asterisk client
Поговорим о реальных примерах применения из жизни моего предприятия. Как же нам помогло применение микросервисов в повышении эффективности работы бизнеса.
Недавно мы проводили реструктуризацию бизнес-процесса «Запись на сервис». И одной из точек маршрута было – уведомить клиента за сутки о том, что он собирался приехать. Если клиент подтверждает свое намерение приехать, то бизнес-процесс двигается дальше по ветке, начинается подготовка к заезду и т.д. А если клиент не планирует приезжать, то бизнес-процесс завершается, и переходит уже к другой логике (к попытке вернуть клиента и т.д.).
Сначала эту задачу возложили на людей, но эффективность прозвона менеджерами не сильно повысила продажи. И мы пришли к выводу, что у нас есть телефония Asterisk, и можно попробовать организовать автоматический прозвон.
Это выглядит следующим образом:
В результате мы увеличили количество дозвонов и автоматизировали получение ответов (да/нет) по поводу каждого обращения.
Снизили нагрузку на операторов и менеджеров по исходящему трафику.
И в качестве побочного эффекта облегчили менеджерам набор номера клиента, потому что раньше возможности совершить звонок из 1С не было.
Примеры использования микросервисов. Внешний журнал записи
Еще один пример – журнал записи. Он нужен нам для понимания, в какой момент времени к какому менеджеру приедет клиент. Тем самым мы планируем нагрузку на сотрудников, на цех – что позволяет нам избежать коллизий при записи, когда клиенты пытаются записаться на одно и то же время.
По нагрузке на приложение:
10 сотрудников и 5 постов.
Первая реализация, конечно, была полностью сделана средствами 1С и как-то работала, но потом ее пришлось выпилить, потому что 1С не справлялась с задачами бизнеса.
С какими основными проблемами при реализации на 1С мы столкнулись:
После отказа от фронтенда на 1С была выбрана следующая архитектура:
Как это все работает?
В качестве результата приложения получили единый бекенд. Все данные для журналов (журнал не только в 1С) берутся из одного места. Там все актуально, ничего не разъезжается, дублирования логики нет.
Кроме этого мы получили единый фронтенд. Операторы колл-центра периодически переваливаются из 1С в колл-центр и обратно, они не задают вопросы, как с ним работать – он работает аналогично.
Функциональный фронтенд. Была задача закрашивать серым цветом области, которые не используются в рабочее время (на слайде видно, что нерабочее время по краям выделено серым цветом). Типовой диаграммой это реализовать не получилось.
На слайде показан пример, как это работает – интерфейс очень отзывчивый, ничего не висит.
Мы теперь можем делать произвольные формы, не ограничиваясь 1С-ным стеком. Если нам нужна какая-то дополнительная функциональность, мы ее выносим. На слайде показан пример, где одна форма HTML выводится поверх другой – все реализуемо.
Быстрый отклик при работе из базы 1С. Раньше это работало очень медленно.
Обратите внимание, поле, где работает журнал – это встроенный в 1С Chrome (Chrome Embedded Framework). Потому что текущий движок в платформе 8.3.8 (Internet Explorer) не позволял запускаться js-коду. Там ничего не работало. Чтобы добиться результата, пришлось впилить туда Chrome.
Какие еще преимущества мы получили в результате:
Примеры использования микросервисов. Предсказание пробега
Еще один пример – у нас есть сервис предсказания пробега.
Для чего это вообще нужно? Мы с помощью машинного обучения предсказываем, когда человек докатает пробег на следующее ТО, и за две недели до этой даты делаем ему предложение о прохождении ТО у нас.
Тем самым мы: во-первых, повышаем лояльность клиентов, во-вторых, повышаем возможность покупки этого ТО у нас.
Как это все работает?
В качестве результата могу сказать, что мы получили проактивную коммуникацию с клиентом по предложениям.
Мы заранее предсказываем его пробег с точностью до 2-х недель в 80-90% случаев.
Создаем предложения по заезду с какой-то дальнейшей обработкой.
Выводы
В качестве выводов могу сказать следующее:
Скорее всего, не во всякой задаче можно или нужно использовать микросервисную архитектуру. Но там, где есть такая возможность, по моему мнению, плюсы превышают минусы.
Вопросы
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.