Большой взлет микросервисов, или как удушить монолит

Начнем издалека — с архитектуры системы. Создание нового продукта всегда связано с риском. И выбор правильной архитектуры — важный шаг на пути успеху.

Выбор архитектуры

Архитектура – это проектные решения, которые тяжело изменить.

Мартин Фаулер

Существует несколько видов архитектуры – монолитная, сервис-ориентированная, микросервисная, бессерверная. Ниже мы кратко рассмотрим каждый из них. Но что это значит — «тяжело изменить»?

Представьте, что у вас есть проектное решение, в котором чётко описано, как разработчики должны структурировать Java-код. Если проект уже содержит много кода, переделать всю его структуру под новую схему — задача трудоёмкая и сложная. Именно поэтому такое решение считается архитектурным, а точнее — программной архитектурой.Однако отдельный разработчик может легко проигнорировать эти правила и написать код по-своему. Ведь вносить локальные изменения в программное обеспечение всегда проще, чем перестраивать всю архитектуру целиком. Хотя глобальные изменения архитектуры требуют больших усилий, отдельные её элементы можно менять довольно легко.

ГОСТ Р 57100-2016 дает следующее определение архитектуры — это основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проектирования и развития. Суть создания архитектуры — структурирование. Создание архитектуры — это деятельность по организации и поддержки системы из составляющих ее элементов. И все архитектурные принципы направлены на декомпозицию и организацию составных частей системы.

Монолитная архитектура

Монолит — это древнее слово, обозначающее огромный каменный блок. Хотя этот термин широко используется сегодня, представление остается одинаковым во всех областях. В программной инженерии монолитная модель относится к единой неделимой единице. Различные компоненты приложения объединяются в одну программу на одной платформе. Обычно монолитное приложение состоит из базы данных, клиентского пользовательского интерфейса и серверного приложения. Все части программного обеспечения унифицированы, а все его функции управляются в одном месте.

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

Плюсы монолитной архитектуры:

• Упрощенная разработка и развертывание;
• Меньше сквозных проблем;
• Лучшая производительность.

Минусы монолитной архитектуры:

• Кодовая база со временем становится громоздкой;
• Сложно внедрять новые технологии;
• Ограниченная гибкость.

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

Сервис-ориентированная архитектура (SOA)

Сервис-ориентированная архитектура (далее SOA — service-oriented architecture) — это стиль архитектуры программного обеспечения, который предполагает модульное приложение, состоящее из дискретных и слабосвязанных программных агентов, которые выполняют конкретные функции. SOA разделяет компоненты по двум основным ролям: поставщик и потребитель сервисов. Приложение может быть спроектировано и построено таким образом, что его модули легко интегрируются и могут быть легко использованы повторно.

Плюсы SOA:

• Повторное использование сервисов;
• Легкость в сопровождении;
• Более высокая надежность;
• Параллельная разработка.

Поскольку сервис-ориентированная архитектура разбита на прослойки, она поддерживает параллелизм в процессе разработки. Независимые сервисы могут разрабатываться параллельно.

Минусы SOA:

• Сложность в управлении;
• Высокие инвестиционные затраты;
• Дополнительная нагрузка.

SOA лучше всего подходит для сложных корпоративных систем, например, банковских. Банковскую систему чрезвычайно сложно разделить на микросервисы. Но монолитный подход также не годится для банковской системы, так как одна часть может повредить все приложение. Лучшее решение — использовать подход SOA и организовать сложные приложения в изолированные независимые сервисы.

Микросервисная архитектура (MSA)

Микросервисы — это тип сервисно-ориентированной архитектуры программного обеспечения, ориентированный на создание ряда автономных компонентов, составляющих приложение. В отличие от монолитных приложений, созданных как единое целое, микросервисные приложения состоят из нескольких независимых компонентов, которые склеены вместе посредством API.

Подход на основе микросервисов ориентирован главным образом на бизнес-приоритеты и возможности, тогда как монолитный подход организован вокруг технологических уровней, пользовательских интерфейсов и баз данных. Микросервисный подход стал тенденцией в последние годы, так как все больше и больше предприятий становятся гибкими и переходят на DevOps.

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

Лукас Краус, автор Microservices

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

• Легко разрабатывать, тестировать и развертывать;
• Повышенная гибкость;
• Возможность масштабирования по горизонтали.

Минусы микросервисов:

• Сложность;
• Проблемы безопасности;
• Разные языки программирования.

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

Теперь мы можем сравнить эти три программные архитектуры, чтобы визуально определить различия между ними.

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

Бессерверная архитектура

