Что такое микросервисная архитектура и с чем ее едят
Микросервисная архитектура. Часть 1: теория
Сибирикс
Микросервисная архитектура. Часть 1: теория
Что такое микросервисная архитектура и с чем ее едят
Вы создали компанию и заказали для неё сайт. Вы оказались неплохим бизнесменом: продажи растут, клиентов все больше, открываете новые филиалы. Приходится усложнять устройство сайта, чтобы удовлетворить запросы посетителей.

Внезапно возникает проблема: объём кода вырос до полного собрания сочинений Толстого, обновления разрабатываются до скончания веков, очень сложно добавить новую технологию. Программисты хватаются за голову и за неделю тратят годовой запас кофе. Что пошло не так?

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

В чём проблема монолитной архитектуры?

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

Приложения, построенные на монолитной архитектуре (или просто монолиты) — не просто огромные приложения с одной функцией. Они содержат отдельные классы и функции, однако те крепко связаны друг с другом. Изъятие одного модуля неизбежно вызывает изменения в работе всей системы.

Хоть монолитная архитектура и устоялась в качестве привычной для многих сервисов, она имеет ряд значимых недостатков:
  • Чтобы внести одно изменение, необходимо пересобрать всё приложение.
  • Невозможно масштабировать отдельный модуль — придётся переделывать всё приложение.
  • Разработка ограничена изначально выбранным набором языков программирования, фреймворков и других инструментов. Хочется использовать что-то альтернативное — извините, у нас такого нет, работайте с тем, что есть.
  • Сломался один модуль — чини весь сервис. И плати еще за это.
  • Сложная структура связей между модулями замедляет выход обновлений. Каждое требует серьезного тестирования на баги и регрессии кода (новые ошибки в уже протестированном функционале). Соответственно, в одном обновлении появляется целая кипа изменений — и не факт, что все они заработают.
  • Поначалу приложение имеет понятную структуру и быстро развивается. А потом понеслось: длинный и сложный код, рамки модулей постепенно стираются, между компонентами возникает все больше неочевидных взаимосвязей.
Сложности возникают и с командой проекта.
Закон Конвея: продукт будет повторять структуру организации, которой он создан
При разработке монолитов команда обычно делится на три группы, каждая из которых отвечает за одну из частей приложения: пользовательский интерфейс; серверную часть и базу данных. Чем больше приложение, тем больше команда. Каждому участнику потребуется владеть экспертизой по всем бизнес-функциям, что со временем все труднее. Намного больше требуется времени для добавления нового программиста в работу — пока изучишь весь километровый код.

Чем хороша микросервисная архитектура?

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

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

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

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

Из крупнейших компаний мира на микросервисную архитектуру перешли Amazon, Google, Netflix и Twitter. В России их попробовали «М.Видео-Эльдорадо», «МегаФон» и не только.
О нашем опыте ухода от монолитной архитектуры читайте во второй части обзора.