Здравствуйте, меня зовут Алексей, я главный IT-архитектор банка «Ренессанс Кредит». Лет десять назад мы, как и многие компании, ускорили свое развитие благодаря сервис-ориентированной архитектуре (SOA). Но со временем требования к архитектуре менялись, и к данной парадигме стали возникать серьезные вопросы. В конце концов мы решили перейти от интеграционной шины ESB к микросервисам. На нашем примере я расскажу, почему стоит задуматься об эффективности SOA и что можно предпринять, если эта модель вас тоже не устраивает.
Новые проблемы ESB
Все началось с того, что мы оценили структуру нашей интеграционной шины. На схеме представлена типовая ситуация с интеграционными потоками для ESB.
Таких блоков может насчитываться нескольких десятков (вплоть до сотни!), и они тесно переплетены между собой. Если потребуется сделать новый продукт и внести какие-то изменения, то на переработку этого здоровенного монолита не хватит никаких ресурсов. И это только общий взгляд. Мы изучили SOA со всех сторон и всего выделили семь основных проблем:
- Акцент на повторном использовании сервисов. Это правило было краеугольным камнем SOA, но в итоге оно привело к тому, что все команды (фронт, бэк и интеграция) оказались настолько плотно связаны, что любое обновление интеграции требовало регрессионной проверки практически всей шины!
- Тяжелый технологический стек. Вначале единый контейнер ESB был преимуществом, и это позволяло нам быстро разворачивать сервисы. Но сегодня ограниченный стек технологий, библиотек и языков программирования уже заметно мешает развитию.
- Превращение ESB в «бутылочное горлышко» для всех процессов. Со временем шина обрастает функциями и превращается в полноценную информационную систему банка, с waterfall-подходом и «нарезанием» интеграционных потоков. Загрузка команды ESB сильно возрастает, что тормозит работу остальных команд развития.
- DataSilo. В SOA интерфейсы сервисов отделены от имплементации. Но насколько отделены друг от друга данные, которые используются сервисами? Один сервис обращается к данным другого, используется механизм dblink’ов, возникает путаница и «силосная башня данных».
- Смешение шаблонов интеграции. Строго говоря, для SOA их два: классический MessageBroker, где между системами ходят сообщения для обмена порциями данных, и хаб сервисов, где мы размещаем какие-то сервисы, которые «некуда больше приткнуть». При смешении этих шаблонов ESB превращается в абсолютно «черный ящик».
- Формирование «теневых IT». Бизнес-заказчики зачастую формируют собственные IT-команды для развития критически важных для себя систем, но при этом использовать шину для интеграции не могут. Так растет число «левых» подключений к информационным системам.
- Отсутствие поддержки ITSec (информационной безопасности) на уровне концепции. Здесь нужно сделать небольшое пояснение: во-первых, вполне «западная» концепция ESB не учитывает особенности российского законодательства (например, защиту персональных данных при передаче из источника в приемник), а во-вторых – контейнер ESB представляет собой периметр, который эффективно работает, когда внутри него уже не требуется соблюдение специальных требований ITSec.
Новые потребности заказчиков
Традиционная сервисная шина, ориентированная на waterfall, со своими сложными и медленными процессами никак не вписывается в условия рынка. Сегодня заказчики знают о гибких методологиях разработки. Они могут не знать различий между agile и waterfall, но хотят получать первые результаты — от появления идеи до прототипа в эксплуатации — не через 6-8, а через 2-3 месяца, а лучше вообще через один. Пусть это будет MVP, но заказчику важно как можно быстрее проверить бизнес-идею, понять, что решение «взлетит».
В таких условиях традиционные, горизонтально ориентированные команды уступают вертикально ориентированным, которые работают со всеми составляющими продукта — от канала взаимодействия до бэк-энда. Ребром встает вопрос: как поступить с интеграционной шиной, превратившейся из-за повторного использования сервисов в монолит? Нужен новый технологический подход.
Фундамент нового подхода
Мы начали прорабатывать альтернативу SOA с формулировки основных требований:
- Возможность быстрого пилотирования идей. Для этого потребуется простая (регулярная, повторяющаяся) структура связей между системами, быстрое развертывание и версионирование.
- Поддержка гибкой разработки. Легкое подключение новых, вертикальных команд, выход на уровень «фабрики разработки», с автоматизацией рутинных задач.
- Наличие экосистемы с командами разработки разных типов: внутренние, внешние, партнерские. Предоставление интерфейсов для внешнего доступа, контроль этого доступа и биллинг.
Пирамида технологий
В соответствии с требованиями мы сформировали пирамиду технологий:
Теперь о составляющих каждого уровня в отдельности:
1. Уровень методологии
- Agile. Гибкий подход сейчас вызывает массу эмоций и противоположных мнений (на тему применимости в организациях разного масштаба). Для себя мы сформулировали главное: этот подход является основой для структурирования требований, быстрого прототипирования и создания MVP – проверки идей продуктов.
- DevOps. Эта парадигма требует максимальной автоматизации и «размывания границ» между разработкой и сопровождением систем. Она позволяет избежать потерь времени на рутинных операциях развертывания и сопровождения.
- Фабрика разработки. Движение артефактов от стадии аналитики до развертывания и эксплуатации созданного продукта должно быть непрерывным, без повторного создания артефактов на каждом следующем этап. Например, не должно быть ситуации, когда интерфейс сервиса сначала описывается в каком-то формате аналитиком, а затем разработчик вручную создает тот же интерфейс заново, но уже в другом инструменте.
2. Уровень инфраструктуры
- Контейнеризация (Docker). Единственный вариант обеспечить на данном уровне именно микросервисы — это уход от единого контейнера шины и использование отдельных контейнеров для каждого экземпляра сервиса. Это означает, что использование «тяжеловесных» серверов приложений, запускающих широкий набор библиотек при старте, также не подходит. Контейнер должен быть максимально легковесным и конфигурируемым, чтобы обеспечить запуск только нужного для сервиса набора функционала. И с этой точки зрения Docker замечательно подходит.
- Оркестровщик контейнеров. Контейнеры должны управляться инструментом, решающим типовые задачи отказоустойчивости, балансировки и унификации развертывания/остановки/запуска. При этом данный инструмент не может быть аналогом шины с ее монолитным контейнером.
3. Прикладная архитектура
- Микросервисная архитектура (MSA). Вопрос о точном определении микросервиса до сих пор открыт. Но для полноценного развития архитектур интеграции и систем мы определили следующие ключевые свойства микросервисов:
| Свойство | Пояснение | |
| 1 | Разделение интерфейса и имплементации сервиса | Данное свойство унаследовано от SOA и требует, чтобы изменение реализации не требовало изменения интерфейса. А вызов сервиса требовал только знания интерфейса, без понимания тонкостей реализации сервиса. |
| 2 | Хорошая гранулярность | Микросервисы должны быть относительно небольшими («правило двух пицц») и отделены друг от друга так, чтобы изменения функциональности в какой-либо предметной области концентрировались максимально в одном микросервисе. |
| 3 | Разделение сервисов на всех уровнях | Микросервисы должны быть полностью отделены друг от друга. На уровне интерфейсов и на уровне исполнения — каждому свой контейнер исполнения. На уровне данных — микросервис имеет доступ только к «своим» данным и ничего не знает об особенностях БД соседнего микросервиса. |
| 4 | Унифицированное взаимодействие | Если микросервису требуются данные, доступ к которым обеспечивает другой микросервис, должен работать именно вызов интерфейса. Ни в коем случае не доступ через БД в соседнюю схему. |
Обратите внимание: для MSA нет обязательного требования повторного использования!
4. Уровень модели данных
- DDD (Domain Driven Design). Один из самых сложных вопросов — тот набор правил, по которым создаются микросервисы, и обеспечение их связи с более ранними этапами аналитической проработки ПО. Мы попытались оттолкнуться от концепции DDD с двумя основными целями. Во-первых, это позволяет сформировать домены в предметной области и удачно связать их с продуктовыми командами (agile!). Во-вторых, помогает формировать микросервис как API работы с определенным бизнес-объектом — соответствуя ресурсу для RESTful сервиса.
- Домены соответствуют продуктам банка. Это позволяет отойти от классического разделения на фронт, бэк и интеграцию, прийти к единству с продуктовыми командами.
5. Уровень интеграции.
- API Management и подход API First. Интеграция с использованием шины подразумевает «нарезание» интеграционных потоков от фронта к бэку с повторным использованием сервисов. В новом же варианте мы ориентируемся на подход «API First». Бэковые системы готовят максимально общие API. Интеграция строится по принципу базового кристалла: разработчики фронтальных систем выбирают нужные им вызовы API, опубликованные на портале API Management.
- Open API. Open API подразумевает использование системы API Management для организации доступа и работы принципиально разных категорий разработчиков — внешних, внутренних, партнерских участников экосистемы. Фактически, мы получаем публичное API организации.
Изменения в архитектуре
Исходя из нового сочетания технологий, мы представили то, к чему хотим прийти. На рисунке ниже — схема нашей нынешней инфраструктуры с интеграционной шиной. Рядом — та схема, к которой мы стремимся.
Что меняется? Изначально на уровне бэк-офиса любая АБС имеет бизнес-логику и источник данных. Мы стремимся к тому, чтобы бэк-офисные системы свелись исключительно к хранению и «ядерному» функционалу, где изменения были бы редкими. А продуктовая логика ушла на уровень микросервисов, позволяющих гибко менять и создавать продукты, разделенные по доменам.
В масштабах канала мы планируем на основе микросервисов сформировать и управлять логикой, «размазанной» по слою фронт-энда. В итоге сами фронтальные приложения будут содержать только канальную логику, то есть нативные приложения для автоматизации нужных каналов обслуживания запросов.
Все управление доступом будет осуществляться через портал API Management, где будут описаны и опубликованы все API. Здесь любой разработчик сможет получить о них всю информацию и включиться в фабрику разработки. В ней с помощью технологий GitLab организован непрерывный цикл работы — планирование, разработка, тестирование, выпуск и эксплуатация.
Схема API Management и Open API
Что дальше?
Изменения такого масштаба не проходят без сложностей. В основном они связаны с разбиванием на микросервисы монолитных коробочных систем, а также с восстановлением связей в «черных ящиках» нашей ESB и Data Silo. С моделью микросервисов заметно теряет актуальность использование BPM-движка для построения бизнес-процессов. И сейчас для нас очень важным становится вопрос его альтернативы — event-driven-архитектуры и хореография. Мы также планируем перейти от чистого DevOps к DevSecOps, который будет включать требования ITSec, и разделить наш Data Silo в рамках доменов. Выполнение этих задач потребует активно собирать опыт для проверки и максимально эффективного использования описанных концепций.
Автор: Alexej Severov
