Что такое корпоративная сервисная шина?
Корпоративная сервисная шина (ESB) – это программный архитектурный шаблон, поддерживающий обмен данными между разнородными приложениями в режиме реального времени. В крупных организациях есть несколько приложений, выполняющих необходимые функции с использованием различных моделей данных, протоколов и ограничений безопасности. ESB упрощает интеграцию приложений, выполняя такие операции, как преобразование данных, перевод протоколов, маршрутизация сообщений. Приложения передают соответствующие данные в ESB, а тот преобразует и пересылает их другим приложениям, которые в них нуждаются.
В чем преимущества корпоративной сервисной шины?
Концепция корпоративной сервисной шины (ESB) позволяет стандартизировать и упростить связь, обмен сообщениями и интеграцию между сервисами в организации. Далее мы приводим некоторые преимущества для небольших реализаций архитектуры ESB.
Улучшенная интеграция приложений
ESB предлагает центральную платформу для интеграции корпоративных приложений. Организации могут легко интегрировать все типы систем и приложений независимо от используемых технологий или протоколов. Это упрощает организациям обслуживание и масштабирование своих приложений, а также управление ими.
Повышение эффективности разработчиков
Разработчики быстрее создают приложения, используя готовые коммуникационные сервисы, предоставляемые ESB. Команды распределяют расходы на инфраструктуру и выделяют серверы для комбинированного использования. Они сокращают накладные и эксплуатационные расходы, одновременно повышая общую эффективность. ESB также может ускорить выход на рынок и снизить затраты на разработку.
Усовершенствованный контроль и отображение информации
С помощью ESB организации могут отслеживать поток данных и сервисов в различных приложениях, а также быстро выявлять и устранять любые возникающие проблемы. Благодаря этому организации могут обеспечить доступность, надежность и безопасность своих приложений.
Как работает корпоративная сервисная шина?
Корпоративная сервисная шина (ESB) работает на принципах сервис-ориентированной архитектуры (SOA).
Сервис-ориентированная архитектура (SOA) – это метод разработки программного обеспечения, который использует программные компоненты, называемые сервисами, для создания бизнес-приложений. Каждый сервис предоставляет бизнес-возможности, и несколько сервисов также могут взаимодействовать друг с другом на разных платформах и языках.
Платформа ESB предоставляет коммуникационные сервисы, которые приложения используют для взаимодействия друг с другом. В качестве примеров можно привести преобразование сообщений и протоколов, маршрутизацию и аутентификацию.
Реализация ESB в AWS
Далее мы обсудим ключевые компоненты архитектуры ESB.
Адреса
В архитектуре ESB адреса можно рассматривать как точки входа или выхода в ESB.
Каждый адрес обычно имеет уникальный адрес или идентификатор. Можно внедрять адреса с помощью различных технологий, таких как интерфейс веб-сервиса, очереди сообщений или FTP-серверы. Адреса также могут обрабатывать сообщения различных типов, например XML, JSON или бинарные данные.
Гибкость архитектуры адресов позволяет ESB интегрироваться с широким спектром систем и приложений.
Адаптер
Компонент адаптера в инструментах ESB переводит сообщения между различными форматами и протоколами. Это означает, что программные приложения получателя могут правильно использовать их. Он также может предоставлять такие функции, как регистрация сообщений, мониторинг, аутентификация и обработка ошибок.
Шина
Шина является основным компонентом ESB для обмена сообщениями между адресами. Для маршрутизации сообщений используется набор правил или политик, основанных на различных критериях, таких как тип сообщения, контент или место назначения.
В конфигурации ESB можно определить политики, отвечающие требованиям сложных бизнес-процессов. Для связи с адресами используется множество соответствующих протоколов, таких как HTTP, JMS и FTP.
Шина работает следующим образом:
- Получает сообщение в одном адресе
- Определяет адреса назначения, проверяя правила бизнес-политики
- Обрабатывает сообщение и отправляет его на адрес назначения
Например, допустим, шина получает XML-файл от приложения, подключенного к адресу A. Она определяет, что XML-файл должен быть отправлен на адреса B и C. Для адреса B требуются данные в формате JSON, а для адреса C – функция HTTP Put. Адаптер преобразует XML-файл в формат JSON, а шина отправляет его на адрес B. Шина выполняет HTTP-запрос с XML на адресе C.
Каковы ограничения корпоративной сервисной шины?
Корпоративная архитектура отошла от корпоративной сервисной шины (ESB) из-за следующих ограничений.
Сложность
Внедрение и обслуживание ESB требуют специальных технических знаний, что делает эту задачу сложной и дорогостоящей. Привязка к поставщикам затрудняет переход на другое решение ESB и ограничивает возможности интеграции данных. Команды сталкиваются с длительным временем ожидания, поскольку только центральная команда управления ESB может интегрировать новые корпоративные приложения.
<t1>Масштабируемость</t1>
Программное обеспечение ESB вносит дополнительную задержку в коммуникацию из-за добавления уровней абстракции и обработки. По мере роста числа адресов и сопоставления коммуникационных сервисов ESB становится уязвимым местом и влияет на производительность. Стоимость внедрения систем высокой доступности и аварийного восстановления для серверов ESB также возрастает.
Сложность обновления
Усовершенствования интеграции ESB могут привести к нестабильной работе других подключенных компонентов и требуют тщательного тестирования перед обновлениями. Финансирование модернизации проектов ESB требует сотрудничества между командами, что может быть непросто.
Какие технологии заменяют корпоративные сервисные шины?
Сегодня использование корпоративных сервисных шин (ESB) ограничено в основном устаревшими системами, требующими сложной интеграции. Архитектурный шаблон ESB был заменен архитектурой микросервисов и другими технологиями.
Архитектура микросервисов состоит из очень небольших и полностью независимых программных компонентов с собственными протоколами связи, которые доступны с помощью легких API. По сути потребители должны использовать микросервис через его API, что устраняет необходимость в централизованном ESB.
Для получения дополнительной информации вы можете прочитать о микросервисах и API.
Рост облачных вычислений и архитектуры микросервисов привел к появлению новых технологий, которые часто рассматриваются в качестве альтернативы ESB. Далее мы обсудим некоторые из них.
API шлюзы
API шлюзы – это легкие компоненты, предоставляющие клиентам единую точку входа для доступа к нескольким сервисам. Они часто используются для управления API, гарантии безопасности и обработки трафика.
Сетка сервиса
Сетка сервисов – это выделенный уровень инфраструктуры для управления связью между сервисами в архитектуре микросервисов. Она предоставляет такие функции, как обнаружение сервисов, балансировка нагрузки и управление трафиком.
Архитектура, управляемая событиями
В архитектуре, управляемой событиями, сервисы обмениваются данными посредством асинхронной обработки событий, а не синхронных запросов. Событие – это изменение состояния или обновление, например помещение товара в корзину на сайте электронной коммерции. События могут либо отражать состояние (купленный товар, его цену и адрес доставки), либо быть идентификатором (оповещение о том, что заказ был отправлен).
Что такое шина события?
Многие организации перешли от корпоративных сервисных шин (ESB) к шинам событий. Шина события – это конвейер, по которому поступают события. Он объединяет компоненты приложения на основе событий, что упрощает создание масштабируемых приложений, управляемых событиями.
Правила, связанные с шиной события, оценивают события по мере их поступления. Каждое правило проверяет, соответствует ли событие критериям правила. Вы связываете правило с определенной шиной события поэтому правило применяется только к событиям, полученным этой шиной событий.
Продюсер публикует событие в шине события. Шина события фильтрует и оценивает события по мере их поступления на основе предварительно настроенных правил, а затем передает события потребителям. Сервисы для производителей и потребительские сервисы отделены друг от друга, что позволяет масштабировать, обновлять и развертывать их независимо.
Как AWS может удовлетворить ваши требования к интеграции приложений?
Amazon Web Services (AWS) предлагает набор сервисов интеграции приложений. Они помогают обеспечить взаимодействие между изолированными компонентами в микросервисах, распределенных системах и бессерверных приложениях. Если вам интересно, ознакомьтесь с дополнительной информацией в разделе Интеграция приложений на AWS.
Например, вы можете использовать эти сервисы в соответствии со своими требованиями:
- API шлюз Amazon для создания, публикации, обслуживания, мониторинга и обеспечения безопасности API в любом масштабе для бессерверных рабочих нагрузок и интернет-приложений
- Amazon EventBridge для создания шины события, соединяющей данные приложений из ваших собственных приложений, программного обеспечения как услуги (SaaS) и сервисов AWS
- Простой сервис очередей Amazon (Amazon SQS) для создания очереди сообщений для отправки, хранения и получения сообщений между компонентами приложений в любом объеме.
Начните интеграцию приложений на AWS, создав аккаунт сегодня.
AWS: дальнейшие шаги
Получите мгновенный доступ к уровню бесплатного пользования AWS.
