Сложность программного обеспечения. Успешное приложение постоянно развивается, чтобы соответствовать меняющимся требованиям. Следовательно, монолитные приложения сложнее поддерживать, не говоря уже о том, что их структура и логика должны быть полностью понятны разработчикам, работающим над ними.
Микросервисная архитектура
В современном мире модернизация приложений часто означает переход к облачным приложениям и микросервисам. Для их разработки используются контейнерные технологии, такие как Docker и Kubernetes, применяемые Netflix, Atlassian и многими другими компаниями. Причина в том, что с помощью архитектуры микросервисов можно облегчить масштабируемость, ускорить разработку и сократить итерационный цикл разработки сервисов.
В архитектуре смешанных сервисов приложение делится на набор независимо развертываемых сервисов, которые взаимодействуют друг с другом через API-интерфейсы. При таком подходе каждая отдельная услуга может быть разработана и масштабирована независимо от других. Это позволяет командам быстрее и чаще развертывать крупные и сложные приложения. В отличие от монолитного приложения, архитектура микросервисов позволяет командам быстрее внедрять новые функции и изменения без необходимости переписывать большие части существующего кода.
Некоторые ключевые характеристики микросервисной архитектуры
Несколько компонентов-сервисов
Архитектура микросервисов состоит из отдельных, слабо связанных между собой сервисных компонентов, каждый из которых можно развертывать, использовать, эксплуатировать, изменять и переустанавливать без ущерба для других сервисов или целостности приложения. Это позволяет легко и быстро развертывать отдельные прикладные функции.
Легкое обслуживание и тестирование
В архитектуре смешанных сервисов команды могут экспериментировать с новыми функциями и возвращаться к предыдущей версии, если что-то пошло не так. Это облегчает обновление кода и сокращает время вывода на рынок новых функций. Это также облегчает поиск и исправление ошибок в отдельных службах.
Владельцами выступают небольшие команды
В архитектуре микросервисов отдельные сервисы обычно создаются небольшими независимыми командами, что облегчает внедрение методов agile и DevOps. Команды могут работать независимо и быстро, что приводит к сокращению циклов разработки.
Организация работы на основе бизнес-возможностей
В подходе микросервисов сервисы организуются на основе бизнес-функций. Команды являются межфункциональными, обладают полным набором навыков, необходимых для развития, и работают над реализацией отдельных функций.
Автоматизированная инфраструктура
Команды, создающие и поддерживающие микросервисы, обычно используют методы автоматизации инфраструктуры, такие как непрерывная интеграция (CI), непрерывная доставка (CD) и непрерывная разработка (также CD). Таким образом, каждая команда может создавать и внедрять свой сервис независимо от других команд, не влияя на их работу. Кроме того, команда может разрабатывать новую версию услуги параллельно с предыдущей версией.
Пример микросервисной архитектуры
В качестве примера возьмем гипотетический проект по разработке программного обеспечения для электронной коммерции. На схеме ниже показан сайт электронной коммерции с веб-приложением и мобильным приложением. Они взаимодействуют с несколькими микросервисами, каждый из которых обеспечивает специфические для данной области функции.
Современные веб-приложения работают в браузерах и часто доставляются через сеть доставки контента (CDN). CDN может доставлять веб-приложения на серверы по всему миру, чтобы они могли быстро загружаться веб-браузерами. CDN часто используются для доставки мультимедийных ресурсов, таких как изображения, аудио- и видеофайлы. В этой системе, например, видео и изображения товаров для продажи предоставляются через CDN.
На схеме изображены следующие микросервисы:
Сервис аккаунтов
Служба счетов предоставляет информацию о счетах клиентов, такую как адрес и платежная информация.
Сервис запасов
Он предоставляет актуальную информацию о запасах товаров, которые клиент может приобрести.
Сервис корзины для покупок
В этой услуге клиент выбирает товары, которые он хочет купить, из инвентаря.
Платежный сервис
Клиенты оплачивают товары, находящиеся в корзине.
Сервис доставки
Отвечает за составление графика упаковки и доставки приобретенных товаров.
Приложения взаимодействуют с микросервисами через REST API, публикуемые каждым микросервисом. Приложения получают доступ к API микросервисов через портал API, что также позволяет заменить один микросервис другим с тем же API.
Каждый микросервис состоит из службы и базы данных. Службы взаимодействуют с REST API, реализуют бизнес-логику и хранят информацию в базе данных. Ресурсы микросервиса, такие как базы данных и очереди, изолируются в соответствии с 12-факторным соглашением о внедрении.
Как создавать микросервисы
Многие компании начинают с монолитной архитектуры. Затем им необходимо разделить кодовую базу на множество сервисов, реализовать соответствующие схемы для надлежащей обработки отказов и восстановления после сетевых проблем, обеспечить согласованность данных, настроить мониторинг нагрузки на сервисы и так далее. Однако эта проблема носит не только технический характер. Вам также необходимо реорганизовать команды и, возможно, внедрить культуру DevOps.
Затем наступает время, когда вам нужно решить самую сложную задачу — разделить монолит на микросервисы. Изменение конфигурации схемы монолитной базы данных может быть сложным процессом. Важно четко определить, какие наборы данных необходимы каждой службе, а какие — сразу в нескольких местах. Непрерывное развертывание помогает снизить риски, связанные с ошибками при выпуске, и позволяет команде сосредоточиться на создании и запуске приложения, а не на его разработке.
Существует несколько подходов. Один из них — использование специального компонента Service Discovery, который знает, где находится каждый микросервис и как к нему получить доступ.
Что такое микросервисная архитектура
Термин «микросервисы» объясняет Сэм Ньюман в своей книге Building Microservices: они маленькие и нацелены на выполнение одной задачи хорошо, автономные, совместные сервисы.
Идея разбиения системы на независимые компоненты не нова. Предшественником архитектуры микросервисов является сервис-ориентированная архитектура (SOA), в которой бизнес-логика также разбивается на компоненты. По сути, архитектура микросервисов — это частный случай SOA с набором более строгих правил.
Микросервисы имеют особые характеристики и преимущества:
- Гетерогенность: возможность создания системы с использованием различных языков программирования и технологий,
- Децентрализованное управление данными: каждый микросервис содержит свой собственный набор данных, доступ к которому другие микросервисы имеют только через соответствующий интерфейс,
- Независимость инфраструктуры: каждый микросервис является независимой сущностью и поэтому может быть изменен и развернут независимо от других,
- Масштабируемость: Для повышения производительности системы следует масштабировать только те службы, которые нуждаются в масштабировании.
Микросервисы vs монолит
Микросервисы контрастируют с традиционной монолитной архитектурой. Монолитность означает, что компоненты продукта взаимосвязаны и взаимозависимы. Если один из них перестает работать, все остальные тоже «ломаются».
Быстрый рост ИТ-индустрии влечет за собой новые требования: развитие технологий, изменение потребностей конечных пользователей, которые необходимо быстро удовлетворять. Если в 2005 году можно было разрабатывать продукт в течение нескольких лет, то сейчас базовая версия должна быть выпущена за несколько месяцев.
В этих условиях архитектура со смешанными услугами выигрывает у монолитной архитектуры:
- Проще изменить один из микросервисов и сразу же развернуть его, чем менять весь монолит и перезапускать всю инфраструктуру,
- Новым разработчикам проще — им не нужно изучать всю систему, они могут просто работать над своей частью,
- Микросервисы независимы от платформы, поэтому внедрять новые технологии проще, чем в монолитной системе.
Недостатки подхода
Не все идеально. Микросервисы усложняют разработку и поддержку продукта:
- Сложность первоначальной разработки и создания инфраструктуры. Распределенные системы сложнее реализовать, поскольку приходится исходить из того, что микросервис не зависит от отказа другого компонента,
- Использование распределенных систем влечет за собой дополнительные затраты на обмен данными между микросервисами: протоколы связи между компонентами должны быть выбраны правильно, чтобы связь была максимально эффективной,
- В распределенной системе трудно поддерживать строгую согласованность: Общие части системы либо нужно поместить в общую библиотеку, но при изменении библиотеки необходимо перезапустить все зависимые микросервисы, либо хранить общий код в каждом из микросервисов, но такой код нарушает принцип DRY (Не повторяйся) и его сложнее поддерживать,
- Различная структура команды разработчиков. Команда делится на группы, каждая из которых полностью разрабатывает один микросервис. Генеральный директор Amazon Джефф Безос считает, что оптимальным размером команды является тот, который может накормить две пиццы, то есть 7-9 человек.
Празднование запуска проекта на IT.Place
Доказано, что монолитная структура обеспечивает более быстрые результаты на ранних стадиях разработки. Чем дальше развивается такая система, тем сложнее ее поддерживать. Микросервисы требуют высокого уровня внимания и знаний от разработчиков. До выпуска первой услуги еще многое предстоит сделать: Инфраструктурные соображения, протокол передачи данных, построение конвейеров разработки и изменение подхода к разработке программного обеспечения. С первой предварительно построенной службой новые функции появляются быстрее, чем при монолитной архитектуре.
Технологии коммерциализации используются для того, чтобы приложение микросервисов одинаково хорошо работало на компьютере разработчика, в тестовой среде и в производственной среде. Контейнеры упрощают перенос микросервисных приложений в «живую» среду и помогают избежать неожиданностей во время разработки.
Микросервисная архитектура
Архитектура микросервисов наследует изоляцию и распределение от архитектуры-предшественницы. Здесь база данных не используется в качестве шины данных, за исключением отдельных случаев по соображениям производительности. В классической схеме компоненты изолированы как на уровне кода, так и на уровне базы данных.
Для микросервисов используется управление контейнерами с оркестровкой и прочими прелестями.
Следующее преимущество — протоколы обнаружения услуг. Рассмотрим разницу между коммуникацией в сервис-ориентированной архитектуре и архитектуре микросервисов: в последней нет общего канала, и сервис адресуется непосредственно всем остальным:
Выбор протоколов связи остается на усмотрение разработчика. Например, используйте REST для публичных запросов и RPC через AMQP для внутренних запросов, или общий протокол для всех.
Выделяйте микросервисы либо с точки зрения предприятия, либо с точки зрения разработчика для повторного использования. Но этому мешают две вещи:
- Внутренняя коммуникация — когда микросервисы тесно взаимодействуют друг с другом,
- Транзакции — разные микросервисы имеют изолированные базы данных, в то время как микросервису нужна общая база данных.
Давайте рассмотрим пример разделения услуг. Первой задачей была настройка для авторизации, а затем аналогичная настройка потребовалась для кошелька. Конечно, нам нужно передать конфигурацию отдельному микросервису. Для этого скопируйте код из предыдущего задания, добавьте RPC для внутренних соединений, удалите клиента для удобства и используйте его в других микросервисах.
Достоинства и недостатки микросервисной архитектуры
Как и в любой распределенной архитектуре, существуют коммуникационные накладные расходы.
Концепция непрерывной интеграции и развертывания (CI/CD) и построение архитектуры (контейнеры, оркестровка, мониторинг и т.д.) отнимают много времени.
А как насчет отказоустойчивости? Это часто определяется как «отказ одной службы не влияет на другие». Представьте, что в Audit произошел сбой, а Wallet теоретически продолжает функционировать — это похоже на отказоустойчивость:
Что насчет RPC-запросов, которые продолжает посылать Wallet? Необходимо предвидеть ситуацию, когда аудит не удастся провести, и правильно настроить сброс, так как базы разные и не могут быть проведены по каждой транзакции.
Или другая ситуация: микросервис авторизации, через который работают другие, терпит крах. Для того чтобы продолжить обработку запросов, добавляется код для неавторизованного пользователя. По сути, это серьезная ошибка.
Микросервисы достигают масштабируемости с помощью систем оркестровки, поскольку остается достаточно ресурсов сервера, в отличие от монолита, который потребляет всю память и процессор.
Типичный процесс разработки — кодирование, тестирование и развертывание — в архитектуре микросервисов выглядит иначе. Первые два этапа объединяются по мере того, как микросервис взаимодействует с рядом других. Чтобы локально выполнить даже один запрос, необходимо запустить все эти микросервисы, поэтому ручное тестирование не подходит для такой задачи.
Представьте, что вы тестируете денежный перевод в банковской системе. Для этого вы создаете двух пользователей, компанию, агента для пополнения счета, релиз в систему для наполнения хранилища агента деньгами, внесения денег на личный счет отправителя и только потом осуществляете перевод получателю.
Вы собираетесь делать такое количество приложений вручную? Добавьте к этому сложность взаимодействия микросервисов, и наступит полный ад.
Таким образом, разработчик запускает модульные тесты на месте, а ответом ему служат макетные объекты, а не микросервисы. Также необходимы функциональные тесты, например, для выявления проблем связи, и интеграционные тесты. Они запускаются вместе с модульными тестами на этапе слияния рабочих копий с основной веткой разработки. И только после этого разработчик вручную тестирует функциональность. Перед разработкой новая версия тестируется службой контроля качества.
Архитектура микросервисов делает компоненты независимыми при разработке и развертывании, чего нельзя было сказать о монолитной архитектуре.
Микросервисы являются многократно используемыми и экономят деньги с точки зрения бизнеса.
Разработчик имеет относительную свободу в выборе языка и технологии для разработки отдельных частей проекта.
Контроль зависимостей
Трудно управлять и поддерживать 50 проектов с 50 репозиториями, если есть ошибка безопасности, которую нужно немедленно исправить во всех проектах. Поэтому используйте проверку зависимостей, общие библиотеки для микросервисов и семантическое версионирование. И не создавайте раздутую библиотеку, разбейте ее на несколько небольших библиотек, чтобы не бояться выпускать большую версию.
Обратные зависимости: Запишите версию драйвера в пакет, в который вы добавляете необходимые микросервисы, чтобы не проверять версии в разных проектах. Для внешних зависимостей лучше всего заблокировать версии.
При использовании stateful вы создаете новый объект HolyjSService при получении запроса и заполняете его данными, необходимыми для его выполнения. Затем эта служба асинхронно переходит к базе данных. Следующий запрос получает новый экземпляр сервиса, и процесс повторяется.
Плюсы микросервисной архитектуры
В подходе микросервисов каждая бизнес-функция разбивается на отдельные сервисы. Основное отличие архитектуры микросервисов от монолитной архитектуры заключается в том, что каждый процесс приложения работает как отдельный, слабо связанный сервис со своей логикой и базой данных. Обновление, развертывание, тестирование и масштабирование выполняются в отдельном модуле.
Микросервисы не уменьшают сложность системы, но они делают ее более управляемой. В зависимости от потребностей, одну и ту же услугу можно повторно использовать в нескольких бизнес-процессах и точках соприкосновения. Благодаря стандартизации через бизнес-ориентированные API пользователи не замечают никаких изменений на стороне сервера.
Как показывают такие крупные сервисы, как Netflix, Airbnb, Google, Disney и Amazon, микросервисы сейчас очень востребованы на развивающемся рынке ИТ. В основном это связано с преимуществами, которые дает передовой опыт архитектуры микросервисов.
Удовлетворение высоких требований. Микросервисы могут обеспечить максимальную гибкость, скорость и масштабируемость. Для приложений с экстремальными требованиями лучше всего подходит архитектура микросервисов, которая может удовлетворить потребности каждого сервиса в разрабатываемом приложении.
Комплексное решение. На этапе проектирования микросервисов их границы должны быть четко определены, чтобы их можно было согласовать с бизнес-функциями. В сфере проектирования, ориентированного на конкретную область, это также известно как ограниченные рамки. Такой подход позволяет использовать наиболее эффективный язык для каждой области.
Опыт работы с микросервисами. Чтобы начать работу с микросервисами, вам нужна команда, которая уже имеет опыт работы с микросервисами или распределенным проектированием. Рекомендуется передать этот проект на аутсорсинг экспертам по DevOps и контейнерам, поскольку эти концепции тесно связаны с микросервисами.
Способность выполнять сложный проект. Если вы разрабатываете большое приложение с множеством модулей и пользовательских циклов, что приводит к высокой сложности приложения, лучше всего использовать архитектуру микросервисов. В будущем будет гораздо проще масштабировать систему и добавлять новые функции.
Недостатки микросервисов
Несмотря на все преимущества создания проекта на основе архитектуры микросервисов, этот подход не является универсальным. Не стоит выбирать микросервисы только потому, что вы видите, как другие компании успешно их используют. Подход микросервисов подходит не для всех бизнес-задач и не устраняет волшебным образом сложность разработки и обслуживания.
Внедрение микросервисов не упростит электронную коммерцию или развитие бизнеса в целом. Прежде чем применять эту архитектуру в своем приложении, рассмотрите следующие недостатки микросервисов по сравнению с монолитным подходом.
Общие проблемы. Каждый микросервис должен решать ряд сквозных задач, таких как протоколирование, ведение метрик, проверка работоспособности и внешняя конфигурация. Скорее всего, вы не включили их в процесс разработки. Вы можете указать стоимость обслуживания для каждого модуля отдельно. В качестве альтернативы они могут использоваться на другом уровне обслуживания, через который направляется весь трафик.
Более высокие затраты. Построение архитектуры микросервисов требует больше усилий по разработке и мониторингу, что напрямую связано с увеличением эксплуатационных расходов. Поскольку сервисы обмениваются данными друг с другом, большое количество удаленных вызовов может привести к увеличению затрат ресурсов, связанных с задержкой в сети и обработкой данных. А поскольку каждый микросервис развертывается независимо и требует собственной среды исполнения и процессорной мощности, требования к ресурсам возрастают.
Организационные изменения: Чтобы стать полностью независимой, каждая команда должна охватить весь жизненный цикл микросервиса: от проектирования и концептуализации, технических решений и реализации, до текущих операций и мониторинга. Это требует организационных изменений, таких как передача обязанностей от менеджеров к командам. Культура DevOps, которая также опирается на методы автоматизации, настоятельно рекомендуется для успешной адаптации подхода смешанных сервисов.
Уникальной архитектуры не существует
Архитектура приложений микросервисов становится все более востребованной. Однако для конкретной бизнес-задачи, оцененной на основе перечисленных выше плюсов и минусов, важно решить, с чего начать — с монолитных или микросервисов.
Для легких приложений часто более подходящей является монолитная система. Для сложного, развивающегося приложения со специфическими доменами лучшим выбором будет архитектура микросервисов.
Самое главное — сосредоточиться на конкретных потребностях вашей организации, а не на архитектурном подходе. Таким образом, можно избежать ненужных сложностей при разработке приложений.
Самое главное — сосредоточиться на конкретных потребностях вашей организации, а не на архитектурном подходе. Таким образом, можно избежать ненужных сложностей при разработке приложений.
Что нужно учесть при переходе на микросервисы
Во-первых, необходимо разработать инфраструктуру. Это делается на аппаратном и системном уровне.
В случае архитектуры микросервисов нет особых требований к аппаратному уровню ИТ-инфраструктуры, но есть некоторые моменты, которые необходимо учитывать при разработке
Планируйте загрузку оборудования,
Не забудьте учесть нагрузку от самих сервисов системы управления контейнерами — иногда это условие может существенно повлиять на общий результат из-за учета множества элементов (протоколирование, мониторинг, сетевая маршрутизация),
На системном уровне важно:
Заранее продумайте ландшафты приложений: у каждого из них свои требования к вычислительным ресурсам и особенности; спланируйте интеграцию с другими элементами ИТ-инфраструктуры и внешними подсистемами с учетом опыта внедрения ИТ в вашей компании, технологического стека, используемых инструментов (системы хранения, сети, резервного копирования, продукты мониторинга),
Разработайте стратегию аварийного восстановления для обеспечения непрерывности обслуживания — любой сбой в работе центра обработки данных приведет к простою, который может обойтись бизнесу очень дорого.
Согласовать системы интерфейса для обеспечения информационной безопасности.
Как перейти от монолита на микросервисы
1) Сформулируйте задачи
Каждый микросервис отвечает за определенную функцию, выполняющую конкретную потребность пользователя. Формулировка этих бизнес-целей: Анализировать существующие цели и разрабатывать новые, основываясь на проблемах процесса. Затем определите наилучшие средства для решения каждой задачи и выберите соответствующие инструменты.
2) Соберите команды разработчиков
Важно определить зоны ответственности команд, то есть у каждой команды должна быть своя среда разработки. Это гарантирует, что каждая ИТ-команда сосредоточится на своем приложении. Доступ к данным должен быть децентрализован, с дифференцированным доступом. Поскольку каждая команда отвечает только за весь жизненный цикл своего продукта, они выбирают язык программирования и методологию реализации.
Если ваши разработчики в прошлом работали только с монолитными системами, вам следует потратить ресурсы и время на их переобучение архитектуре микросервисов под руководством опытных внешних экспертов.
3) Создание инструмента для взаимодействия микросервисов
Проекту нужна коммуникационная среда, поэтому необходимо создать клиент, оптимизированный для REST-вызовов и способный использовать все языки программирования. Также требуется регулярно обновляемая конфигурация, локализованная в каждом приложении — она помогает микросервисам понять, как передавать данные друг другу.
Разработка приложения (включая время на тестирование) занимает от 2 до 3 недель, поэтому лучше выбрать agile-модель, чем Waterwall.
4) Быстрый релиз с помощью DevOps
Подход микросервисов идеально вписывается в парадигму DevOps. Его общие принципы — хорошая коммуникация между соответствующими командами и быстрые сроки выпуска.
Микросервис можно рассматривать как мини-продукт, который «помещен» в контейнер. Оно проходит автоматизированное тестирование и нагрузочное тестирование, и когда критерии качества удовлетворены, начинается интеграция приложения. Управление контейнерами осуществляется с помощью системы оркестровки.
Инструменты для создания микросервисов
Хотя службы независимы и невелики, их развертывание отличается от традиционного развертывания. Существует большое количество инструментов для разработки микросервисов, которые выполняют определенные задачи.
Управление API и тестирование
Одним из известных инструментов является API Development Kit, который облегчает выполнение тестов на основе пользовательского интерфейса, Postman. Также можно комбинировать простые и сложные HTTP-запросы. Это помогает быстрому тестированию, разработке и документированию API.
Разработчики используют Fortress API для тестирования и проверки API, а также масштабируемую и быструю платформу Tyk для управления API с открытым исходным кодом.
Служба сообщений
Очередь сообщений важна для архитектур микросервисов — она касается обработки связи между приложениями и внешними источниками (например, вызовами API).
Популярные инструменты включают платформу Apache Kafka (помогает в распределенной обработке потоков), решение RabbitMQ, которое служит мостом для связи между микросервисами, и Amazon Simple Queue Service (SQS). Последний представляет собой надежный, высокопроизводительный коммуникационный механизм микросервиса, который обеспечивает хранение сообщений в очереди.
Мониторинг
После разработки и развертывания приложений необходимо отслеживать их производительность, принимая во внимание несколько факторов. Например, насколько хорошо работают сервисы, базы данных и т.д.? Нужна ли им дальнейшая оптимизация?
Logstash — это инструмент протоколирования с открытым исходным кодом, используемый для хранения, сбора и преобразования данных. Он также может использоваться в качестве центрального сервера вместе с интерактивным интерфейсом Graylog.
Оркестровка
Системы оркестровки могут использоваться для автоматической координации и управления микросервисами и сервисами. Попробуйте, например, Apache Mesos, Nomad или Conductor. Последняя является частью экосистемы OSS компании Netflix. Он также может помочь контролировать и визуализировать взаимодействие между компонентами.
Инструментарий
Благодаря архитектуре микросервисов выбор технологий и инструментов может быть очень широким. Например, fabric8 может быть полезна как платформа с открытым исходным кодом, которая обеспечивает управление конфигурацией на основе Git, высокую доступность и масштабируемость компонентов. Seneca, пакет микросервисов для Node.js, можно использовать для создания хорошо структурированного кода и организации логики приложения. А с помощью бессерверной платформы Google Cloud Platform можно создавать управляемые события для сервисов с низкой связностью. Используя Google Compute API, облачные функции можно подключать к другим продуктам.
Архитектурный каркас
С помощью фреймворка goa ИТ-специалисты могут разрабатывать API, создавать контент, от текстовых форматов JSON до библиотек JavaScript, или инструмент Kong использует многочисленные модули, помогающие разработчикам создавать приложения, в том числе с помощью шаблонов.
Безсерверные инструменты
Они направлены на упрощение серверных операций, что положительно сказывается на качестве работы специалистов: они могут тратить меньше времени на структуру приложений и сосредоточиться на бизнес-задачах.
Apache Openwhisk, например, является легко масштабируемой платформой для разработчиков, позволяющей создавать, тестировать и настраивать микросервисы. Открытая платформа FaaS компании IronFunctions может поддерживать любую функцию, независимо от языка написания. OpenFaaS помогает «обернуть» любой процесс в функцию Linux или Windows без необходимости использования сервера. А Microsoft Azure Functions — это инструмент, расширяющий функциональность систем Azure.
Подотчетность и гибкий подход должны применяться на протяжении всего жизненного цикла микросервисов. Существует несколько инструментов для совместной работы экспертов: чаты, видеоконференции, управление проектами и базы знаний. Наиболее известные помощники — Trello, Slack и Google Meet.
Что такое микросервисная архитектура?
Архитектура смешанных сервисов — это способ построения информационной системы, состоящей из ряда отдельных сервисов. Каждый из этих сервисов разрабатывается независимо от других и реализует определенную функциональность общего приложения. Важными техническими особенностями этой структуры является то, что данные хранятся децентрализованно, а интеграционные процессы, такие как преобразование форматов сообщений, выполняются самими микросервисами, а не шинами данных. Кроме того, нет ограничений на выбор технологии для реализации каждого микросервиса, что позволяет выбрать наиболее подходящее решение для удовлетворения конкретных потребностей бизнеса. В результате банки больше не зависят от конкретного поставщика. Поскольку разные микросервисы могут разрабатываться разными командами, можно поручить конкретную бизнес-задачу лучшему специалисту. Благодаря независимости микросервисов, информационные системы на их основе можно разрабатывать по частям. На мой взгляд, эта возможность является одной из основных причин, почему многие банковские ИТ-подразделения приняли идею создания микросервисных систем.
Современные финансовые учреждения предлагают широкий спектр услуг. У них есть отдельные бизнес-подразделения, отвечающие за различные сферы деятельности, каждое из которых разрабатывает и запускает новые продукты по собственному плану. Точкой пересечения всех этих областей является электронный банк. Вам может быть знакома ситуация, когда продукт готов к запуску через интернет-банкинг, но приходится ждать, пока завершатся проекты по разработке соответствующих подразделений. Например, функция платежей и переводов не может быть обновлена до выхода соответствующей версии функции открытия депозита. Это менее вероятно при смешанном подходе, поскольку многие услуги часто полностью отделены друг от друга. Это означает, что «время выхода на рынок» новых услуг сокращается.
Выбираем путь развития
Когда я начал свое знакомство с философией архитектуры микросервисов, одной из первых статей, на которую я наткнулся, была статья Мартина Фаулера «Монолит превыше всего». В нем он упоминает, что заметил некоторые закономерности в историях команд разработчиков, использующих архитектуру микросервисов:
- «В подавляющем большинстве случаев, когда информационная система была построена с нуля с использованием архитектуры микросервисов, возникали серьезные проблемы.
- Почти все истории успеха в построении систем микросервисов начинались с монолитного приложения, которое росло и его решили разбить.
Эта информация была обнадеживающей, поскольку к тому времени мы уже разработали и успешно внедрили в нескольких банках платформу InterBank RS, которую можно назвать «монолитной», хотя и с некоторыми корректировками. Однако термин «монолитный» не следует путать с медленной, трудно масштабируемой и немасштабируемой системой. Приложения, входящие в состав комплекса InterBank RS, поддерживают горизонтальную масштабируемость; существует функциональное разделение на компоненты, обрабатывающие запросы пользователей, и компоненты, выполняющие обработку данных в фоновом режиме. Кроме того, функциональность системы, построенной на платформе InterBank RS, может быть расширена сторонними разработчиками с помощью механизма расширения.
В отчетах о переходе от монолитных приложений к архитектуре микросервисов можно выделить две основные тенденции:
- Монолит полностью заменяется микросервисами.
- Монолит остается центральным элементом системы (своего рода «микролит»), окруженный фрагментированными микросервисами, а большинство расширений системы принимают форму новых микросервисов.
Мы выбрали второе направление, и одной из наших целей было предоставить удобный механизм расширения функциональности InterBank RS за счет интеграции с микросервисами.
- Предоставление инфраструктуры взаимодействия для микросервисов,
- для организации процесса аутентификации и авторизации.
Зная, что системы микросервисов требуют больше усилий по управлению, чем монолитные системы, мы постарались спроектировать наше решение так, чтобы оно включало минимум различных обязательных настроек конфигурации.
Что получилось в итоге?
Инфраструктура взаимодействия микросервисов
Основные задачи разработчиков микросервисов — создать удобный механизм для добавления новых экземпляров микросервисов в существующую систему, настроить балансировку нагрузки и обеспечить пересылку запросов между микросервисами.
Существует несколько подходов. Один из них — использование специального компонента Service Discovery, который знает, где находится каждый микросервис и как к нему получить доступ.
Когда микросервис запускается, он связывается со службой Discovery Service и сообщает ей свой тип и IP-адрес. Затем служба обнаружения периодически информирует микросервис о своем состоянии и готовности обрабатывать запросы. Прежде чем микросервис отправит запрос другому микросервису, он обращается к службе обнаружения, которая, в свою очередь, сообщает, какой микросервис может обработать запрос, возвращая либо IP-адрес самого микросервиса (в этом случае служба обнаружения выполняет балансировку нагрузки), либо список IP-адресов доступных микросервисов (если балансировка нагрузки выполняется на запрашивающем микросервисе).
Поскольку одним из требований к архитектуре микросервисов была возможность асинхронного взаимодействия между компонентами системы, в качестве центрального элемента соединения был выбран Active MQ Message Broker. Он даже стал службой обнаружения в нашей системе. Легко видеть, что задачи, поставленные перед службой поиска, были решены:
- При запуске микросервис подключается к очередям, опубликованным в Active MQ. Это говорит системе, что она «живая» и готова обрабатывать запросы. Одна очередь используется всеми микросервисами для отправки запросов, а вторая очередь — для отправки ответов на полученные запросы. Каждый экземпляр определенного типа микросервиса регистрируется для прослушивания очереди запросов и получения сообщений, адресованных тому типу микросервиса, к которому он принадлежит. При отправке запросов получателем является не конкретный экземпляр микросервиса, а тип, к которому он принадлежит.
- Сообщения пересылаются брокером сообщений на основе метаданных в заголовках сообщений, которые содержат информацию о получателе и опциях, установленных микросервисами при подключении к очередям запросов и ответов. Важным фактом является то, что микросервису необходимо знать только местоположение Message Broker и имена очередей, а физическое местоположение других микросервисов для него не имеет значения.
- Брокер сообщений также берет на себя функцию балансировки нагрузки. Балансировка неявно выполняется самими микросервисами, прослушивающими очередь. Запрос, адресованный группе микросервисов определенного типа, забирается из очереди тем микросервисом, который в данный момент самый быстрый и имеет свободные ресурсы для обработки запросов. Таким образом, ситуация, когда один микросервис перегружен, а другой не активен из-за ошибки в выборе правила балансировки, просто невозможна.
Чтобы облегчить интеграцию микросервисов со сторонними системами, каждый микросервис имеет открытый RESTful API, описанный в Swagger v.2 (Open API Specification v.2²).
Внимательный читатель может задаться вопросом: если Active MQ используется для передачи сообщений между микросервисами, а API микросервисов использует HTTP-запросы, то микросервисы общаются друг с другом в другом формате, а с внешним миром — в другом? Давайте узнаем.
