Когда сервисов много, работа легко может превратиться в хаос — для налаживания путей связи между ними понадобится много ресурсов, а любое нововведение повлечет за собой ряд изменений, которые нужно будет внести во все сервисы.
При этом масштабирование в такой ситуации превращается в кошмар.
Чтобы упростить весь этот процесс, существует Enterprise Service Bus — архитектура, которая помогает навести порядок и облегчает взаимодействие между службами.
Всем привет, меня зовут Даниил Солодухин, я программист в студии ITT. В этом тексте я расскажу об особенностях ESB, а также объясню, почему он полезен в работе.
Много услуг – много проблем
Прежде чем мы перейдем к обсуждению ESB, давайте определим проблему.Представьте, что у вас есть система большого количества сервисов — каждый делает что-то свое и обеспечивает часть функционала всей системы.
Некоторые занимаются авторизацией, другие хранят пользователей, историю, данные кредитных карт и так далее.
Это могут быть не микросервисы, а большие монолиты.
Для нас нет разницы.
Сервисы общаются между собой простым способом — каждый вызывает или отправляет запросы к нужным ему сервисам.
В результате получается схема, где каждый из них связан с несколькими другими.
Чтобы добавить пикантности схеме, напомню, что протоколы тоже могут быть разными.
Некоторые сервисы могут работать через HTTP, некоторые используют JMS, некоторые используют файловый ввод-вывод (они ждут файлы в определенных каталогах на своем сервере), а некоторые компоненты этой схемы обычно обмениваются данными по электронной почте.
Если вы думаете, что я нагнетаю ситуацию, то нет. Это реальная картина, я сталкивался с таким: такое бывает, когда у тебя достаточно старая система — сервисы вводились в эксплуатацию в разное время, разными командами.
А еще хуже, когда сервисы не ваши, а какие-то сторонние, и вам нужно с ними общаться.
Вы не можете никак повлиять на то, какие API, какие протоколы они будут использовать.
Такой хаос встречается повсюду.
Одна группа исследователей Я заметил, что разработчики склонны использовать примерно одинаковые подходы к решению проблемы.
В 2003 году эта группа опубликовала книгу «Шаблоны интеграции предприятия» — в ней исследователи собрали и структурировали все накопленные паттерны интеграции, используемые программистами.
На картинке ниже схематично изображены все выкройки, собранные в книге.
Вероятно, вы увидите там некоторые знакомые термины: например, Шина сообщений, Канал, Сообщение, Маршрутизатор, Точка.
Сейчас многие из нас используют эти закономерности в повседневном развитии, воспринимая их как нечто естественное и само собой разумеющееся, и все это пришло к нам оттуда.
Используя эти закономерности, мы можем превратить нашу хаотичную систему во что-то красивое и понятное.
Некоторым из вас этот шаблон может показаться знакомым – это потому, что шаблоны поведения у всех примерно одинаковы и приводят к одинаковым решениям.
Это схема архитектуры ESB, которая позволяет организовать хаос, сделать систему более красивой, удобной и масштабируемой.
Что такое ЕСБ
ESB — это подход к решению задачи интеграции, определенный набор принципов, правил, закономерностей и способов их использования.Архитектура ESB ориентирована на сервисы.
Соответственно, он событийно-ориентированный, то есть мы ориентируемся на то, что общаемся с нашими сервисами посредством сообщений — отправляем и получаем их.
Более того, ESB — это распределенная система.
То есть это может быть как один сервер, на котором проходит все взаимодействие ваших сервисов, так и несколько серверов.
Это также может быть федеративная система, когда у нас есть несколько отдельных серверов, каждый со своим ESB, и они подключаются друг к другу и обмениваются сообщениями.
При желании мы можем ввести эту систему в еще более глобальную систему.
Или, наоборот, взять и отключить какую-то часть.
С другой стороны, ESB — это специфическое программное обеспечение.
Возникает своеобразный дуализм понятия — это и архитектура, и одновременно программное обеспечение.
Вот небольшой список наиболее известного промежуточного программного обеспечения, реализующего архитектуру ESB:
- ИБМ МИБ
- Red Hat JBoss Фьюз
- Мул ЭСБ
- Сервисная шина Oracle
- Apache СервисМикс
- Апач Верблюд
Что нам предлагает ESB?
Мультипротокольный .Это решение одной и той же проблемы, когда разные сервисы общаются по разным протоколам.
Представьте, что вы не используете ESB и вам нужно добавить еще один сервис, который будет взаимодействовать с несколькими другими, используя разные протоколы.
Тогда вам нужно будет включить поддержку этих протоколов.
Если вам нужно изменить протокол, вам нужно будет изменить его во всех связанных сервисах.
В такой схеме масштабирование становится головной болью.
ESB позволяет этого избежать — всю работу с протоколами, их обработку и преобразование он берет на себя.
Соответственно, каждый сервис может общаться по одному протоколу, например HTTP. Ему больше ничего знать не нужно.
Если он хочет отправить сообщение другой службе, он делает это через HTTP на ESB. А потом конвертирует HTTP, например, в JMS и наоборот. Получается, что внутренняя работа скрыта от сервисов: от них не требуется знать, кто как работает, их задача — отправить сообщение в шину.
Соответственно, если один из наших сервисов меняет протокол, например, он был HTTP, стал JMS, то нам нужно это исправить в одном месте — на самой шине.
Количество протоколов, которые поддерживает шина, зависит от конкретных решений.
Например, IBM ESB поддерживает множество опций, а Sprint Integration — лишь немногие.
Вычисление точных значений может быть затруднено.
Но тот же Camel утверждает, что в целом поддерживает около 250 различных протоколов и вариантов преобразования данных.
Помимо распространенных, Camel поддерживает, например, Slack, Jira. То есть вы можете создавать задачи в Jira из своего ESB. Преобразования данных .
Даже если мы используем один и тот же протокол, у нас могут быть разные форматы данных — один сервис может предоставлять ответ в формате XML, второй — в Json, третий — в двоичном формате.
Все это нужно как-то преобразовать, чтобы разные сервисы понимали друг друга.
ESB также берет на себя эту задачу.
Многие ESB предоставляют довольно удобные графические инструменты для преобразования данных.
Например, у вас есть XML с одной и другой стороны, но разные XSD. Вы открываете графический инструмент, и он наглядно показывает, как все работает. Вот как выглядят преобразования данных в графическом представлении.
Я взял пример от Red Hat JBoss Fuse. 
С одной стороны есть входящие данные, с другой — формат исходящего сообщения.
Между ними можно настроить отображение одного типа в другой.
Маршрутизация .
Это один из важнейших компонентов ESB. Допустим, нам нужно отправить сообщение от одного сервиса к другому.
Затем нам нужно задать маршрут: например, если приходит сообщение от этого сервиса, нам нужно отправить его туда.
Но ESB обеспечивает гораздо более сложную логику маршрутизации.
Например, можно добавить фильтры: «Если пришло сообщение, и есть такое-то поле в таком-то значении, то мы отправим его туда.
Если оно имеет другое значение, мы отправим его сюда».
Вы также можете добавить мультиплексирование, чтобы одно сообщение можно было отправить нескольким клиентам.
Более того, мы можем отправить его всем сразу или определенному списку.
Вы можете разделить сообщения.
Например, пришло одно большое сообщение, мы разделили его на пять маленьких и каждую часть отправили в свой сервис.
Мы снова собрали ответы в одно большое сообщение и отправили обратно.
ESB берет на себя эту логику.
Другая возможность — добавить условные маршруты.
Например, пришло какое-то сообщение, но нужного поля нет, поэтому дальше мы его обрабатывать не будем.
Вы также можете встроить балансировщик нагрузки на уровне ESB — циклический перебор, аварийное переключение и т. д. Вот пример маршрутизации с использованием Red Hat JBoss Fuse. 
Логика здесь довольно проста.
Читаем что-то в файле.
Далее идет элемент Choice, то есть некоторый выбор, куда его отправить.
И в зависимости от параметров мы можем отправить наше сообщение по тому или иному пути.
Гарантированная доставка сообщений .
Если сообщение было отправлено, получатель обязательно его получит. Даже если он не был «жив» в тот момент, когда он появится и подключится к ESB, это сообщение ему все равно будет доставлено.
Здесь необходимо сделать небольшое замечание.
Camel не гарантирует эту доставку — если доставлять некому, сообщение будет потеряно.
Никто не будет хранить его для вас.
Если вы используете Camel и хотите иметь полную версию ESB, вам придется предоставить гарантию доставки самостоятельно.
Мониторинг .
ESB позволяет увидеть, как вообще идет ваш процесс: где в данный момент находится сообщение, куда оно направляется, помогает собирать статистику и так далее.
Все это доступно «из коробки» (но не в Camel).
Интегрированные инструменты разработки (IDE, низкий код).
Эта возможность позиционируется чуть ли не как главная «торговая особенность» ESB. Он позволяет самостоятельно внести некоторые изменения в процесс и не трогать для этого разработчиков.
Например, сегодня вы решили, что сообщения должны идти в какую-то другую систему, а завтра поменяете ее обратно и все продолжит работать.
Но проблема такого подхода в том, что понять IDE не так-то просто.
Рядовой менеджер вряд ли захочет в это вникать.
Тем не менее, возможность перетаскивать эти элементы на какой-нибудь Canvas с помощью мыши выглядит довольно интересно.
Например, на одном из наших проектов у нас был очень большой процесс — мы унаследовали его исторически, переделать его было просто невозможно, поэтому мы использовали его как есть.
А что нам помогло, так это возможность быстро прокрутить мышкой и посмотреть, куда идут сообщения и как вообще работает процесс.
В какой-то момент мы даже импортировали весь наш процесс в картинку в IBM Integration Designer, распечатали и повесили на стену — получилось полотно от потолка до пола, два на три метра.
А если нужно было разобраться, как все работает, вы просто подходили к стене и проводили карандашом по стрелкам.
Но у этого подхода есть и недостатки.
Очень сложно работать с системами контроля версий.
Например, если два человека одновременно исправили какой-то процесс, а потом нужно его объединить, то это боль.
Каждый элемент на графической схеме имеет свой идентификатор в виде порядкового номера.
Если в схеме 100 элементов и вы добавляете еще один, у вас получится 101 элемент. Если добавить еще один, то это будет элемент 102. Соответственно, если два человека одновременно добавят элементы, то у одного будет ID 101, а у второго ID 101. И когда вы начнете это объединять, то не факт, что Git вообще будет Воспринимайте это как конфликт. А потом запускаешь приложение и обнаруживаешь, что оно у тебя не работает. Это всего лишь один пример, на самом деле здесь очень много места для ошибок.
В какой-то момент мы пришли к выводу, что невозможно, чтобы два человека одновременно провалили задачи, предполагающие корректировку самого процесса.
То есть нужно заранее планировать и декомпозировать задачи: чтобы один писал Java-код, а второй занимался исправлением схемы.
К сожалению, мне пришлось увернуться.
Если у вас большая команда (более десяти человек), вам, скорее всего, это не удастся.
Я до сих пор не нашел хорошего решения.
Видимо, каждый страдает в той или иной степени.
Когда ESB следует использовать его? Когда у вас много сервисов, все они имеют разные протоколы, разные форматы данных и логика интеграции довольно сложная.
Одна из самых приятных особенностей ESB — простота масштабирования этих систем.
Если вы добавляете какой-то сервис, то достаточно будет изменить код или схему всего в одном месте.
Вы можете в любой момент сменить сервисы, например переключиться с HTTP на JMS. И это коснется только самого сервиса и автобуса.
Остальная часть системы может даже не знать, что что-то изменилось.
И это удобно.
Также масштабирование можно рассматривать не только в рамках одного ESB-сервера, но и организовывать федеративные системы.
И в любой момент вы можете что-то переподключить, отключить, удалить или добавить.
Еще многие отмечают, что с ESB удобно разрабатывать итеративно — последовательно подключая новые функции и сервисы.
Их можно добавить с помощью федерации.
Например, если вы собрали ESB с определенным количеством сервисов, то в дальнейшем вы сможете расширить свою систему, подключив ее к более крупной системе и все будет работать.
Теги: #Разработка игр #услуги #gamedev #esb
-
Ирландская Республика
19 Oct, 24 -
Шпинаты И Торнадо
19 Oct, 24 -
Сегодняшние Проблемы С Гласными В Gmail
19 Oct, 24 -
Командная Разработка С Помощью Gwt В Eclipse
19 Oct, 24 -
Изучение C# — Практический Подход
19 Oct, 24