Бессерверная архитектура — это подход применения облачных вычислений для создания и запуска приложений и сервисов без необходимости управления инфраструктурой. В бессерверных приложениях выполнение кода управляется платформой, что позволяет разработчикам развертывать код, не беспокоясь об обслуживании и обеспечении сервера. На самом деле, бессерверность не означает «отсутствие сервера». Приложение все еще работает на серверах, но сторонняя облачная служба, такая как AWS, несет полную ответственность за эти серверы. Бессерверная архитектура устраняет необходимость в дополнительных ресурсах, масштабировании приложений, обслуживании серверов, а также системах хранения и баз данных.

Бессерверная архитектура включает в себя две концепции:

• FaaS (Function as a Service — функция как услуга) — модель облачных вычислений, которая позволяет разработчикам загружать части функционала в облако и позволяет этим частям выполняться независимо.
• BaaS (Backend as a Service — бэкэнд как услуга) — модель облачных вычислений, которая позволяет разработчикам передавать на аутсорсинг аспекты бэкэнда (управление базой данных, облачное хранилище, хостинг, аутентификация пользователей и т. д.), а также писать и поддерживать только часть внешнего интерфейса.
  

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

Плюсы бессерверной архитектуры:

• Простота развертывания;
• Снижение затрат;
• Улучшенная масштабируемость.

Недостатки бессерверной архитектуры:

• Привязка к поставщику;
• Не для долгосрочных задач.

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

Итак, мы видим, что, во-первых, микросервисная архитектура является всего лишь одним из нескольких возможных вариантов архитектуры информационных систем, и не имеет безусловных преимуществ. Выбор архитектуры зависит от множества факторов. Попытки бездумно внедрить «модное» новшество без детальной оценки всех плюсов и минусов, приводит как правило к неудаче проекта.

Исторически, каждая архитектура появлялись последовательно как ответ на проблемы, которые не могли быть решены в рамках предыдущей архитектуры.

Например, SOA появилась после того, как в процессе развития вычислительной техники появилось множество корпоративных систем, никак не связанных друг с другом, и созданных разными производителями. Потребовался некий «клей», который позволил бы интегрировать разнородные системы и заставить их работать в рамках предприятия как единое целое. Или хотя бы обмениваться данным. В результате появились общепризнанные стандарты форматирования данных (XML, JSON), обмена данными и вызова методов внешних приложений (SOAP, REST API). Появился взгляд на приложение как на службу (service), которая предоставляет определенные услуги другому приложению, используя стандартизованные форматы данных и протоколы обмена.

Начало

Аналогичным образом зародились микросервисы. Крупные компании, предоставляющие публичные сервисы, обнаружили, что с ростом количества посетителей возрастает нагрузка на инфраструктуру, увеличивается стоимость простоя в случае сбоя системы, усложняется установка обновлений. Кроме того, команда разработчиков сталкивается со все большими проблемами при разработке и установке обновлений системы. Трудности нарастают как снежный ком.

Одними из первых микросервисы начали применять разработчики компаний eBay и Amazon.

Например, в Amazon миграция с монолита началась примерно в 2002 году. Новая архитектура состояла из набора слабо связанных сервисов. За каждый сервис отвечала команда «на две пиццы» (в терминологии Amazon) — достаточно компактная для того, чтобы всех ее членов можно было накормить двумя пиццами. Компания Amazon приняла на вооружение эту архитектуру, чтобы ускорить темпы разработки, активизировать инновации и повысить конкурентоспособность. Результаты оказались впечатляющими: как сообщается, изменения на промышленном уровне в Amazon происходят каждые 11,6 секунды!

В настоящее время большинство крупнейших компаний, работающих в публичных сетях, перешли на микросервисную архитектуру.

Вот неполный список:

Отечественные компании тоже стараются не отставать от трендов:

Кому и зачем это нужно?

Прочитав статьи о новых технологиях, разработчики обычно сразу бросаются их изучать и внедрять. Это нормально. Но для большой корпоративной/коммерческой системы такой подход, мягко говоря, нежелателен. Если система находится в промышленной эксплуатации, то любые изменения несут в себе серьезные риски. Кроме того, нужно еще доказать руководству пользу, которую получит компания от перехода на новую архитектуру. В каких же случаях внедрение микросервисной архитектуры оправдано? Однозначного ответа нет. Если количество пользователей системы постоянно растет, и при этом требуется обеспечить бесперебойную работу системы в режиме 24/7, если время простоя стоит дорого, если требуется обеспечить адекватную реакцию системы на резкое увеличение нагрузки, если вносить изменение в систему с каждым разом становится все сложнее, то стоит подумать о постепенном внедрении микросервисной архитектуры.

Итак, микросервисная архитектура интересна разработчикам, так как ее изучение и внедрение позволяет удовлетворить профессиональное любопытство и повысить компетенции.

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

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

