Микросервисные архитектуры: больше, чем сумма частей?

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

Не существует четкого, единого определения того, что такое микросервисы. Это не только технология программного обеспечения, но и методология разработчика: как лучше всего добиться успеха в большом проекте по программированию? Как правило, проекты, которые считаются «микросервисами», следуют философии Unix Кена Томпсона: «Делай что-то одно и делай это хорошо». Это можно резюмировать так: сосредоточьтесь на одной задаче и доведите ее до совершенства. Это утверждение относится не только к программированию, но и описывает функциональность отдельных микросервисов.

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

Архитектура микросервисов, по сути, является дальнейшим развитием сервис-ориентированной архитектуры (SOA): небольшие сервисы также играют роль в этом архитектурном паттерне. Однако они все еще встроены в большую систему и не настолько независимы, как хотелось бы. Так же, как нет четкого определения для первого, SOA — довольно расплывчатый термин. Поэтому переходы между этими двумя паттернами очень подвижны.

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

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

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

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

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

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

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

В конце концов, все аспекты объединяются: как бы ни отличались микросервисы по структуре, в конечном итоге у них должны быть общие точки соприкосновения. Они должны быть как можно более простыми, чтобы соединения оказывали незначительное влияние на реальный процесс. Именно поэтому большинство разработчиков микросервисов используют REST API. Унифицированные, оптимизированные методы HTTP, такие как GET или POST, позволяют отдельным микросервисам легко общаться и обмениваться информацией.

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

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

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

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

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

В настоящее время микросервисная архитектура нашла свое применение в системах крупных компаний. Впоследствии компании смогли устранить определенные проблемы или оптимизировать свои процессы. Такие примеры, как Netflix, Spotify и eBay, показывают, как крупные компании с устоявшимися монолитными системами переходят на микросервисную модель. Другие крупные ИТ-компании, такие как Google и Amazon, также работают подобным образом. Некоторые из них уже использовали модульные системы, когда для них еще не было термина.

Как и многие другие компании, Netflix раньше базировалась на монолитной системе (в те времена, когда Netflix не была онлайн-сервисом потокового вещания, а только отправляла DVD-диски по почте). В 2008 году в базе данных произошла ошибка, из-за которой весь сервис не работал в течение четырех дней. Тогда было принято решение разрушить старую систему и разделить ее на микросервисы. В результате компания смогла гораздо быстрее вносить изменения в реальном времени, а ремонтные работы проводились гораздо быстрее. Поскольку система Netflix чрезвычайно обширна, была разработана отдельная программа для организации отдельных микросервисов между собой: Conductor.

Conductor предоставляет Netflix централизованный контроль для приостановки, перезапуска или масштабирования своих микросервисов. Ядром программы является сервис под названием Decider. Он может автоматически планировать процессы и реагировать на события в рабочем процессе. Другие программы, разработанные Netflix для эффективной работы со своими микросервисами, — Mantis (обработка потоков), Dynomite (хранение данных) и Vizceral (интуиция трафика).

Потоковый сервис Spotify также полагается на микросервисы. Главная ежедневная задача Spotify в области разработки — опередить сильную конкуренцию. На рынке потоковых аудиоуслуг основными игроками являются крупнейшие IT-компании мира — такие как Amazon, Apple и Google. Из-за растущего числа пользователей разработчикам Spotify постоянно приходится удовлетворять повышенные требования и соблюдать определенные бизнес-правила (например, лицензионные права). Микросервисы — хорошее решение для Spotify, позволяющее быстро реагировать на новые разработки конкурентов и быстрее публиковать собственные разработки, заставляя конкурентов реагировать в свою очередь.

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

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

Как и многие другие крупные системы, торговая платформа eBay начиналась как монолит: в eBay было 3,4 миллиона строк кода только в одном файле. Затем компания решила разрушить монолит и разработать вместо него Java-микросервисы. Отдельные сервисы eBay также используют REST для взаимодействия друг с другом.

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

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

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

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

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