Комментарии 19
Я последний раз работал с кондовой ESB на Apache Camel в 2018 году. Типичная "интеграция" там выглядела так: система А хочет общаться с системой Б, поэтому давайте запилим адаптер на шине. И 9 разрабов пилили эти адаптеры и изображали из себя очень важных спецов.
А единственный резон существования шины был в том, что системы А и Б - это проприетарные закрытые серые ящики, которые невозможно по-человечески дорабатывать. То есть шина это просто костыль.
Потом костыли перестали быть актуальными не потому, что он не модные, а потому что хромота прошла - написали свое вместо серых ящиков.
Это очень круто, когда у вас есть система А и система Б, которые нужно подружить. Тут даже как костыль шина не нужна - проще написать свой маленький адаптер, который свяжет эти две системы. А если этих систем у вас целый алфавит от разных вендоров? Да еще и двух/трехбуквенные сочетания используются! Тут явно не одна команда должна заниматься интеграцией всего со всем. А ведь каждая команда пишет как умеет - кто-то сделал на Go, кто-то написал на Java. А кому-то вообще было нечем заняться и он решил запилить всё на Ассемблере, производительность же... Написал и уволился, так как стало скучно. Как потом всё это поддерживать? Как разобраться в этом зоопарке? На мой взгляд, именно эти задачи в первую очередь решает корпоративная шина - единообразие и стандартизация при создании интеграционных решений.
Честно говоря, не совсем понял этот посыл про Open Source с этими всеми картинками про "open source автомобиль" и тд и тп.
Особенно, с учетом того, что рассматриваемая в исходном обзоре система (с которого, собственно, началось - https://habr.com/ru/companies/w_code/articles/896448/), базируется, собственно на том самом Open Source.
Или "это другое"? Т.е. когда комания сама пишет себе "нечто" на Open Source - это "криво и нестабильно", а если коммерческая компания продает свое, написанное с использованием Open Source - это уже "прямо и стабильно"?
Так и не увидел разгрома вот этого тезиса:
А вендор, при всем уважении, продавая "мультитул", который позволяет все, подсаживает клиента на аутсорс по настройке своей платформы.
И, видимо, и не увижу.
Гладко было на бумаге, да вот только зачастую нет альтернативе шине или чему-то мидлварному вроде нее. В больших компаниях, ну например банках, оч много АБС которые в силу разных причин проще связать с другой такой неповоротливой АБС, шиной, нежели вкручивать в эти АБС коннекторы к кафке. Ну например, АБС поставляет вендор для которого компания оплачивает N доработок в месяц за K рублей, и на квартал вендору поставлены уже более приоритетные задачи, а расширять договор - не бюджет и вообще долго и сложно. А еще, стоимость этих доработок у вендора, как правило: оверпрайс. А еще, иногда нужно синтегрироваться с системой на которой работают 2-3 человека которые не в ресурсе затащить коннектор в проект, но сваять вызов апи на корп шине коробочными средствами - вполне. В общем, жизнь - она сильно сложнее, чем слабая, маркетинговая статья на хабре.
Я как "шинник" могу сказать про ESB ПО следующее: суть шины в централизации. Вместо того чтобы размазывать интеграционный код ровным слоем по всем языкам и платформам, которые имеются в более-менее крупной компании, мы стремимся централизовать его. Понятно, для того чтобы извлекать стандартные плюсы централизации: гибкость к изменениям, шире возможности в оперировании (при расследованнии инцидентов в передаче данных), ниже стоимость, выше скорость разработки. Понятно, что на 100% этой цели достичь невозможно, все-равно останутся какие-то "хвосты" в каких-то системах. Но даже приближение дает огромное преимущество над ситуацией когда выгрузки-загрузки написаны непонятно кем, на чем и кто в лес, кто по дрова ("лоскутная интеграция").
Очевидно, что если кто-то использует "Кафка" и "гарантированная доставка" в одном предложении - он не совсем в теме. Кафка вообще не про гарантированную доставку. Представим, что мы выгружаем какие-то документы в 1С через Кафку. Что произойдет если при загрузке части документов случится конфликт блокировок (потому что база сильно нагружена в текущий момент). Ничего хорошего. Сообщения прочитаны, офсет сдвинут - до свидания. Что произойдет на шине:
залогируются сообщение в 1С и ответ 1С для анализа проблемы
полетят алерты отвественным сотрудникам
без вмешательства человека шина попытается доставить эти документы позднее (в соответствие с настроенной политикой: увеличивающиеся интервалы, до истечения времени жизни сообщения/кол-ва попыток и т.д.)
И это не требует ни строчки кода в 1С! Так как шина использует коннектор к OData 1С (всю интеграционную логику мы уже централизовали).
К тому же, современная ESB - это идеальная платформа для "корпоративного API": она уже имеет доступ ко всем данным всех систем нашего ИТ ландшафта, имеет кластеризацию "из коробки", широкие инструменты настройки и контроля доступа к данным, спецификации, документацию, API разворачивается "по нажатию одной кнопки" и т.д. Если, конечно, это "правильно приготовленная" ESB.
Вот то что этот паттерн недооценен и многие просто даже не думают о том чтобы решать вопросы интеграции приложений стратегически - это да...
Ничего не имею против шин, но что касается 1С и кафки: а что мешает выключить автокоммит и не сдвигать оффсет, пока 1С внутри себя точно не прожуёт очередной документ?
Потому что один застрявший документ остановит весь поток. Это нормально сработает только если 1С не принимает документ из-за каких-либо временных проблем: перегружена база, сеть барахлит и т.п. А если проблема перманентная, например, невалидный с точки зрения 1С документ, то на этом документе весь поток и встанет. А ретрай механизмов у кафки нет, что вынуждает городить костыли.
Так это касается не только 1С, а вообще любого консьюмера. Если в архитектуре используется кафка - то изначально предполагается, что сервисы умеют сами разбираться со своими проблемами. Не прочитал - никуда информация не денется, прочитал и кинул коммит - сам разбирайся, что с этим делать.
В ActiveMQ или в кролике есть встроенные механизмы DLQ, но и свои проблемы тоже есть.
Так это касается не только 1С, а вообще любого консьюмера.
Вопрос был в контексте 1С, и я подумал, что ответ в этом же контексте будет смотреться органичнее. Но вы верно подметили - ответ применим не только к 1С.
Если в архитектуре используется кафка - то изначально предполагается, что сервисы умеют сами разбираться со своими проблемами.
Сервис не может предусмотреть все возможные проблемы. И не важно, кафка там у него или нет. Поэтому ошибки делятся на два типа - которые мы знаем как обработать и все остальные. С первым типом всё понятно, а вот со вторым уже не очень.
Допустим, встретилась ошибка сети. Очевидно, что коммитить оффсет нет смысла, так как все последующие сообщения так же упадут с этой же ошибкой и лучше ретраить текущее сообщение до победного, либо до изменения ошибки на какую-то другую.
А если возникла ошибка, которую никто никогда не видел? Можем ли мы блокировать чтение топика, отправив сообщение в "ретрай до победного"?
Типичным вариантом обработки всех подобных неизвестных ошибок является изъятие проблемного сообщения из топика и отправка его в отдельную независимую ретрай схему с увеличивающимся интервалом между попытками. И в системах на кафке такая схема делается либо очень сложно, либо с привлечением сторонних инструментов.
Да, спасибо! Гарантированная доставка так или иначе крутится вокруг ретраев. Поэтому Кафка, хороший, там где это уместно, инструмент - не про гарантированную доставку.
Я, на самом деле, на шине использую аналогичный Кафке алгоритм, только вместо офсета - ID обработанных сообщений (с привязкой к консьюмеру). Что позволяет, спокойно пропускать "проблемные" сообщения и возвращаться к ним позднее. Это не годится только для потоков данных где критична последовательность сообщений в рамках топика. На практике, такое бывает крайне редко. В этом случае, просто тормозим поток до ручного разбора инцидента.
Если документ не валидный то мы просто обязаны остановить весь поток и разобраться с проблемой. Почему документ не валидный. Пофиксить и перезапустить. Ибо если проглотить как есть то жди бардака в данных
Честно говоря, кажется тема как-то не до конца раскрыта и хотелось бы чуть более развернутой аргументации.
Open source компоненты надо изучать, тестировать и командой поддерживать, а ESB-продукты почему-то не надо? Почему - не понятно.
Самописная шина, которую писали для конкретной организации, обычно криво написана, а вот, получается, ESB все пишутся сразу прямо и для любой организации сразу подходят. Кажется, что это не всегда так и все равно придется многое докручивать и ещё в довесок будет куча ненужного функционала.
ESB шаблон не устаревший, но реализуется теперь как набор self-hosted легковесных модулей. Чем это отличается от набора open source компонент поднятых как цепочка микросервисов не очень понятно.
Или здесь имеются ввиду какие-то вполне конкретные ESB продукты и для понимания аргументации следует сначала с ними познакомиться?
Нам 50 лет и мы не утратили свою актуальность....
кафка или кролик и заполировать айрфло, конекторы какието, вы еще про драйвера начните нудеть
«Зачем нужна шина данных, если есть Apache Kafka?» и еще 3 популярных аргумента против ESB