Микросервисная архитектура

Микросервисная архитектура (microservices architecture, MSA) — это способ построения приложений, которые состоят из независимых друг от друга небольших модулей. Такие приложения называют микросервисами (microservices / MS). 

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

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

Микросервис и монолит

В противовес микросервисам существует так называемая монолитная архитектура программы — когда все приложение рассматривается как единое целое. Программа-монолит может состоять из модулей, но они тесно связаны друг с другом и не могут существовать один без другого. Их нельзя просто убрать или заменить. Если изменить один модуль, изменятся и другие.

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

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

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

Сложнее обновлять. Монолитная архитектура довольно консервативна: чтобы что-то добавить или убрать, понадобится переделывать всю программу целиком. Это требует больше времени, затрат, труда разработчиков. Кроме того, использовать можно не все инструменты. Не получится просто так переделать legacy-код под новые стандарты или внедрить новый стек технологий: нужно выбирать инструменты, совместимые с изначальной архитектурой. А если проблема обновления стоит остро — переписывать весь код.

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

Для чего нужны микросервисы

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

• иметь возможность дорабатывать и изменять каждый блок по отдельности; 
• упростить обновления и развитие продукта;
• повысить отказоустойчивость всей системы;
• более эффективно распределить мощности по частям системы;
• лучше разделить обязанности внутри команды: каждый может делать что-то свое и не беспокоиться, как это повлияет на весь остальной продукт.

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

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

Особенности микросервисов

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

Сообщение. Модули независимы, но общаются друг с другом и обмениваются информацией. Это обычно делают по схеме, которую называют Smart endpoints and dumb pipes — умные конечные точки и глупые каналы. Так называется паттерн, когда обработкой входящих и исходящих сообщений занимаются сами отправители и получатели — то есть модули. А каналы просто передают информацию и больше ничего не делают. Обычно микросервисы «общаются» по сети с помощью простых API.

Команда. Микросервисная архитектура накладывает свои требования к команде разработки. Есть мнение, что для каждого модуля нужен свой разработчик, а отдельно стоит выделить DevOps-инженера и других «глобальных» специалистов. Другое мнение гласит, что команда должна быть такой, чтобы ее можно было накормить двумя коробками пиццы — это правило в свое время внедрил Amazon.

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

В реальном мире при создании микросервисов чаще всего пользуются JavaScript для веб-модулей, C++ и Go для нагруженных модулей, которые должны работать быстро, Java для энтерпрайза и Python для вычислений и аналитики.

Инструменты и среды. Можно использовать любые библиотеки и фреймворки, которых требует задача. Но есть инструменты, которые необходимы любому микросервисному продукту. Это ПО не для конкретных модулей, а для менеджмента всей системы и настройки среды выполнения:

• Docker для контейнеризации данных;
• Kubernetes для управления контейнерами;
• системы для CI/CD — непрерывной интеграции и развертывания;
• сервисы для мониторинга и записи логов о работе приложения;
• инструменты для Service Discovery — автоматического обнаружения сервисов.

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

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

Скажем, «ЯндексGo» последние годы можно использовать не только для заказа такси, но и для пересылки вещей, просмотра маршрутов общественного транспорта или аренды самоката. Это суперапп, и сложно представить, чтобы такой набор сложных функций реализовали монолитно. А еще на микросервисную архитектуру давно перешли такие крупные проекты, как Twitter (X) или Amazon.

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

Отличия микросервиса от SOA

Похожий подход к архитектуре приложений — это SOA, или сервисно-ориентированная архитектура. Некоторые даже считают, что микросервисы и SOA по сути одно и то же. Это не совсем так. Скорее, микросервис можно назвать частным случаем SOA и одним из способов ее реализовать.

• В SOA входит большое количество подходов к разработке. Например, архитектура CORBA, или общая архитектура опосредованных запросов к объектам. Эти подходы необязательно похожи на микросервисы.
• В среднем SOA-приложения имеют меньшую степень гранулярности, то есть разбиения на мелкие части. В микросервисном приложении может быть несколько десятков или даже сотен модулей, а в SOA — в среднем не больше десяти.

SOA можно рассматривать как промежуточный этап при переходе от монолита к микросервисам.

Кто разрабатывает микросервисы

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

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

Отличительная особенность микросервисов тут — необходимость иметь в команде DevOps-инженера. Без него управлять всей этой системой из сервисов очень сложно.

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

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

Удобные обновления. Если нужно что-то обновить — можно изменить только несколько сервисов и не трогать остальные. Не понадобится переписывать все, ведь модули независимы. А еще ненужные модули можно просто убрать, и это не слишком повлияет на работу системы в целом. Разворачивать обновления тоже проще, ведь заново запускать приходится не весь продукт целиком, а только отдельный сервис. 

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

Возможность выбирать технологии. С микросервисами продукт не «привязан» к конкретному языку программирования и стеку инструментов. Правда, обязательно нужны системы для управления модулями — но даже тут можно выбрать из нескольких вариантов.

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

Наглядный контроль качества. Если в монолитной команде выше вероятность подхода «все отвечают за всё», то с микросервисами задачи легче распределить между командами. Каждый делает что-то свое, его результаты можно наглядно оценить. Качество выполнения задач проще отследить, а еще структурированными командами легче управлять.

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

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

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

Потребность в DevOps. Этот пункт вытекает из предыдущего. Микросервисная архитектура накладывает ограничения на методологию и состав команды. Без методологии DevOps микросервисное приложение практически невозможно поддерживать — из-за необходимости мониторить и оркестрировать модули. В целом повышается операционная сложность, растут требования к специалистам.

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

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

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

Для каких приложений подходит микросервисная архитектура

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

• cloud native — архитектура облачных приложений очень часто построена на микросервисах. Облако идеально подходит для системы из слабо связанных между собой маленьких частей;
• супераппы и многофункциональные программы — чем больше компонентов и модулей, тем выше потребность в MSA. Особенно если эти модули в идеале нужно реализовать с помощью разных технологий;
• приложения с объемным кодом — сложно переписывать его целиком ради каждого обновления;
• программы, компоненты которых нагружаются по-разному или нагрузка «плавает» в зависимости от внешних факторов. Например, онлайн-магазины с сезонным спросом;
• приложения, для которых критичны быстрые обновления и непрерывная доставка — например, связанные с меняющимися трендами;
• приложения с большими командами разработчиков — это не характеристика программы как таковой, но тоже аргумент в пользу микросервисов. Чем больше людей в команде, тем сложнее поддерживать монолит: каждому приходится держать в голове работу всех остальных.