Микросервисная архитектура: как работает и каким компаниям нужна

В этом материале

• Принципы программной инженерии
• Преимущества и недостатки микросервисной архитектуры
• Примеры использования микросервисной архитектуры
• Как понять, что компании нужна микросервисная архитектура

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

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

Разработчики заговорили об этой проблеме в начале 1960-х. А в 1968 году на конференции по программному обеспечению (ПО) в Гармиш-Партенкирхене эксперты предложили ряд идей, которые легли в основу отдельной дисциплины — «программная инженерия» (пишет издание «Открытые системы»). Она состоит из принципов, помогающих разработчикам заниматься созданием ПО, соблюдая заданные сроки и даже небольшой бюджет. 

Принципы программной инженерии

• Модульность. Система должна разбиваться на отдельные автономные компоненты, или модули, каждый из которых выполняет определённую функцию.
• Связанность. Между модулями и компонентами должно быть минимальное количество связей.
• Универсальность. Компоненты должны быть созданы так, чтобы их можно было повторно использовать, но уже в других проектах.
• Абстракция. При проектировании необходимо руководствоваться «методом чёрного ящика», который позволяет фокусироваться на функциональности компонентов без погружения в детали их внутреннего устройства.
• CI/CD (непрерывная интеграция и доставка). Процесс сборки, тестирования и развёртывания программного обеспечения должен быть автоматизирован.

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

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

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

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

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

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

Первыми этот путь прошли компании, которые ежедневно сталкиваются с проблемами в работе высоконагруженных и крайне сложных систем. В процессе  работы они постепенно разрабатывали и унифицировали набор инструментов и технологий. А после того как они опубликовали  наработки под открытой лицензией, возможность использования микросервисов стала доступной в средних, а иногда и в малых проектах, что привело к её широкому распространению. Это подтверждает исследование, из которого следует, что 77% процентов опрошенных компаний уже используют микросервисную архитектуру, при этом каждая шестая переносит от 75 до 100% систем на микросервисы. 

В России тоже много примеров. Так, крупный российский ритейлер давно развивает собственную микросервисную архитектуру для оптимизации электронной коммерции и повышения гибкости разработки (сообщает «Хабр»). Из тех же соображений на микросервисную архитектуру перешёл другой онлайн-ритейлер, что позволяет ему регулярно обновлять отдельные функции платформы, не подвергая риску другие части системы (пишут на «Хабр»). «Лаборатория Касперского» активно использует микросервисную архитектуру, что позволяет повысить надёжность и масштабируемость продуктов, а также облегчить процесс  улучшения и обогащения новыми функциями.

Преимущества и недостатки микросервисной архитектуры

Переход с монолитного решения на микросервисы даёт ещё несколько преимуществ. 

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

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

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

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

Также использование микросервисов несёт дополнительные издержки на оборудование и работы. Построение конвейера сборки и развёртывания на основе kubernetes требует, по нашим наблюдениям, минимум семь серверов (в каждом 24 ядра CPU и 24GB ОЗУ) и двух инженеров на полную ставку, обладающих компетенциями в администрировании и разработке. При этом в состав оборудования не входят мощности для подсистемы хранения (СУБД, Ceph, S3 и т. д.) и подсистемы очередей (Kafka, Rabit MQ и т. д.).

Как понять, что компании нужна микросервисная архитектура

Если вы задумались о переходе к микросервисной архитектуре, то надо честно ответить на следующие вопросы.

• Достигла ли стоимость масштабирования за счёт увеличения мощности «железа» физического или финансового потолка?
• Разрослась ли структура монолитного решения до размеров, когда ни один участник команды не в состоянии предсказать, каким будет результат после внесения изменения, а падения при каждом релизе стали нормой?
• Вы не можете обновлять свой технологический стек, так как есть блокеры в виде компонентов, которые не могут работать на новых версиях фреймворков?
• Вы стали зависимы от одного или нескольких вендоров, чьи проприетарные решения стоят в основе вашего ИТ-ландшафта?
• План выхода релизов растянулся во времени и перестал успевать за запросами рынка?

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

• Чтобы быть в курсе важных трендов и мнений ведущих экспертов, следите за нами в телеграм-канале. О развитии навыков управления, личностном росте пишем в «Дзене». Про технологии и развитие в IT — в блоге на VC.