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

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

Рассмотрим таблицу 8.4. Если вы отметите «да» для трех или более признаков, то, скорее всего, вы работаете с монолитной архитектурой.

Таблица 8.4. Признаки микросервисной и монолитной архитектуры

Микросервисы – это искусство разделения системы на отдельные «мини-приложения» с узкой областью применения, выполняющие определенное действие или функцию. Взаимодействие между ними осуществляется через API, служебную шину (service bus) или очередь сообщений. Надежный микросервис – это независимый компонент со своим собственным хранилищем данных, средой выполнения (на основе подходящего языка/библиотеки) и релизным циклом, который не влияет на другие части системы.

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

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

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

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

Микросервисы дают возможность внесения изменений в будущем и позволяют отложить технологические решения в какой-то области. Создав надежный, согласованный API, вы можете развивать реализацию сервиса со временем, по мере необходимости. Если, например, вам нужно сохранять и раздавать файлы для всей системы – вы можете создать микросервис для работы с файлами (File MS).

Этот File MS будет иметь два простых API: принимающий файл для сохранения и возвращающий файл. Первая версия реализации может просто хранить файл в локальном каталоге (с резервной копией). По мере развития сервиса она может хранить файл в сети SAN с большей емкостью. Если сервис становится очень востребован, можно использовать для его реализации облачный сервис, такой как Amazon S3.

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

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

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

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

Звучит знакомо? Да – именно так работают все современные облачные провайдеры. AWS – это всего лишь набор микросервисов, каждый из которых предоставляет свой функционал через API-интерфейсы, которые вы оплачиваете по мере использования.

Подавляющее большинство сервисов AWS возникло благодаря необходимости поддерживать основные сайты торговой площадки Amazon. Библиотека микросервисов AWS стала настолько мощной, что появилась возможность продавать функциональность внешним разработчикам – то есть нам с вами. Хотя ваша компания, может быть, и не станет следующей AWS, надежная микросервисная архитектура позволит вам стать ближе к клиентам и предоставлять им доступ к вашим API, чтобы они могли выстраивать свою собственную экосистему на основе предоставляемых вами услуг.