Введение в интеграции информационных систем · Татьяна Сальникова #системныйаналитик

• Татьяна Сальникова рассказывает о своём опыте в бизнес-системном анализе.  

• Основные сферы работы: ритейл, строительство и финансовые технологии.  

• Упоминает о своём телеграм-канале, где можно найти статьи и тексты.  

• Вебинар будет в лекционном формате с возможностью задавать вопросы в перерывах.  

• Татьяна просит участников поднимать руки и задавать вопросы голосом.  

• Интеграция — это автоматизированное взаимодействие между системами и сервисами.  

• Пример интеграции: приложение Delivery Club и «Самокат».  

• Delivery Club и «Самокат» обмениваются данными для реализации общего бизнес-процесса.  

• Пользователи могут заказывать продукты через Delivery Club, а доставку осуществляет «Самокат».  

• Аналитик задаёт вопросы о целях и ценности интеграции.  

• Определяет целевой бизнес-процесс и зоны ответственности систем.  

• Анализирует, какими данными системы должны обмениваться и при каких условиях.  

• Delivery Club получает список продуктов от «Самоката» и отправляет заказ.  

• «Самокат» выполняет заказ и отчитывается перед Delivery Club.  

• Обсуждаются условия обмена данными и функции, которые должны выполняться.  

• Обсуждение подхода к анализу данных: от общего к деталям или наоборот.  

• Объяснение эффекта повышения продаж: увеличение охвата пользователей и лояльности.  

• Интеграцией занимаются аналитики обеих систем.  

• Команды из обеих систем плотно взаимодействуют на промежуточном этапе.  

• Каждый аналитик отвечает за свой функционал в своей системе.  

• Обсуждение целевого бизнес-процесса: увеличение продаж или получение аудитории.  

• Для «Самоката» увеличение продаж достигается через увеличение аудитории.  

• У «Деливери Клаб» увеличение аудитории происходит косвенно через расширение линейки продуктов.  

• Системы «Деливери Клаб» и «Самокат» написаны на разных языках программирования.  

• Для взаимодействия систем необходимы протоколы и форматы данных.  

• Протоколы определяют формат и порядок взаимодействия систем.  

• Примеры протоколов: HTTP, SOAP, FTP.  

• Форматы данных определяют конкретную форму представления данных.  

• Обе системы должны выбрать общий протокол для интеграции.  

• Выбор протокола зависит от целей интеграции и возможностей разработчиков.  

• Внешние интеграции часто используют популярные протоколы, такие как JSON.  

• Четыре общих способа интеграции: удалённый вызов процедуры, REST, GraphQL, GPS.  

• Удалённый вызов процедуры: клиент делает запрос к серверу, сервер выполняет код и возвращает ответ.  

• Пример интеграции: «Деливери Клаб» отправляет адрес клиента, «Самокат» ищет доступные продукты и возвращает список.  

• Аналитик определяет формат передачи данных, который обе системы могут обработать.  

• Если в ответе больше атрибутов, чем нужно, система обрабатывает только необходимые.  

• В JSON добавление новых полей не влияет на обработку данных другой системой.  

• В Excel добавление нового поля может потребовать доработки системы.  

• Переход к обсуждению вида запроса.  

• Аналитики работают с двумя форматами: строкой запроса и данными в запросе и ответе.  

• В запросе используются глаголы: GET, POST, PUT, DELETE, PATCH.  

• Глагол GET обозначает получение данных.  

• После глагола указывается адрес интерфейса системы.  

• На веб-сервере распределяются ресурсы и сущности для запросов.  

• Пример запроса: получение информации по продуктам с параметрами.  

• Параметры запроса идут после знака вопроса.  

• В POST-запросах и PUT-запросах параметры передаются в теле запроса.  

• В ответе должен быть перечень продуктов и код ответа.  

• Формат данных может быть JSON.  

• Обмен сообщениями — популярный метод интеграции.  

• Системы общаются через очереди сообщений, сравнимые с трубами.  

• Примеры инструментов: Kafka, RabbitMQ.  

