Благодаря тому, что части приложения автономны, его, как и любую распределённую систему, легко развивать и обновлять: добавление или улучшение отдельных функций никак не повлияет на остальные компоненты. И это главное отличие микросервисного приложения от монолитного, в котором все блоки кода связаны между собой, и даже небольшие изменения хотя бы в одном из них поменяют работу всей системы.
Микросервисная архитектура: что это, кому подойдёт, с чего начать
Рассказываем про микросервисную архитектуру: чем она отличается от монолитной, кому подойдет такой подход и какие инструменты использовать для создания микросервисов.
31 марта 2022 г.
11 минут чтения
Что такое микросервисная архитектура
Чем быстрее идея воплотится в новый продукт или в существующий проект, тем больше у вас шансов занять нишу и завоевать лояльность пользователей, а значит, стать успешнее и популярнее конкурентов.
Микросервисная архитектура — это подход, который помогает не только ускорить разработку продукта, но и сделать ее гибкой и управляемой: проект из неделимого целого превращается в систему связанных между собой блоков — сервисов. Впервые о микросервисах заговорили ещё в 2000‑х, но концепция архитектуры сформировалась только к началу 2010‑х. К 2014 году технологию внедрили такие крупные компании, как Netflix, Amazon и Twitter. Сегодня микросервисный подход используют гораздо активнее. В 2020 году в отчёте Cloud Microservices Market Research рынок облачных микросервисов оценили в 831,45 млн долларов США. К 2026 году его масштабы могут увеличиться более чем в три раза.
Микросервисная архитектура vs монолитная
Приложение с микросервисной архитектурой разделено на небольшие не зависящие друг от друга компоненты — микросервисы. У каждого из них своя бизнес-задача: например, управлять каталогом, хранить и обновлять содержимое корзины или проводить оплату заказа.
Для наглядности покажем, как выглядит архитектура микросервисов в Yandex Cloud.
| Микросервисное приложение | Монолитное приложение |
|---|---|
| Скорость релизов | Скорость релизов |
| Чтобы запустить новые функции или обновить существующие, достаточно изменить один модуль приложения. Это позволяет ускорить разработку и чаще выпускать обновления. | Чтобы протестировать релиз и подготовить к нему приложение, нужно обновить всю систему, что может привести к неожиданным сбоям и увеличить время отладки. |
| Диапазон технологий | Диапазон технологий |
| Для каждого сервиса можно использовать свой язык программирования, способ хранения данных, необходимые библиотеки. | Код монолитного приложения — единое целое, поэтому вся команда должна придерживаться уже выбранных инструментов и методов. |
| Процесс разработки | Процесс разработки |
| Микросервисная архитектура позволяет вести гибкую разработку и при необходимости быстро изменить состав команды или требования к продукту. | Монолитный подход более требователен к порогу вхождения: каждому новичку придётся полностью изучить код системы и её функциональность. |
| Оптимизация приложения | Оптимизация приложения |
| Управление ресурсами, инфраструктурой и функциональностью приложения можно доверить разным сервисам и оптимизировать каждый из них по отдельности. | При оптимизации монолитного приложения нужно постоянно учитывать внутренние связи между его модулями: обновление хотя бы в одного из них приведёт к изменению системы в целом. |
| Масштабируемость | Масштабируемость |
| Если нагрузка на ресурсы микросервисов увеличится, они масштабируются автоматически. А гибкий процесс разработки позволит усилить команду дополнительными сотрудниками. | Если вы решите изменить хотя бы один блок, придётся масштабировать всё приложение. |
| Отказоустойчивость | Отказоустойчивость |
| Проблемы внутри одного сервиса не нарушат работу системы в целом и не приведут к появлению новых ошибок. | Все элементы монолитного приложения связаны друг с другом напрямую или косвенно: сбой внутри одного модуля может вызвать полный отказ системы |
Конечно, микросервисный подход не лишён недостатков. При кажущейся простоте и логичности деления большого продукта на самостоятельные сервисы разработка распределённой системы — процесс сложный и с технической, и с организационной точек зрения. Плюсы могут обернуться минусами:
- Сбой одного сервиса не приведёт к полному отказу приложения, но любая распределённая система имеет и другие слабые места: потенциальные проблемы связи её элементов друг с другом, сетевые задержки, возможная неконсистентность данных.
- Вы сэкономите, если будете платить только за те ресурсы, которые потребляют микросервисы, но должны будете предусмотреть расходы на внедрение облачных технологий, отдельное развёртывание каждого нового сервиса и его покрытие отдельными тестами и мониторингами.
- Контролировать качество решения отдельных бизнес-задач проще и эффективнее, чем оценивать систему в целом, но настроить рабочие процессы большой команды разработчиков не так уж легко.
Кому подойдёт использование микросервисной архитектуры
Если вам или вашему проекту подходит хотя бы один пункт из этого списка, задумайтесь об использовании микросервисов:
- Большие коллективы. Группам разработчиков, которые работают над разными микросервисами не нужно синхронизировать друг с другом каждый шаг, выбор инструментов и другие детали. Новые фичи можно разрабатывать параллельно и запускать по мере готовности.
- Объёмные проекты со сложной архитектурой. Обновлять и поддерживать отдельные модули намного проще, чем контролировать, как изменения скажутся на системе в целом.
- Продукты с резко меняющимся трафиком. Если вашим продуктом начинают чаще пользоваться в период праздников или распродаж, микросервисы позволят вам быстро масштабироваться и уменьшить риск отказа системы. К тому же вам не придётся платить за дополнительную инфраструктуру, которая нужна только в периоды пиковых нагрузок.
- Приложения, требующие частых обновлений. Достаточно изменить и отладить только тот модуль, который вы хотите обновить. Это существенно сокращает время разработки и приближает релиз.
Говорят, что хороший микросервис должен быть небольшим, автономным, обходиться собственной изолированной базой данных и «закрывать» конкретную потребность. Чтобы проверить, стоит ли погружаться в мир микросервисов, спросите себя: можно ли разделить ваш продукт на простые независимые части?
Протестируйте инфраструктуру Yandex Cloud. Платформа даёт новым пользователям грант на 4000 рублей. Этими деньгами можно оплатить используемые ресурсы во время пробного периода. Есть и другие программы поддержки компаний. Тестирование поможет понять, насколько платформа и облачные сервисы будут эффективны в бизнес‑процессах вашей компании.
Какие инструменты использовать для создания микросервисов и работы с ними
Попробуйте создать микросервисный проект с помощью инструментов Yandex Cloud. Мы собрали всё необходимое — можете разрабатывать и развивать архитектуру на одной платформе.
-
Один из самых популярных способов создавать микросервисы — платформа контейнеризации Docker. Что такое контейнеры и как устроена эта платформа, мы рассказывали в отдельной статье. Напомним: Docker — универсальный инструмент с открытым кодом, совместимый с Windows, Linux и macOS. С его помощью приложение отделяется от инфраструктуры: это значит, что вы сможете беспроблемно перемещаться между облачным и локальным хранилищем. Для управления образами и контейнерами Yandex Cloud предлагает Yandex Container Registry — отказоустойчивое хранилище с автоматической репликацией.
-
Чтобы оркестрировать контейнеры, то есть управлять работой с ними, чаще всего используют кластеры Kubernetes®. Сервис Yandex Managed Service for Kubernetes® позволяет работать с серверами, расположенными вне платформы Yandex Cloud.
-
Неотъемлемая часть любого микросервисного проекта — балансировщик. Именно благодаря ему такую архитектуру считают более устойчивой к отказам, чем монолитную: он контролирует, чтобы нагрузка на приложение распределялась по облачным ресурсам равномерно. Попробуйте Yandex Network Load Balancer. Чтобы регулировать входящий трафик разных компонентов веб‑приложений, воспользуйтесь Yandex Application Load Balancer.
Больше о современных облачных веб-сервисах и инструментах для работы с ними — на вебинаре архитектора Yandex Cloud Нарека Татевосяна:
Кто уже выбрал микросервисную архитектуру и наши инструменты для своих проектов
-
Умный поиск SearchBooster полностью выстроил облачную инфраструктуру на Kubernetes. Через полтора года после переезда количество входящих поисковых запросов увеличилось в 150 раз, а количество индексируемых данных — в сотни.
-
Сервис Бухта, который помогает предпринимателям оцифровывать бухгалтерские и бизнес-процессы, втрое увеличил отзывчивость тестовых сред и на 40% сократил расходы на инфраструктуру.
-
Центральный НИИ эпидемиологии справился с ежедневной обработкой десятков тысяч тестов на коронавирусную инфекцию в разгар пандемии, быстро нарастив вычислительные мощности.
Ещё больше историй о микросервисных проектах, которые выбрали Yandex Cloud, вы найдете на нашем сайте.