Что такое микросервис в программировании

Что такое микросервисы и как они работают?

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

Замкнутая природа микросервисной архитектуры может упростить создание проектов по разработке программного обеспечения и управление ими. Многие крупные компании, такие как PayPal, Netflix и даже Amazon, используют микросервисы, демонстрируя, что микросервисы могут быть полезным инструментом для разработки масштабируемого программного продукта.

Что такое микросервисы?
Микросервисы — это средства организации приложения с помощью нескольких независимых однофункциональных протоколов или сервисов. Стандартным архитектурным стилем для создания программных приложений является шаблон монолитной архитектуры.

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

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

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

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

• деловые возможности
• автоматическое развертывание
• интеллект конечных точек
• децентрализованный контроль над языками и данными

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

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

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

• Монолитные приложения

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

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

• Сервис-ориентированная архитектура (SOA)

• Микросервисы

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

Каковы основные области применения микросервисов?
Вы можете применить микросервисы к своей программной архитектуре по ряду причин. Ниже приведены несколько примеров, когда микросервисы могут подойти.

• Небольшие команды

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

• Тестирование и развертывание

• Разнообразные технологические стеки

6 характеристик микросервисов
Микросервисы и их непосредственные преимущества можно разделить на несколько ключевых характеристик.

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

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

3. Простая маршрутизация
Микросервисы получают запросы и отвечают на них. Просто, верно? Что ж, монолитное приложение активирует череду зависимых уровней приложения, и функциональные возможности могут сталкиваться друг с другом для достижения одной и той же конечной цели.

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

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

6. Эволюционный
Микросервисы могут расти вместе с вашим бизнесом. Добавление новых функций происходит за пределами монолитной системы, что полностью упрощает масштабируемость.

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

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

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

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

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

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

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

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

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

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

Микросервисы и API: в чем разница?
Основное различие между микросервисами и API заключается в их соответствующих функциях и классификациях.

Например, API определяет протоколы для интеграции двух или более программных систем . Вот несколько примеров API:

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

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

Видео Youtube, встроенные на веб-страницу, отличную от самой Youtube

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

Микросервисы зависят от API для подключения этих сервисов, но сами по себе они не являются API.

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

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

HR Блог для IT рекрутера в Телеграм

Хочешь всегда получать новые статьи, бесплатные материалы и полезные HR лайфхаки! Подписывайся на нас в Telegram! С нами подбор ит персонала становится проще 😉

Что такое микросервисы

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

Проблемы монолитной разработки

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

• регистрация в сервисе,
• напоминание пароля,
• создание нового списка задач,
• управление списками,
• создание новой задачи,
• редактирование задачи,
• удаление задачи.

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

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

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

Микросервисы — разбиваем программу на автономные части

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

1. Каждая смысловая часть программы выносится в отдельный код, который делает что-то одно: получает данные от сервера, отправляет логин и пароль на проверку, даёт разрешение пользователю на вход и т. д.
2. Каждая такая программа может получать и отправлять данные в каком-то формате. Благодаря этому программы могут обмениваться данными и управлять друг другом.
3. Такие мини-программы и называются микросервисами.

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

�� Главный принцип в таком подходе — сделать так, чтобы у каждого микросервиса было понятное описание, в каком формате он получает данные, в каком отправляет и куда именно отправляет.

Пример

Разобъём нашу программу из начала статьи на микросервисы:

Обратите внимание — у нас появились функциональные элементы, которых не было в исходной картинке: например отрисовка интерфейса, запрос данных от пользователя, отправка данных на сервер, запрос в БД.

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

Плюсы и минусы микросервисов

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

• Каждый микросервис можно полностью заменить или переписать без потери качества для проекта, если у него будет тот же формат общения с другими микросервисами.
• Если нужно, можно запустить одновременно несколько одинаковых микросервисов на разных компьютерах, чтобы повысить устойчивость и скорость работы приложения.
• Если какой-то микросервис откажет, то чаще всего это не приводит к падению всего сервиса или программы. Ещё можно настроить автоматический перезапуск микросервиса после аварийного завершения.
• Неважно, на каком языке написан микросервис, если он делает то, что нужно, и умеет общаться с другими. Например, для высокопроизводительных частей можно использовать С++, а для остальных — Java или Kotlin.
• Можно постепенно наращивать возможности приложения, просто подключая новые микросервисы к системе.

Но и минусы у такого подхода тоже есть:

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

Пример: работа системы под нагрузкой

Допустим, у нас есть две версии одного и того же сервиса: один сделан единым кодом, второй — на микросервисах.

Пока нагрузка в рамках нормы, оба сервиса работают примерно одинаково:

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

