Главная
Микросервисная архитектура: как работает и каким компаниям нужна
С ростом нагрузки и ограничений в виде физических возможностей оборудования практически любое решение проходит путь от монолитной структуры к микросервисной. Микросервисная архитектура простыми словами — это система, которая состоит из отдельных модулей, каждый из которых отвечает за определенный функционал. Такая распределенная система отличается гибкостью в разработке и широкими возможностями масштабирования.
Что это значит для бизнеса?
Подробности — в полной версии материала.
В этом материале
Микросервисная архитектура (MSA, microservices architecture) — это архитектура программного обеспечения, которая состоит из комплекса отдельных модулей (микросервисов), обеспечивающих выполнение независимых функций. Такая распределённая система отличается гибкостью в разработке и широкими возможностями масштабирования.
Цифровые услуги — от получения паспорта до стриминговых площадок с музыкой и видео или доставки еды на дом — делают жизнь ярче и динамичнее. Но к сервису человек быстро привыкает, воспринимает его стабильную работу как данность, а в случае проблем, например регулярных ошибок или медленной загрузки, начинает искать альтернативу.
И, с одной стороны, разработчики постоянно расширяют функционал сервисов, чтобы удерживать интерес пользователей, а с другой — должны поддерживать их стабильную работу. Но между этими задачами есть противоречие: появление новых функций неизбежно влияет на стабильность работы, и владельцу сервиса необходимо уметь управлять сложностью продукта.
Разработчики заговорили об этой проблеме в начале 1960-х. А в 1968 году на конференции по программному обеспечению (ПО) в Гармиш-Партенкирхене эксперты предложили ряд идей, которые легли в основу отдельной дисциплины — «программная инженерия» (пишет издание «Открытые системы»). Она состоит из принципов, помогающих разработчикам заниматься созданием ПО, соблюдая заданные сроки и даже небольшой бюджет.
В 1968
году
были заложены принципы программной инженерии
Принципы программной инженерии
Если следовать этим принципам, то с ростом нагрузки и ограничений в виде физических возможностей оборудования практически любое решение проходит путь от монолитной структуры к микросервисной.
Это связано с тем, что при коллективной работе над модулями в рамках одного репозитория (места, где хранятся данные) кода удерживать область ответственности каждого модуля становится трудоёмкой и дорогой задачей. Внесение изменений требует тщательной верификации участниками команды разработки и архитекторами, в процессе чего возникает много коммуникаций, в основе которых лежит субъективное мнение о том, какие функции следует включать в состав каждого модуля.
Когда время поставки изменений падает до критического уровня, единый репозиторий кода разделяют на несколько репозиториев, каждый из которых отвечает за один модуль, а протоколы взаимодействия между модулями фиксируются в контрактах. За каждым репозиторием назначают ответственного за его функционал, ограничивая остальные команды в правах на внесение изменений в его функциональность.
Такой же процесс происходит со структурой базы данных. Каждый модуль нуждается в своей структуре, и все команды приходят к состоянию, когда каждый модуль работает со своей структурой, не зависящей от остальных модулей.
В итоге у каждого модуля формируется собственная команда разработки с собственным списком задач и релизным циклом. При правильно разработанных KPI для модульных команд каждая из них начинает стремиться минимизировать зависимости от других команд, самостоятельно находя баланс между зависимостью от функционала чужих модулей и скоростью поставки изменений.
Разумеется, это вызывает рост накладных расходов на управление, сборку и развёртывание конечного решения, в связи с чем возникает потребность в изменении производственных процессов и автоматизации рутинных операций. Запрос на внедрение практик DevOps появляется естественным образом, и это не вызывает отторжения у участников модульных команд.
Первыми этот путь прошли компании, которые ежедневно сталкиваются с проблемами в работе высоконагруженных и крайне сложных систем. В процессе работы они постепенно разрабатывали и унифицировали набор инструментов и технологий. А после того как они опубликовали наработки под открытой лицензией, возможность использования микросервисов стала доступной в средних, а иногда и в малых проектах, что привело к её широкому распространению. Это подтверждает исследование, из которого следует, что 77% процентов опрошенных компаний уже используют микросервисную архитектуру, при этом каждая шестая переносит от 75 до 100% систем на микросервисы.
В России тоже много примеров. Так, крупный российский ритейлер давно развивает собственную микросервисную архитектуру для оптимизации электронной коммерции и повышения гибкости разработки (сообщает «Хабр»). Из тех же соображений на микросервисную архитектуру перешёл другой онлайн-ритейлер, что позволяет ему регулярно обновлять отдельные функции платформы, не подвергая риску другие части системы (пишут на «Хабр»). «Лаборатория Касперского» активно использует микросервисную архитектуру, что позволяет повысить надёжность и масштабируемость продуктов, а также облегчить процесс улучшения и обогащения новыми функциями.
Преимущества и недостатки микросервисной архитектуры
Переход с монолитного решения на микросервисы даёт ещё несколько преимуществ.
Первая особенность связана со снижением времени, которое требуется разработчику для того, чтобы разобраться с устройством микросервиса и приносить пользу команде. В случае со сложным монолитным решением на это требуется больше времени.
Второе и третье преимущества перехода на микросервисы дают технологии оркестрации: возможность динамически масштабировать систему путём клонирования сервисов и автоматического запуска нового экземпляра в случае падений идёт «из коробки». Причём оркестратор берёт на себя и распределение нагрузки между ними.
Разумеется, помимо достоинств, микросервисная архитектура обладает и рядом недостатков.
Самой серьёзной считается проблема синхронизации данных между компонентами. Используя микросервисный подход, мы получаем распределённую систему. Вместо единой транзакции, которая происходила в монолитной структуре, на одну бизнес-операцию выполняется множество микротранзакций внутри отдельных микросервисов. Для некоторых типов систем такое поведение недопустимо, а в остальных случаях нужно учитывать альтернативные сценарии для обработки отказов, которые могут произойти в цепочке распределённых вызовов. И чем больше транзакций происходит в рамках одной бизнес-операции, тем сложнее становится разработка.
Также использование микросервисов несёт дополнительные издержки на оборудование и работы. Построение конвейера сборки и развёртывания на основе kubernetes требует, по нашим наблюдениям, минимум семь серверов (в каждом 24 ядра CPU и 24GB ОЗУ) и двух инженеров на полную ставку, обладающих компетенциями в администрировании и разработке. При этом в состав оборудования не входят мощности для подсистемы хранения (СУБД, Ceph, S3 и т. д.) и подсистемы очередей (Kafka, Rabit MQ и т. д.).
Примеры использования микросервисной архитектуры
Веб-приложения
Микросервисную архитектуру используют крупные торговые онлайн-площадки — маркетплейсы. За каждую функцию (каталог, личный кабинет, корзину, финтех-сервисы и так далее) отвечает отдельный модуль. Между собой они взаимодействуют через API (англ. application programming interface — «интерфейс программирования приложений»).
Мобильные приложения
На микросервисной архитектуре создано мобильное приложение СберБизнес, которое содержит два типа модулей — продуктовые и кросс-продуктовые (сообщает «Хабр»). При работе они берут данные с серверов и друг у друга.
Облачные вычисления
В облачных вычислениях микросервисная архитектура считается наиболее оптимальной и эффективной, так как помогает быстро масштабировать приложения без потерь в производительности (пишет TAdviser). Сейчас это стандарт в разработке большинства облачных сервисов.
IoT (интернет вещей)
На микросервесной архитектуре работают платформы по сбору, анализу и хранению данных, поступающих от IoT-устройств сообщает журнал «Control Engineering Россия»). Отдельные модули отвечают за настройки датчиков, обработку данных, геопозиционирование и другие функции.
Крупные корпоративные системы
Микросервисная архитектура часто применяется при разработке корпоративных ИТ-систем. Например, такой подход популярен среди компаний, использующих Agile-методологию, так как он соответствует принципам гибкости и большого количества итераций.
Как понять, что компании нужна микросервисная архитектура
Если вы задумались о переходе к микросервисной архитектуре, то надо честно ответить на следующие вопросы.
При каждом положительном ответе постарайтесь оценить его влияние на бизнес, и если совокупные потери превышают стоимость перехода, то пора начинать. Как было сказано выше, это естественный процесс роста, и вы можете себя поздравить с тем, что наступило время и вам пройти этот сложный путь к новому уровню свободы, доступности, производительности и скорости развития.