Путь из монолитов в микросервисы

Технологии
3512
0
Андрей Григоров, руководитель отдела программных разработок, департамент систем электронного банковского обслуживания, R-Style Softlab
Несколько лет назад на рынке банковской автоматизации произошло заметное изменение: в списках требований банков к разрабатываемым приложениям для дистанционного банковского обслуживания всё чаще стала появляться строка «система должна быть реализована с соблюдением принципов микросервисной архитектуры». Следуя запросам рынка, мы решили подробнее ознакомиться с этой темой и испытать на практике, что представляют собой микросервисы. В этой статье мы расскажем, какой опыт получили.



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

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


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

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

Выбираем путь развития 


Когда я начинал знакомиться с философией микросервисной архитектуры, одной из первых статей на эту тему, которая попалась мне на глаза, была публикация «Monolith First» Мартина Фаулера¹. В ней он говорит, что заметил некоторые закономерности в историях о командах разработчиков, использующих микросервисную архитектуру: 

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

В историях перевода монолитных приложений на микросервисную архитектуру можно выделить два основных направления: 

  • Монолит полностью заменяется на микросервисы. 
  • Монолит остаётся в качестве центрального компонента системы (этакого «микролита»), окружённого отделившимися микросервисами, а большинство доработок системы выполняется в виде новых микросервисов. 
Мы выбрали второе направление, при этом одной из наших целей было создать удобный механизм расширения функциональности InterBank RS путём интеграции с микросервисами. 

Для достижения поставленной цели нам пришлось решить ряд задач: 

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

Что получилось в итоге? 


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


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

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

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

  • При запуске микросервис подключается к очередям, опубликованным на Active MQ. Тем самым он фактически сообщает, что «живой» и готов обрабатывать запросы. Одна очередь используется всеми микросервисами для отправки запросов, а вторая – для отправки ответов на полученные запросы. Каждый экземпляр микросервиса определённого типа подписывается на прослушивание очереди запросов и выполняет выборку сообщений, адресованных тому типу микросервисов, к которому он относится. При отправке же запросов в качестве получателя указывается не конкретных экземпляр микросервиса, а тип, к которому он относится. 
  • Маршрутизация сообщений выполняется силами брокера сообщений на основании метаданных, передаваемых в заголовках сообщений и содержащих информацию о получателе, и селекторов, которые микросервисы устанавливают при подключении к очередям запросов и ответов. Отмечу важный факт: микросервису достаточно знать только расположение брокера сообщений и название очередей, а физическое расположение других микросервисов для него значения не имеет. 
  • Брокер сообщений также берёт на себя функцию балансировки нагрузки. Действительно, балансировка производится неявно самими микросервисами, слушающими очередь запросов. Запрос, адресованный группе микросервисов с определённым типом, из очереди забирает тот микросервис, который в настоящий момент самый расторопный и имеет свободные ресурсы для обработки запросов. Таким образом, ситуация, когда из-за ошибки выбора правила балансировки один микросервис будет перегружен, а второй простаивать без действия, попросту невозможна. 
Для того чтобы с микросервисами было удобно интегрироваться сторонним системам, каждый из них имеет открытый RESTful API, описание которого представляется в формате Swagger v.2 (Open API Specification v.2²). 

Внимательный читатель может задаться вопросом: если для передачи сообщений между микросервисами используется Active MQ, а API микросервисов предполагает обработку HTTP запросов, то неужели микросервисы между собой общаются в каком-то своём формате, а с внешним миром в другом? Давайте разберёмся. 

Микросервис при отправке запросе выполняет запаковку http-запроса в специальный конверт, который передаётся через Active MQ. Микросервис-получатель на своей стороне этот конверт распаковывает и передаёт http-запрос на обработку сервисам RESTful API. Подготовленный http-ответ, в свою очередь, также запаковывается в конверт и передаётся через Active MQ микросервису, выполнявшему запрос, который распаковывает конверт и обрабатывает полученный ответ. 
Получается, что фактически каждый микросервис имеет единый API, запросы к которому могут поступать по двум каналам: либо через JMS, либо напрямую через HTTP.

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

API Gateway 


Ещё одним компонентом разработанной системы является API Gateway, который выступает единой точкой приёма запросов от внешних пользователей открытого API микросервисов. Такими пользователями могут выступать, например, приложение мобильного банка или браузер, в котором открыта страница интернет-банка. API Gateway получает запрос и на основании URL определяет, какой микросервис должен его получать. После этого передаёт сообщение через Active MQ микросервису-получателю, дожидается ответа и возвращает его обратно. 

Второй важной функций API Gateway является создание и ведение пользовательской сессии. При аутентификации клиента в интернет-банке или приложении «Мобильный банк» InterBank RS создаёт специальный авторизационный токен, действующий до конца пользовательского сеанса. Этот авторизационный токен должен передаваться в запросе к открытому API микросервисов. Если при получении очередного запроса пользовательской сессии на стороне API Gateway нет, то API Gateway извлекает этот авторизационный токен из запроса и выполняет проверку его валидности, обращаясь с запросом к сервису авторизации InterBank RS. В ответ от InterBank RS API Gateway получает информацию об учётной записи клиента, которому выдан токен. Эта информация сохраняется в создаваемой пользовательской сессии, и для всех запросов, относящихся к данной сессии, информация об учётной записи клиента добавляется в заголовки конверта, передаваемого через Active MQ. 

На картинке ниже представлена общая схема получившегося решения. 

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

Рис. 1. Общая схема InterBank RS в микросервисной архитектуре 

Заключение  


Мир микросервисов многогранен, а объять необъятное, как известно, невозможно. В данной статье мы лишь слегка затронули пласт тем, с которыми нам пришлось ознакомиться, переводя InterBank RS на микросервисные рельсы. За рамками осталось много интересных вещей, обсуждению которых можно посвятить не одну публикацию: например, вопросы масштабирования и автоматического развертывания комплекса микросервисов, организации процесса разработки внутри команд программистов, сравнения и выбора фреймворков для построения микросервисной архитектуры и многое-многое другое. А что интересно вам, наши уважаемые читатели? Считаете ли вы, что микросервисная архитектура может стать стандартом разработки для постоянно развивающихся систем? Оставляйте свои комментарии к этой статье, я думаю, у нас есть много того, что мы можем обсудить на страницах нашего блога.

________________________________________

Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2016 2017 2018