Это что, теперь каждую программу нужно писать на микросервисах?

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

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

Что такое микросервисы: определение, архитектура и примеры

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

Термин «микро» относится к размеру микросервиса – он должен быть удобным в управлении одной командой разработчиков (5-10 специалистов). В данной методологии большие приложения делятся на крошечные независимые блоки.

Что такое монолитная архитектура?

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

В качестве примера монолитной архитектуры давайте рассмотрим сайт для электронной торговли. Например, онлайн-магазин.

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

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

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

Давайте рассмотрим пример приложения для онлайн-торговли с микросервисной архитектурой. В данном примере каждый микросервис отвечает за одну бизнес-возможность. У «Поиска», «Оплаты», «Рейтинга и Отзывов» есть свои экземпляры (сервер), которые взаимодействуют между собой.

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

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

Микросервисы и монолитная архитектура: сравнение

Микросервисы

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

Каждый блок данных создается для решения определенной задачи; его размер должен быть предельно малым

Единая база кода для всех бизнес-целей

Запуск сервиса происходит сравнительно быстро

На запуск сервиса требуется больше времени

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

Локализовать ошибки сложно. Если какая-то определенная функция не перестает работать, то ломается вся система. Чтобы решить проблему, придется заново собирать, тестировать и развертывать приложение.

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

Монолитная архитектура тесно связана. Изменения в одному модуле кода влияет на другой

Компании могут выделять больше ресурсов на самые рентабельные сервисы

Сервисы не изолированы; выделение ресурсов на отдельные сервисы невозможно

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

Масштабирование приложения – задача сложная и экономически не выгодная

Микросервисы всегда остаются постоянными и доступными

Большая нагрузка на инструменты для разработки, поскольку процесс необходимо запускать с нуля

Федеративный доступ к данным, благодаря чему под отдельные микросервисы можно подбирать наиболее подходящую модель данных

Небольшие целевые команды. Параллельная и ускоренная разработка

Большая команда; требуется серьезная работа по управлению командой

Изменения в модели данных одного микросервиса никак не сказывается на других микросервисах

Изменения в модели данных влияют на всю базу данных

Четко прописанный интерфейс позволяет микросервисам эффективно взаимодействовать между собой

Микросервисы делают акцент на продуктах (модулях), а не проектах

Сосредоточены на проекте в целом

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

Одна функция или программа зависит от другой

Сложности в работе с микросервисами

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

Сервис-ориентированная архитектура (СОА) или микросервисы

СОА-сервисы (SOA — Service-oriented architecture) поддерживаются через реестр, который считается перечнем файлов каталога. Приложения должны найти сервис в реестре и вызвать его.

Иначе говоря, СОА похож оркестр: каждый музыкант играет на своем инструменте, а всеми артистами управляет дирижер.

Микросервисы – это разновидность СОА-стиля. Приложения создаются в виде набора небольших сервисов, а не цельной программы.

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

Теперь давайте поговорим о различиях между СОА и микросервисах.

Параметр

СОА

Микросервисы

В СОА компоненты приложения открыты для внешнего мира; они доступны в виде сервисов

Микросервисы – это часть СОА. Такая архитектура считается реализацией СОА

Они не зависят друг от друга

Размер приложения больше, чем у обычных программ

Размер приложения всегда небольшой

Стек технологий ниже, чем у микросервисов

Стек технологий очень большой

Независимость и ориентированность

СОА-приложения создаются для выполнения множества бизнес-задач

Создаются для выполнения одной бизнес-задачи

Процесс развертывания растянут по времени

Несложное развертывание, на которое тратится меньше времени

Меньше, чем у микросервисов

Компоненты бизнес-логики хранятся внутри одного сервисного домена. Простые проводные протоколы (HTTP с XML JSON).
API управляется с помощью SDK/клиентов

Бизнес-логика распределена между разными корпоративными доменами

Микросервисные инструменты

Wiremock – тестирование микросервисов

WireMock – это гибкая библиотека для создания заглушек и сервисов-имитаций. В ней можно настроить ответ, который HTTP API вернет при получении определенного запроса. Также может использоваться для тестирования микросервисов.

Docker

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

Hystrix

Hystrix – это отказоустойчивая Java-библиотека. Данный инструмент предназначен для разделения точек доступа к удаленным сервисам, системам и сторонним библиотекам в распределенной среде (микросервисах). Библиотека улучшает всю систему в целом, изолируя неисправные сервисы и предотвращая каскадный эффект от сбоев.

Лучшие примеры использования микросервисной архитектуры

• Отдельное хранение данных для каждого микросервиса.
• Поддержание кода на едином уровне зрелости
• Отдельная сборка для каждого микросервиса.