А как?

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

Существует несколько стратегий перехода от монолита к микросервисам:

1. Реализация новых возможностей в виде сервисов.
2. Разделение уровня представления и внутренних компонентов.
3. Разбиение монолита путем оформления функциональности в виде сервисов.

Первая стратегия предотвращает дальнейшее развитие монолита. Она позволяет быстро продемонстрировать выгоду от использования микросервисов, помогая заручиться поддержкой руководства. Две другие стратегии разбивают монолит на части.

Второй подход может стать полезным в процессе рефакторинга, а без третьего вы точно не обойдетесь, поскольку именно так функциональность переносится из монолита в удушающее приложение.

Реализация новых возможностей в виде сервисов

Если у вас есть большой и сложный монолитный проект, прекратите добавлять в него новые возможности, иначе он станет еще более крупным и неуправляемым. Вместо этого новые функции следует реализовывать в виде сервисов. Это отличный способ начать перевод монолитного приложения на микросервисную архитектуру, снизив темпы его развития. Данный подход ускоряет реализацию новых функций, поскольку разработка происходит в совершенно новой кодовой базе. Он также позволяет быстро продемонстрировать выгоды от перехода на микросервисы.

Интеграция нового сервиса с монолитом

Архитектура приложения после реализации новой возможности в виде сервиса показана на рисунке. Помимо нового сервиса и монолита, она содержит два других компонента, которые интегрируют новый код в приложение:

• API-шлюз — направляет запросы новой функциональности к новым сервисам, а старые запросы — к монолиту;
• Интеграционный связующий код — интегрирует сервисы в монолит. Позволяет сервису обращаться к данным и функциям, принадлежащим монолиту.

Интеграционный код не является самостоятельным компонентом. Он состоит из адаптеров к монолиту и сервисов, которые применяют один или несколько механизмов межпроцессного взаимодействия.

В идеале каждая новая возможность должна быть реализована в удушающем приложении, а не в монолите. Для этого создается новый или дополняется уже существующий сервис. Таким образом вы сможете избежать дальнейшей модификации монолитного кода.

Разделение уровня представления и внутренних компонентов

Одна из стратегий сокращения монолитного приложения заключается в отделении уровня представления от бизнес-логики и слоя доступа к данным. Типичное промышленное приложение включает следующие слои:

• Логика представления — состоит из модулей, которые обрабатывают НТТР-запросы и генерируют HTML-страницы с пользовательским веб-интерфейсом. В приложениях, обладающих сложным пользовательским интерфейсом, слой представления занимает существенную часть кода.
• Бизнес-логика — состоит из модулей, реализующих бизнес-правила. В промышленных приложениях может быть довольно сложной.
• Логика доступа к данным — состоит из модулей для доступа к инфраструктурным сервисам, таким как базы данных и брокеры сообщений.

Уровень представления обычно четко отделен от бизнес-логики и прослойки для доступа к данным. Бизнес-логика обладает обобщенным API с одним или несколькими фасадами, которые ее инкапсулируют.

Этот API представляет собой естественный шов, вдоль которого монолит можно разделить на два более мелких приложения.

Разбивка монолита путем оформления функциональности в виде сервисов

Реализация новых возможностей в виде сервисов и отделение клиентского веб приложения от внутренних компонентов — это лишь полдела. Вам все равно придется активно работать с кодовой базой монолита. Если вы хотите существенно улучшить архитектуру своего приложения и ускорить темпы разработки, разбейте монолит на части, постепенно перенося его бизнес-возможности в сервисы. При использовании этой стратегии количество бизнес-возможностей, реализованных в виде сервисов, будет постепенно увеличиваться, а монолитный код — понемногу сокращаться.

Итоги

В этой статье мы лишь немного прикоснулись к огромному, увлекательному, динамично развивающемуся миру микросервисов. К настоящему времени написано большое количество книг и статей, разработаны компоненты, шаблоны, фреймворки…

И все это продолжает разрастаться бешеными темпами. Чтобы не отстать от прогресса с одной стороны, и не потеряться в этом огромном море информации и технологий с другой, желательно, для начала, прочитать несколько книг (ниже), и начинать грызть монолиты!

А почитать?

1. Ньюмен С. Н93 Создание микросервисов. — СПб.: Питер, 2016.
2. Кочер П. С. К55 Микросервисы и контейнеры Docker – М.: ДМК Пресс, 2019.
3. Хорсдал К. Х82 Микросервисы на платформе .NET. — СПб.: Питер, 2018.
4. Ричардсон К. Р56 Микросервисы. Паттерны разработки и рефакторинга. — СПб.: Питер, 2019.

Дмитрий Лукин, руководитель проектов