ESB (enterprise service bus): назначение, функционал, новые подходы к развитию

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

Что такое интеграционная шина и как она устроена

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

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

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

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

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

Если в одну из систем потребуется внести изменения, это никак не повлияет на работу других корпоративных приложений. За все эти задачи будет отвечать только шина данных ESB[2].

Таким образом, ESB-подход, в отличие от традиционной архитектуры «точка-точка» (когда сервисы напрямую взаимодействуют друг с другом), обладает большей гибкостью. Сценарии интеграции можно модифицировать с минимальным вмешательством разработчиков.[3]

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

Несколько слов о том, как устроена интеграционная шина. Решение включает в себя несколько компонентов:

• Брокер сообщений — обеспечивает управление очередностью сообщений и выступает посредником между приложением-источником и приложением-приемником;
• Комплект адаптеров — программных компонентов, которые служат для связи приложений с ESB и преобразуют один интерфейс в другой. Чем больше различных адаптеров заложено в интеграционную шину, тем шире ее функционал;
• В современных ESB-решениях реализованы принципы микросервисной архитектуры. В соответствии с ними весь функционал системы распределяется между микросервисами, каждый из которых может работать независимо от других;
• Средства для контроля и мониторинга.

Интеграция программных модулей

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

Маршрутизация сообщений

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

Преобразование сообщений

Данные из разных систем могут быть представлены в различных форматах — XML, CSV, JSON, DBF и других. При классическом подходе «точка-точка» это затрудняет процесс «общения» приложений между собой. Сервисная шина предприятия решает проблему, преобразуя данные из неподходящего формата в подходящий. Например, если нужно отправить одно и то же сообщение и в ERP, и в CRM, ESB трансформирует данные нужным образом и передаст в соответствующие системы.

Масштабируемость

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

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

Чем отличается микросервисная архитектура от традиционного подхода с ESB шиной?

Ее функциональность разбита по маленьким сервисам, каждый из которых отвечает за отдельную бизнес-задачу (решая ее в совершенстве), поддерживается одной командой и может работать изолированно от других. Централизованной базы данных здесь нет, у каждого сервиса — свое хранилище информации. ESB при этом выполняет лишь функцию транспорта, являясь по сути просто брокером сообщений. Взаимодействие между пользователем и сервисами также осуществляется через API, но программный интерфейс не содержит бизнес-логики[5].

Независимость микросервисов друг от друга обеспечивает ряд преимуществ с точки зрения эксплуатации и развития информационной системы предприятия:

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

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