• Синхронный обмен: клиент блокируется до получения ответа.  

• Асинхронный обмен: клиент отправляет запрос и продолжает работу, ответ приходит позже.  

• При синхронном обмене системы должны быть постоянно доступны.  

• Асинхронный обмен позволяет системам не быть постоянно онлайн.  

• Брокеры очередей частично берут на себя заботу о доступности.  

• Протоколы работают поверх друг друга.  

• Аналитикам редко нужно глубоко погружаться в работу брокеров.  

• Возможно, потребуется знание форматов, например, AvroSchema в Kafka.  

• Передача файла — простой и олдскульный способ интеграции.  

• Пример: самокат передаёт файл с адресами и продуктами на файловый сервер, а Delivery Club использует этот файл для работы.  

• Проблема: непредсказуемое изменение данных, необходимость определения актуальности версии файла.  

• Delivery Club может не хотеть хранить весь файл из-за безопасности или других причин.  

• Подходит для периодической отправки отчётов, например, раз в месяц.  

• Требуется настройка файлового сервера и решение вопросов безопасности.  

• Склад может передавать информацию о товарах на файловый сервер.  

• Магазин должен получать уведомления о новых товарах.  

• Частое обращение к файловому серверу может быть невыгодным из-за затрат ресурсов.  

• Передача данных с оповещением предпочтительнее передачи файла.  

• Возможные альтернативы: очереди, обмен сообщениями, общая база данных.  

• Общая база данных — устаревший, но всё ещё полезный способ интеграции.  

• Удобен для систем внутри одной компании, работающих с одним набором данных.  

• Для оповещения о новых данных требуется дополнительная интеграция.  

• Триггеры могут оповещать смежные системы о новых данных.  

• Не везде используются триггеры, но они могут быть полезны.  

• Аналитикам не стоит беспокоиться о выборе способа интеграции, этим занимаются техлиды и архитекторы.  

• Важно учитывать скорость ответа клиента и время формирования ответа сервером.  

• Синхронные способы интеграции предпочтительнее для быстрых ответов, а асинхронные — для систем с низкой доступностью.  

• Объём данных, который может передать система, ограничен.  

• Большое количество запросов может привести к сбоям системы.  

• Важно учитывать частоту передачи данных.  

• Безопасность является важным фактором при интеграции систем.  

• Некоторые способы интеграции менее безопасны, чем другие.  

• Необходимо учитывать навыки разработчиков и скорость выполнения задач.  

• В разных компаниях аналитики выполняют разные задачи в интеграции.  

• Топ вопросов на интервью: знание видов интеграции, REST, SOAP.  

• Аналитики могут описывать спецификации и параметры очередей.  

• Синхронное взаимодействие используется, когда нужен немедленный ответ.  

• Асинхронное взаимодействие предпочтительнее при частых сбоях систем.  

• Пример синхронного взаимодействия: публикация прогноза погоды.  

• Веб-системы часто используют синхронное взаимодействие.  

• Запросы на госуслугах могут быть асинхронными, например, запрос электронной выписки из трудовой книжки.  

• Микросервисная архитектура предполагает использование очередей для синхронного взаимодействия внутри компании.  

• Микросервисы — это небольшие сервисы со сложным функционалом, интегрированные через очереди сообщений.  

• Увеличение количества сервисов снижает доступность системы.  

• Рекомендуется использовать общий брокер для распределения сообщений между сервисами.  

• Достоинство: хорошая масштабируемость, возможность добавления новых сервисов без переделки большого монолита.  

• Недостатки: сильная связь сервисов через интеграции, риск возникновения «распределённого монолита».  

• Важность правильного распределения сервисов для обеспечения гибкости системы.  

• Микросервисы подходят, когда есть заказчик и задача по интеграциям.  

• Решение о выборе архитектуры должно учитывать перспективы развития системы и возможности команды.  

• Необходимо учитывать множество деталей: язык программирования, способ работы с системой, способы развёртывания.  

• Благодарность участникам за внимание.  

• Анонс записи встречи и статьи.  

• Прощание.