Заключение

• Микросервисы – это СОА-шаблон, в котором приложения создаются как набор малых и независимых серверных единиц.
• Микросервисная архитектура относится к стилям разработки архитектуры, позволяющим создавать приложение в виде небольших и автономных сервисов для определенных предметных областей.
• Монолитная архитектура похожа на большой контейнер, в котором все компоненты приложения собраны в один пакет.
• Каждый блок приложения в микросервисе имеет предельно малый размер и выполняет определенную функцию.
• Большая база кода в монолитной архитектуре замедляет процесс разработки. Выход новых версий может растянуться на месяцы. Поддерживать такую базу кода довольно сложно.
• Существует 2 типа микросервисов: Stateless (без сохранения состояния) и Stateful (с отслеживанием состояния)
• Микросервисы на Java полагаются друг на друга; они должны взаимодействовать между собой. Микросервисы позволяют в большей степени сконцентрироваться на определенных функциях или потребностях бизнеса.
• Сервисно-ориентированная архитектура, или СОА, – это усовершенствованные распределенные вычисления, основанные на проектной модели запроса/ответа в синхронных или асинхронных приложениях.
• Компоненты приложения в СОА открыты для внешнего мира и представлены в виде сервисов; микросервисы считаются частью СОА. Это реализация СОА.
• К популярным микросервисным инструментам относятся Wiremock, Docker и Hystrix.

Что такое микросервисы: особенности архитектуры, примеры использования, инструменты

Видео про микросервисы с простым объяснением архитектуры и отличий от монолита, а также примерами инструментов.

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

Подробности — в видео и текстовой расшифровке ниже.

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

При монолитной архитектуре система обычно состоит из 3 блоков: пользовательский интерфейс, хранилище данных и серверная часть. Серверная часть обрабатывает запросы, выполняет бизнес-логику, работает с БД, заполняет HTML-страницы. Любое изменение в системе приводит к обновлению версии серверной части приложения.

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

Что такое контракт

Контракт — это формализация возможностей взаимодействия с микросервисом. В случае с REST API эндпоинты сервиса и схема данных являются контрактом. Первоначальная разработка архитектуры — это декомпозиция системы на слабосвязанные сервисы, создание интерфейсов и связей между ними, поддержка целостности данных без потери производительности. Помочь с решением данной задачи могут шаблоны Tolerant Reader и Consumer-Driven Contracts.

Микросервисная команда

Команда не должна включать в себя больше людей, чем можно насытить двумя пиццами. Такое правило использовала компания Amazon при распиливания своего монолита в 2002 году. Вполне допустимо и правило developer per service, то есть один разработчик на один микросервис.

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

Микросервисный подход предполагает разбиение системы на сервисы по бизнес-требованиям. Сервисы включают в себя полный набор технологий: UI, storage, backend. Это приводит к созданию кросс-функциональных команд, имеющих достаточно компетенций для реализации всех необходимых сервисов, покрывающих 100% бизнес-функционала. Команды должны отвечать за все аспекты ПО, которое они разрабатывают, включая поддержку его в режиме 24/7. В таком случае возможность проснуться от звонка в 3 часа ночи — это очень сильный стимул писать хороший код.

Насколько большим должен быть микросервис

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

• Node.js — для простых страничек с отчетами.
• С++ — для real-time приложений.
• Python —для анализа данных.
• Golang — для высоконагруженного сервиса.
• Java — для интеграции с энтерпрайзом.

Архитектура микросервиса даёт полную свободу в выборе технологий и инструменария.

Инструментарий для реализации микросервисов

В процессе реализации микросервисной архитектуры существенным упрощением будет использование систем CI/CD, системы оркестрации, Service Discovering, мониторинга и сбора логов.

• Для CI/CD сейчас активно используются GitLab CI, TeamCity, Jenkins, Github Action, Circle CI.
• В качестве системы оркестрации можно попробовать Nomad или Apache Mesos, а если вы используете Docker, то Kubernetes и Docker Swarm.
• Для Service Discovering можно взять Consul, Eureka или Zookeeper.
• Для мониторинга и сбора логов можно выбрать стек ELK или TICK, а также построить свою систему мониторинга из отдельных продуктов, включая Prometheus, Grafana и Graphite.

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

Цепочка синхронных вызовов микросервисов приведет к ожиданию ответов от всех сервисов по очереди. Поэтому используйте правило «Один синхронный вызов на один запрос пользователя», как это сделали в The Guardian, либо полностью асинхронный API, как в Netflix. Один из способов сделать асинхронный API — использовать систему обработки очередей, например, RabbitMQ, Apache Kafka или ActiveMQ.