Esb что это такое
Сравнение ESB-решений, популярных на российском рынке
Содержание
В конкурентной борьбе побеждает тот, кто умеет быстро масштабироваться, быстро реализовывать партнёрские проекты и вкладывать в рост минимум средств. Традиционное представление об интеграциях диаметрально противоположно этим приоритетам. Сроки и стоимость реализации непонятны, эффект непредсказуем, вместо ожидаемого преимущества — неопределённость.
Парадигма low-code гораздо ближе к приоритетам бизнеса. Программное обеспечение, которое работает в этой парадигме, позволяет ускорить разработку и внедрение новых систем, интеграций и фич в разы.
Один из продуктов, работающих в парадигме low-code, — ESB-система (сокр. от англ. enterprise service bus, рус. «сервисная шина предприятия»). ESB — это набор программного обеспечения, которое работает как единый центр для обмена сообщениями между информационными системами и приложениями. Сервисная шина позволяет легко настраивать маршруты движения сообщений, хранит историю сообщений, фиксирует путь каждого из них.
ESB не требует сложной и длительной разработки каждый раз, когда нужно соединить системы, которые изначально не спроектированы для совместной работы. Более того, бóльшая часть работы обеспечивается визуальными средствами разработки. При интеграции главным становится бизнес-анализ, а не технические аспекты этой интеграции.
ESB — это не монолитная система, а слой в IT-инфраструктуре компании, который состоит из нескольких продуктов. Каждый из них берёт на себя одну или несколько функций сервисной шины. В этой статье мы разложим слой ESB по функциям и расскажем, как эти функции реализованы в продуктах, популярных на российском IT-рынке.
Из чего состоит слой ESB
Студия — графическая среда для разработки быстрых интеграций. Системы, параметры, действия визуализированы и максимально понятны. Функционала студии хватает на бóльшую часть действий, таких как передача и получение информации, преобразование и сбор атрибутов из одних потоков в другие. Здесь же можно задать параметры, которые ESB-шина должна отслеживать, считать ошибкой интеграции и пр. Если в рамках интеграции нужно уникальное действие, его можно написать парой строк на традиционных языках (например, Java) или специально разработанных.
Без студии и, соответственно, без визуализации интеграций ESB не может считаться low-code решением.
Каждое из ESB-решений предлагает на выбор несколько возможностей размещения. Например, некоторые системы позволяют опубликовать интеграцию в частном облаке Kubernetes, OpenShift, Amazon вообще без настройки. Для публикации внутри вашего уникального кластера потребуется работа архитектора.
В этой статье мы разберём, как реализованы компоненты ESB в решениях, которые чаще всего предлагают на российском рынке: Talend, Mule, WSO2, Red Hat Fuse. Иногда разработчики дополняют список брокерами сообщений Apache Kafka (плюс Kafka Connect) и RabbitMQ, но эти два решения не являются ESB и рассматривать их в рамках данного разбора нецелесообразно.
Укажите свою почту, и мы будем присылать вам еженедельный анонс новых статей.
+ — студия есть в «коробке».
± — студия есть, но она сложнее в настройке и требует постоянного участия разработчиков, что идёт вразрез с парадигмой low-code.
Как видите, внутреннее логирование в ESB-системах реализовано практически идентично — с небольшими особенностями, индивидуальными для каждого из продуктов.
Дополнительно предусмотрено логирование во внешних системах, которые подключаются через коннекторы. Бизнес-аналитик должен прописать ключевые события в рамках интеграции, чтобы сообщения об этих событиях попадали в логи.
Логирование во внешней системе даёт ESB дополнительную гибкость. Скорее всего, у бизнеса масштаба enterprise в IT-архитектуре уже есть компонент для логирования, и системы не будут дублировать функции друг друга.
Резюме
Talend, Mule, WSO2 позволяют решить проблему скорости проведения интеграций и соответствуют парадигме low-code.
Red Hat Fuse по функционалу близка к предыдущим трём продуктам, но уже не может считаться low-code решением: даже для рядовых операций здесь нужен именно разработчик. Однако в ней сохраняется принцип самодокументируемости.
Apache Kafka и RabbitMQ являются не ESB-системами, а брокерами сообщений. Их недостаточно, чтобы создать полноценный слой ESB, они не дают никаких преимуществ в плане упрощения интеграций и масштабирования, но при этом могут стать частью слоя ESB.
Понятно, что каждое внедрение индивидуально и должно учитывать особенности бизнеса, продуктовую и IT-стратегию. Но из существующих решений именно low-code позволяет быстрее всего проводить цифровую трансформацию, масштабироваться, интегрироваться с партнёрами. Поэтому компаниям, которые заинтересованы в быстром росте с сопутствующей оптимизацией затрат на разработку, мы рекомендуем именно low-code решения: ESB, BPMS, CRM.
Отдельно обозначим, что само внедрение low-code ESB происходит не мгновенно. Как и всякая масштабная интеграция, оно требует времени и ресурсов: затрат на команду разработчиков, на серверы (при необходимости) и т. д. В этом low-code решения ничем не отличаются от привычных. Экономия на разработке начинается только после их внедрения.
Путешествие в мир сервисных корпоративных шин на IBM WebSphere ESB
Порядок
Чем большего размера система, тем более важен в ней порядок и единообразие. Если речь идет о комплексе систем большого предприятия, то его точно уж можно назвать системой большого размера. Конечно, всегда можно найти администратора, держащего в голове схему взаимодействия сотни серверов, или кучу томов несвязанной документации по каждому программному модулю, где описано, с чем и как он взаимодействует. 
Но намного проще иметь сервис (ESB), который позволяет проводить все взаимодействие через себя. При таком подходе часть архитектуры взаимодействия в любой подсистеме уже понятна – нет бардака в связях между системами, серверами и приложениями: все связано с ESB и ESB связано со всем.
Централизованное управление
Всегда удобнее производить настройку систем централизованно – будь то конфигурирование, адаптация к переезду серверов, обеспечение отказоустойчивости, распределение нагрузки, обработка ошибок либо мониторинг и аналитика.
Например, при переезде сервера БД не нужно залезать в конфигурацию всех существующих серверов приложений, и в настройки конкретных приложений в частности – достаточно иметь одну переменную среды в ESB, в которой указывается адрес БД, и тогда изменения нужно будет выполнить всего в одной точке.
Или же если одна из внешних систем была недоступна длительное время, а ни один запрос к ней не должен потеряться – можно воспользоваться сервисом обработки сбойных событий для «вбрасывания» недошедших сообщений тогда, когда это будет удобно.
Если вам нужно регулировать количество одновременных запросов к какой-либо системе, либо мониторить эти запросы, анализировать нагрузку, искать узкие места – вам нужно в центр управления обмена сообщениями – в консоль ESB-сервера.
Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее.
Во-вторых, при конфигурировании на стороне сервера именно среда работы приложения во многом может на него влиять, что позволяет переносить приложения между разными контурами (тестовым и продуктивным), тюнинговать и даже исправлять баги без внесения изменений в приложение.
Если использовать все эти преимущества, приложения получают способности истинного хамелеона – они настолько гибкие, что стают частью среды, в которой работают, и при этом привносят свой важный функционал.
Но гибкость приложений под IBM WebSphere ESB не ограничивается средой их работы. Громадный вклад в это делают возможности разработки. Поскольку, системы не только нужно иметь, где запускать, но еще нужно разрабатывать и дорабатывать, эти интересные пункты упускать нельзя:
SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).
Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. С другой стороны, она логично необходима ввиду выполнения имплементаций компонент в транзакционном контексте.
У каждой компоненты есть интерфейс(ы), имплементацию которого она предоставляет. Таким образом, связывая между собой компоненты, нет необходимости знать их внутренние особенности – достаточно того, что они реализуют необходимые интерфейсы.
Посредством данной архитектуры также можно решить все задачи, требующие параллельной работы, без «ручного» управления потоками (например, можно выполнять асинхронные вызовы нескольких компонент с отсроченным ответом).
Не java-компоненты, например, типов Export и Import, позволяют предоставлять сервисы для внешнего использования либо использовать внешние сервисы соответственно; компонента Mediation Flow обеспечивает низкоуровневый доступ к сообщениям, которыми обмениваются другие компоненты и позволяет производить различные преобразования при работе с гетерогенными интерфейсами.
Помимо интерфейсов, очень полезные возможности предоставляет IBM business object framework. Бизнес-объекты (БО), представлены xsd-схемами, используются как объекты для передачи данных в интерфейсах, как между компонентами, так и для коммуникации между модулями. Они же напрямую интегрируются, например, в wsdl-схему для описания веб-сервисов. То есть, например, если модуль «А» предоставляет свой функционал в виде веб-сервиса, модулю «Б» для его использования достаточно подключить интерфейс и готовые БО, и он сможет в полной мере работать с таким сервисом без создания каких-либо дополнительных java-объектов для передачи данных. БО также удобно использовать при обмене данными с БД, если эти данные используются другими компонентами (это, конечно, идет в разрез с паттерном «DAO», но избавляет от лишних java-объектов и операций переписывания данных «туда-сюда»).
Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент Export и Import. Поскольку связь с этими компонентами идет по интерфейсам и reference’ам, программный код полностью независим от используемого для взаимодействия протокола. Один и тот же функционал можно легким движением сделать доступным по любому количеству поддерживаемых протоколов и по любым нужным интерфейсам. На следующем рисунке показано добавление экспорта с SCA привязкой к компоненте, которая уже предоставляет свой интерфейс как HTTP, JMS и Web-сервис.
Удобства очевидны – гибкость, универсальность, повторное использование кода, быстрота разработки и модификации.
Кстати, SCA привязка использует особый протокол и предназначена для сообщения между модулями в рамках одного сервера/кластера. Взаимодействие через эту привязку менее ресурсоемкое и более быстрое по сравнению с другими протоколами.
Конфигурирование
Конфигурирование сервера и приложений осуществляется через IBM console сервера.
В ESB, как и в IBM WebSphere в общем, довольно много специфических возможностей и артефактов. Например, при использовании тех же импортов и экспортов, можно «на лету» конфигурировать end-point’ы соответствующих сервисов. Для вызовов сервисов можно настраивать policy set’ы с разнообразными правилами (например, можно установить поддержку механизма WS-AT, который позволяет вызывать веб-сервис в той же транзакции, в которой работает клиент; но транзакционность – это уже тема для полной статьи), устанавливать параметры аутентификации, подключать сертификаты и прочее.
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно использовать для массовой обработки ошибок.
Ну и, конечно же, можно настроить много чего другого согласно спецификации Java2EE, которая, иногда довольно строго, реализована в IBM Application Server.
Все вышеприведенное утверждает ESB как удобный, мощный и гибкий интеграционный аппарат, пусть и не всегда легкий в освоении. В дальнейшем нужно всего лишь научиться им пользоваться.
В статье использованы следующие изображения: 1 2 3 4 5
ESB (Enterprise Service Bus) — дословно можно перевести как «сервисная шина предприятия». ESB описывает вполне реальный программный продукт, в задачи которого входит упрощение вызова службы за счет управления всеми взаимодействиями на пути от потребителя службы к поставщику и обратно. Двумя наиболее часто упоминаемыми возможностями ESB являются преобразование сообщений и их маршрутизация. На шину ESB в архитектуре SOA возложена важнейшая задача обеспечения взаимодействия систем из слабосвязанных сервисов в сети. Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня, который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция).
Содержание
Основные функции ESB
Архитектура ESB
Основа архитектуры ESB — это идея использования общей интеграционной инфраструктуры всеми корпоративными приложениями на базе обмена сообщениями. Все приложения взаимодействуют через одну точку, которая, в случае необходимости, обеспечивает сохранность обращений, преобразование данных и транзакции. При этом целью интеграции приложения является создание единственного модуля (или адаптера), который отвечает за «подключение» приложения к ESB. Последующую обработку сообщений и их маршрутизацию в другие системы, ESB выполняет на основании установленных бизнес-правил самостоятельно. Этот подход обеспечивает превосходную гибкость, простоту масштабирования и переноса, поэтому в случае замены одного из приложений подключенного к шине, перенастраивать остальные не нужно.
Достоинства и недостатки
Достоинствами ESB является:
К числу недостатков ESB относят:
Разработка Enterprise Service Bus
Отличительной чертой Web-служб является то, что потребитель имеет возможность динамически связываться с провайдером службы. Все это происходит благодаря двум главным функциональным возможностям:
Самоописание Web-служб облегчило интеграцию с помощью объявления интерфейсов, которым нужно было следовать. Благодаря динамическому обнаружению службы, потребитель был освобожден от зависимости от конкретного провайдера с определенным адресом, однако, и эта возможность создала свои собственные проблемы. Достаточно тяжело было решить вопрос связи потребителя с провайдером раз и навсегда во время компиляции и потенциальным поиском нового провайдера при каждом вызове во время исполнения. Тогда ESB предложила другой вариант — дать возможность потребителю один раз динамически связаться с прокси-службой, имея при этом возможность использовать нескольких провайдеров и провайдеров, которые могут появиться в будущем, через эту прокси-службу. Все это говорит о том, что ESB делает службы доступными для их вызова потребителями и дает возможность потребителям найти службы программным способом.
Шлюз служб
Так называемый шлюз служб является краеугольным камнем синхронной ESB. Он выступает посредником между провайдерами и потребителями служб, оказывая при этом содействие в обработке синхронных вызовов с использованием брокера. Данный шлюз открывает доступ ко всем известным службам и прокси-службам каждой из них, поэтому он является своего рода «единым окном» для потребителя, желающего вызывать любую службу у любого провайдера, который известен шлюзу. Когда Web-службы координирует шлюз, они обладают способностью к самоописанию. Каждая служба предоставляет свой интерфейс с помощью WSDL, который состоит из следующих четырех частей:
Web-службы шлюза, а точнее их прокси-службы являются также обнаруживаемыми. Шлюз дает такую возможность в виде UDDI-службы. Чтобы найти адрес вызова службы потребитель подает запрос в UDDI-службу шлюза список провайдеров необходимой WSDL-операции и получает обратно адрес прокси-службы шлюза для этой операции.
Шина сообщений
Шаблон Message Bus (Шина сообщений) является основой асинхронной ESB. Шина сообщений — это набор каналов сообщений, которые настроены как пары каналов запрос-ответ. Каждая пара представляет службу, которую может вызвать потребитель, использующий шину. Потребитель посылает сообщение в очередь запросов службы и после этого выслушивает очередь ответов для получения результата. О том, кто предоставляет службу потребитель на самом деле не знает. Провайдеры служб также подсоединены к шине сообщений и прослушивают ее на наличие сообщений запросов. При наличии нескольких провайдеров службы, между ними происходит соревнование как между потребителями за получение конкретного запроса. Система сообщений, выполняемая шиной сообщений, функционирует как диспетчер сообщений и рассылает запросы провайдерам служб, оптимизируя эту рассылку в зависимости от степени нагрузки, сетевых задержек и т. д. После того как провайдер получил запрос, он выполняет службу и вносит результат в сообщение в очередь ответов, то есть провайдер и потребитель никогда не знают о месторасположении друг друга. Эта шина сообщений и является сущностью ESB.
Централизованная шина vs Service Mesh: как митап превратить в баттл
Когда мы поняли, что проводить очередной митап нам будет скучно, то решили превратить его в нечто более остросюжетное. А именно в дуэль, в поединок между двумя интеграционными подходами — ESB и Distributed — честь которых защищали тяжеловесные эксперты. В этом посте расскажем, как шел бой, и узнаем победителя.
Пара слов о формате
За централизованную шину выступил Александр Трехлебов, наш корпоративный архитектор. За децентрализацию — Андрей Трушкин, руководитель центра инноваций и перспективных технологий Промсвязьбанка. Они по очереди выступили с докладами о своих технологиях и ответили на разные вопросы, провокационные и не очень. Вот как оно было.
Почему ESB — это круто?
Для начала следует ввести в курс дела и рассказать, как все начиналось. Многие наверняка помнят, что на самом первом этапе всё происходило без всякой интеграции, когда каждая система общалась и проводила свое интеграционной тестирование с каждой другой системой.
Соответственно, если человек увольнялся или еще что-то с ним происходило, то никто не знал, как это все будет работать. Каждый комп взаимодействовал с каким-то сервером. Какой протокол, какое взаимодействие? Это все знал только тот человек, который работал в системе.
Затем появилась интеграционная шина. Она появилась не просто так, а потому что на ней были собраны основные протоколы и способы взаимодействия и можно было не заставлять системы описывать какие-то специфические вещи. Она могла с ними общаться с помощью своих внутренних алгоритмов.
Далее выяснилось, что чаще всего с шиной общаются через очереди или через REST.
Со временем, правда, необходимость в шине и REST во многих случаях отпала. Но это выглядело как откат назад, важные вопросы повисли снова:
Кроме того, производительность в централизованной системе гораздо лучше, чем в Distributed. Можно и на скорость рассчитывать, и на объем, и на доступность. Всё это потому, что это — одна система, обслуживанием которой занимается определенная команда.
Насколько уязвима эта система? Что будет, если один компьютер будет взломан?
Всегда есть резервирование и централизация. В случае, что кто-то один вышел из строя, то система будет работать.
Кто отвечает за шину? Ваша же команда или сторонние разработчики?
Во внутренней команде мы делаем операционные сервисы, обеспечиваем надежность, мониторинг. Если что-то не работает, мы знаем, где искать. Существует вопрос: «Можно ли доверять вендорам в таких случаях и сторонним командам?» Здесь нужен хороший мониторинг. Потому что за качество, в любом случае, отвечает внутренняя команда.
По мере развития шины сервисы не становятся связанными. Вы меняете сервисы релизами или как? Как быть с Agile?
Здесь мы подошли к фундаментальному вопросу. Интеграция — это не приложения. Когда-то было частью, но сейчас не так. Интеграционная разработка не является разработкой приложений. Она является разработкой интеграционных взаимодействий или разработкой в рамках какого-то отдельного проекта, но не конкретно одного приложения.
Ваши опасения касательно agile понятны. Эта модель используется, когда мы делаем отдельную систему, которая подключена к шине где-нибудь сбоку. Когда я работал в другом банке, там была такая система: месяц тестирования, месяц разработки. В итоге на шине все интеграционные взаимодействия быстро реализуются. Даже быстрее, чем их описывают аналитики, потому что системы разработки достаточно совершенны и просты. А agile применяется при разработке конечной системы.
Как долго команда ищет нужный ей сервис, и где она его ищет?
Все имеют мечту о том, чтобы существовала карта мира, на которой по континентам разбросаны все основные области бизнеса. И это даже частично реализовано. Туда заходит аналитик и начинает усиленно бродить по континентам, через какое-то время находит то взаимодействие, которое нужно. Дальше, если все подходит идеально, он его просто использует. Если нет — описывает в ТЗ, какие ему нужно дополнения. Было бы здорово иметь такой вариант, но пока актуально менее удобные системы, которые требуют намного больше времени и сил для работы с ними.
А может быть Service Mesh круче?
Начнем с того, что за 3-4 года действительно многое изменилось. Но что именно произошло? Произошла та самая банальность, которую регулярно повторяют все спикеры, и мимо которой мы также не можем пройти: мир меняется.
Требования к скорости изменений становятся огромными. При этом никуда не пропадают требования по надежности, требования по безопасности, а требования по нагрузкам только возрастают. Как мы видим, все пытаются захватить долю рынка, что неминуемо ведет к росту нагрузки на корпоративные системы и, соответственно, на интеграцию.
Действительно, ESB в свое время очень здорово помогла как шаблон технической реализации в части децентрализации приложений, разнесения логики по различным приложениям, унифицированного устройства для интеграции приложений между собой. Скажем так, условно-унифицированного.
А теперь представим, что систем в компании не 20 — ведь она стремится перейти к той самой архитектуре, которую называют модным словом «микросервисы». А что такое микросервис? Существует много определений, одно из них периодически использует Мартин Фаулер: это сервис, который в состоянии разработать mid-разработчик за один спринт. Представим сколько таких сервисов будет в крупной компании. Например, Netflix оценивает количество своих микросервисов в 800-900. В принципе, в компании, которая стремится построить партнерскую внешнюю экосистему, эти сервисы могут перевалить и за тысячу. А ведь каждый из таких сервисов в перспективе выдерживает грандиозную нагрузку и должен развиваться независимо.
А что с шиной? Если шина остается этим общим комплексом между ними, то получается, что она становится узким местом и задерживает разработку сервисов. Не просто потому, что она ждет эти самые сервисы, а потому, что она развивается отдельной командой, людьми, которые владеют этими самыми технологиями и навыками.
И теперь представим: у нас развивается, работает несколько десятков продуктовых команд. И каждая из них пилит несколько сервисов. А шину ведут две команды. Естественно эти команды с высокой степенью вероятности не смогут развивать эту самую интеграцию с необходимым уровнем скорости и качества.
Возникает вопрос: «Как нам обеспечить такую же быструю скорость, не теряя при этом доступности, безопасности и так далее?». Ответ очень простой: «Пусть эти сервисы взаимодействуют напрямую, без явного посредника».
Тогда поднимается следующий важный вопрос: «Как сервисам узнать друг о друге?». И здесь ответ тоже очень простой: можно придумать такую систему, с которой сервисы сами сообщали бы о себе. То есть в тот момент, когда сервис разработан, он будет самостоятельно публиковать информацию о себе в некоем реестре. И на основании этой информации, все сервисы смогут начать с ним взаимодействовать.
Таким образом и была сформирована концепция «сетки» сервисов — как она исходно называлась, «service mesh». Как некий промежуточный уровень интеграции между сервисами, который предоставляет такое интеграционное, как бы облачное решение.
Крупные компании сейчас стараются решать вопросы скорости разработки параллельно — находить для этого некое общее решение, распределенное и зачастую встраиваемое. В этом случае каждый сервис использует тот или иной набор готовых библиотек, чтобы автоматом при развертывании публиковать информацию в некий реестр.
Часто еще возникает вопрос: «Но что же делать с канонической моделью данных, источником которой, как правило, являлась ESB, в которую вложено так много средств и сил, чтобы ее реализовать и поддерживать?». Ведь она была стандартно-используемой моделью. Здесь встречный вопрос: «А какие преимущества она нам приносила? И не была ли она той самой точкой, которая задерживала нашу разработку?». Ведь при разработке сервисов модель расширяется все сильнее. Всегда будут возникать всё более новые задачи.
Если говорить прямо, то затраты на добавление новых устройств, организацию взаимодействия и т.д., как правило, существенно меньше затрат на поддержание в актуальном состоянии канонической модели данных ESB.
Также децентрализованные интеграции — это в значительной степени обеспечение той самой высокой доступности. Каждый из микросервисов является независимым, в том числе от других микросервисов, но при этом критично зависимым от внешней нагрузки, которая на него оказывается. Разворачиваемая параллельно с ним интеграция также может технологически реализовываться независимо.
Порой применение довольно тяжелого ESB в современных условиях не имеет смысла или даже наоборот, снижает качество решения. На пороге применение serverless-технологий, той самой инфраструктуры, которая не подстраивается под некие эфемерные нужды создаваемых решений, а поставляется уже в нужном сформированном для конкретного сервиса варианте. Сейчас это выглядит как что-то очень далекое, но мир меняется, как уже было сказано, довольно быстро.
Многие производители программного обеспечения идут этим путем в части своих решений по интеграции. Уже есть и фреймворки, которые по сути реализуют концепцию service mesh (те же Linkerd или Istio). Так же уже происходит в рамках размещения большого количества сетевых прокси и сервисов интеграции service mesh. Много общего с service mesh и у систем оркестровки контейнеров, например Kubernetes.
Можно ли на основе ESB построить Distributed? То есть, можно ли из одной системы сделать другую? И если да, то в чем смысл этих споров?
Здесь приходит на ум Гегель и его «отрицание отрицания». Когда одна идея повторяет себя на более высоком историческом уровне. Прийти от одному к другому, на мой взгляд, можно. Другой вопрос в том, как мы будем идти к этому. Ведь по сути сама концепция микросервисов и их реализация во многом похожа на ту концепцию интеграции, которая была изначально: взаимодействие микросервисов между собой, каждый с каждым.
Можно ли прийти к интеграции по принципам сетки, если мы идем от ESB? Собственно, Red Hat, ныне IBM, уже идет по тому же принципу. Достаточно посмотреть на их представление о концепции интеграционного стека и гибкой интеграции (Agile Integration). Они предлагают наличие большого количества интеграционных прокси, не перегруженных логикой. Самое главное — это прозрачность и то самое знание о сервисах, которое требуются всем вновь поступающим участникам взаимодействия.
Понимает ли ваш банк, что ESB отжил свое, если продолжает в него инвестировать значительные бюджеты?
Скажу честно, что вопросы бюджетов — коммерческая тайна. Что касается используемых подходов, то в данный момент у нас развивается параллель из двух подходов. В Промсвязьбанке действительно есть много систем, завязанных на шине. Они до сих пор интегрированы через шину. Но мы со своей стороны понимаем, что ESB — неперспективный подход и эффективнее инвестировать в распределенные интеграции не используя шину. Это наш стратегический приоритет сейчас.
Где место бизнес-мониторингу в distributed system?
В децентрализованной интеграции наличие большого количества сервисов не исключает наличия бизнес-мониторинга. Все это может закладываться на уровне соответствующих фреймворков. Соответственно, данный мониторинг может сливать информацию в некое хранилище, отвечающее за данные. Эти данные там анализируются, и готовится сводный отчет.
Как Вы видите план перехода к децентрализованной интеграции?
Переход к децентрализованной интеграции имеет смысл рассматривать в контексте перехода к новым архитектурным принципам. Это сложный переход, который не может произойти одномоментно. Да, можно пытаться провести его в формате «большого взрыва», но этот сценарий вариант несет в себе серьезные риски. Более логичным видится вариант создания нового контура параллельно с существующим и по мере его создания (в итеративном режиме) заведения в нем новых продуктов. По мере развития нового архитектурного контура туда могут переводиться и те продукты из текущего ИТ-ландшафта, которые выдержали проверку временем. Такой путь достаточно продолжительный – по оценкам до 4-5 лет – но вследствие итеративности можно получать результаты в режиме промышленной эксплуатации последовательно.
Кто же победил?
После трех интерактивных раундов с выступлениями, вопросами и ответами зал затаился в ожидании оглашения итогового результата. Наверное, вы догадываетесь, что победителем «PSB Battle» стал Андрей Трушкин и распределенная система.
В заключение предлагаем ролик, который поможет почувствовать атмосферу нашего баттла: