Как стать автором
Обновить

Асинхронная интеграция. Что это такое и как её дружить

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров10K
Всего голосов 3: ↑3 и ↓0+3
Комментарии4

Комментарии 4

Позволю себе несколько замечаний к статье.

  1. Сильно плавает глубина: текст позиционируется как ликбез, начинается с ввода и разбора терминов, а заканчивается паттернами проектирования приложений, сервис мешем и прочими высшими материями, которые и не разобраны детально (так как это не тема статьи) и лишний раз пугают начинающего читателя, так как кажется, что ему для собеседования и это тоже надо заботать;

  2. Ссылка на вики "издатель-подписчик" не работает;

  3. "Смешанная интеграция" - это уже прием для реализации флоу бизнес процесса, я бы не выделял это в отдельный вид, ну или оформил бы как вариацию асинхрона;

  4. Вы говорите, что шаблон издатель-подписчик это пример использования очередей и в качестве иллюстрации упоминаете почту, но это некорректно: реализация Pub-Sub шаблона это, скорее, радиоэфир, когда много подписчиков подключаются к топику одного издателя и получают сообщение, пока подключены. Почта - хороший пример "Очереди", но это паттерн Уведомление (или запрос-ответ, если там двусторонняя переписка)

  5. Слабая связанность и масштабируемость не являются плюсами асинхронной интеграции - эта связанность не "слабее" и не "сильнее", чем интеграционный контракт и пока он соблюдается, взаимодействие работает, что бы ни происходило внутри модулей (сервисов). При синхронном взаимодействии это будет работать так же.

  6. Паттерн стейт-машина больно уж мудрено описан

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

  8. Не согласен с выводом. Выбор интеграции базируется не на лучших практиках, а на исходных данных, включая известные ограничения. Лучшие практики - это опробованные ранее удачные решения для конкретных групп кейсов. Нельзя сказать "будем делать синхрон или сагу на хореографии, потому что вон гугл так сделал и у них все работает".

  9. Там же, в выводах: RESTful API это не противопоставление сервисов действиям: RPC API тоже может реализовывать сервисную модель.

Это из крупного. Я бы посоветовал все-таки определиться с аудиторией и если это ликбез - сделать статью чуть полегче и без тяжелой артиллерии.

Спасибо за содержательный комментарий!

  1. По п . 1 хотел дать общее представление о том, как вообще можно асинхронно интегрировать приложение. Изначально думал рассказать о том, что применяется для асинхрона, в плане технологий и про Стейт машину. Большая часть текста возникла уже в ходе изучения статей по теме и я понял, что в одну статью это не уместить, поэтому попытался верхнеуровнево описать смысл технологии/подхода для того, чтобы читатель просто узнал, что такое есть и оставить ссылку на материал для подробного самостоятельного изучения

  2. По п. 2 поправим

  3. По п. 3 я подумаю, как поменять формулировку

  4. Да, про шаблон издатель-подписчик согласен. Подойдет пример с доской объявлений. Поправим

  5. Внесу пояснения

  6. Подумаю как упростить

  7. Поправлю

  8. Тоже поправлю

  9. Тоже подумаю над правками.

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

Хорошо)



Спасибо за Ваш труд. Статья интересная. Вы делаете хорошую и полезную работу. Несете знания в массы. Единственный момент. Хотелось бы, чтобы в дальнейшем, при написании статей, Вы использовали более легкие и понятные формулировки. Сейчас объясню.

Пример 1
Как есть:Синхронная интеграция, это такая  интеграция, при которой система, отправившая запрос (назовем её система-1), не продолжает свою работу до тех пор, пока не получит ответ от системы-обработчика запроса (система-2).
Возможный вариант:
Синхронным (synchronous) называется такое взаимодействие между компонентами, при котором клиент, отослав запрос, блокируется и может продолжать работу только после получения ответа от сервера.
Преимущества:
НЕ продолжает работу = блокируется, но в этом случае читается легче.
Система1 и Система 2 = Клиент и Сервер, но в этом случае становится сразу понятно о чем идет речь.

Пример 2Как есть:
Асинхронная интеграция, это такая интеграция, при которой система-1 не дожидается ответа от системы-2. В данном случае ответ системе-1 может быть либо совсем не нужен. Например, если речь идёт о логировании действий, либо о ситуациях, когда получение ответа не влияет на дальнейшее выполнение функций системы. - Вот это вообще тяжело читается.
Возможный вариант:
Асинхронная интеграция, это такая интеграция, при которой Клиент может не дожидаться ответа от Сервера. Бывают случаи когда ответ клиенту либо совсем не нужен (например, если речь идёт о логировании действий), либо получение ответа не влияет на дальнейшее выполнение функций системы. Все равно, даже с такой формулировкой, не понятно к чему это написано.

Возможно, в погоне за уникальностью контента, пострадало качество. Не могу знать.
Но, если стояла задача объяснить сложные вещи простыми словами, то есть помочь начинающим системным аналитикам разобраться в вопросе, то лучшим решением было бы использовать известные формулировки и не выдумывать велосипед.

Например, вот, что пишет ChatGPT:Синхронное взаимодействие - это процесс взаимодействия между двумя или более объектами или системами, в котором один объект ждет завершения выполнения задачи другим объектом до продолжения своей работы. В этом случае каждый объект работает в синхронизированном режиме и соответствует временным ограничениям, установленным другими объектами.
Асинхронное взаимодействие - это процесс обмена информацией между двумя или более участниками, при котором каждый из них работает в своем собственном темпе, без ожидания ответа от другого участника. В таком взаимодействии используются различные методы и протоколы, которые позволяют участникам передавать данные независимо от времени и скорости работы друг друга. Такой подход обеспечивает более эффективное и гибкое взаимодействие между участниками, что особенно важно в сложных распределенных системах.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий