Потребитель VS поставщик информации: принципы построения интеграционного взаимодействия
Всем привет!
Сегодня я расскажу про роли поставщика и потребителя в контексте информационных систем. Под поставщиками я подразумеваю информационные системы, которые передают информацию, а под потребителями — которые ее получают. Также расскажу об основных правилах игры, которые мы выработали у себя в команде.
Зачем нужны правила? Представьте, если бы светофоры в разных городах имели бы разную цветовую гамму. К сожалению, похожий бардак иногда встречается в различных областях нашей жизни, и сфера информационных технологий — не исключение!
Статья поможет структурировать информацию тем, кто проектирует информационные системы и взаимосвязи между ними.
Начну с того, что меня зовут Сергей, и я кандидат технических наук и руководитель команды разработки в НЛМК-ИТ. Одной из крупных информационных систем, которую мы разрабатывали, поддерживаем и развиваем является Единый корпоративный портал (далее портал). Кстати, о нем я немного рассказывал в прошлой статье «Как мы допиливали Битрикс и защищали его от хищных роботов».
Когда мы в 2017 году начинали разрабатывать портал, нам нужно было получать информацию для различных сервисов, например, вывод расчетного листка, информации о месте работе сотрудника, о днях рождения и т.д. Таким образом, мы являлись потребителем информации.
Интеграционные взаимодействия, как правило, строились на базе REST-архитектуры с использованием curl или своих обработчиков на базе протокола https. Это был осознанный выбор, базировался он на следующих принципах:
Относительно невысокий порог вхождения в архитектуру REST и написание «простых» http (s) запросов. На рынке уже есть множество различных решений:
стандартные библиотеки и функционал PHP (curl, http-запросы);
библиотеки с подробными мануалами по использованию (Guzzle, Slim и т. д.).
Гибкость — под каждую интеграцию можно написать свою реализацию. Например, обмен с помощью XML, json и других объектов.
Необходимость научить новую систему сначала «играть по текущим правилам», прежде чем их менять или диктовать свои. Портал только создавался и выступал в качестве потребителя, а ряд систем с мастер-данными существовали уже давно со своими устоявшимися процессами и правилами.
В какой-то момент времени, реализовав множество различных сервисов и обогатившись собственной уникальной информацией, мы стали предоставлять ее другим информационным системам, т.е. стали поставщиками информации.
Давайте более детально рассмотрим историю выработки правил, которые мы закладывали при выборе технологии для построения интеграционных взаимодействий.
Потребитель VS поставщик
Потребитель
Как и писал выше, в начале своего пути портал являлся потребителем информации, и для реализации сервисов необходимо было получение дополнительной информации. В частности, необходимо было получать данные по оргстуруктуре, кадровой информации, телефонному справочнику, расчетному листу и т.д. У каждой системы поставщика были свои интерфейсы/методы/протоколы передачи данных.
В итоге, у нас получился небольшой «зоопарк» интеграционных технологий, но, к сожалению, от него не уйти, т.к. «диктовать свои условия» и ломать уже существующие работающие системы мы не можем. Возможно, многие скажут, что можно сделать какой-либо промежуточный web api/api gateway сервер, который будет приводить информацию к единому виду, но это только внесет дополнительную точку отказа/обслуживания/поддержки и никак не исправят мастер-систему (поставщика).
Потребитель знает:
какая информация ему необходима и для чего;
поставщика, с которым он будет работать;
язык/способ общения с поставщиком.
Со временем появилась задача тиражировать информацию с портала на другие информационные системы (т.е. стать поставщиком), и появился вопрос: «Можем ли мы использовать такие же правила и знания при смене роли потребитель→ поставщик?».
При поиске ответов на этот вопрос мы все больше и больше приходили к мнению, что нет, не можем, т.к. заводить еще один «зоопарк» и поддерживать и развивать множество спецификаций трудоемко и нецелесообразно.
Поставщик
Для выработки какой-либо спецификации взаимодействия с другими ИС мы начали с определения/набора знаний поставщика. К сожалению, оказалось, что поставщик не обладает практически никакими знаниями о потребителе, и логичнее отталкиваться от его незнаний.
Поставщик не знает:
количество возможных потребителей, особенно, если информационные технологии/системы постоянно развиваются;
платформу и технологический стек потребителя;
какая информация, ее состав (поля) и для чего она нужна потребителю.
Далее мы стали разрабатывать правила и обязанности поставщика. Не буду рассказывать детали мозгового штурма при проработке данного вопроса, а сразу перейду к сформулированным концептуальным правилам.
«Правила игры» поставщика
Поставщик должен:
быть единообразным. Работать одинаково для всех потребителей без исключения. Такое единообразие позволяет легче интегрировать систему с другими приложениями, снижает сложность поддержки и помогает дальнейшему развитию.
работать по принципу One step, т.е. система должна предоставлять информацию в максимально полном и связанном виде, чтобы потребителям было достаточно одного запроса для получения всех необходимых данных.
Давайте более детально разберем что понимается под принципом One step.
Step by step VS One step
Объекты предоставляемой информации имеют связность с другими объектами. Например, у каждой новости есть рубрика, комментарии, просмотры и авторы и т.д.
Информацию можно получать двумя способами:
Step-by-step — шаг за шагом, т. е. формируя несколько запросов, из которых складывается общая картина. Например, получить новость → рубрики→ просмотры→ комментарии и т. д.
One-step — за один шаг, т. е. формируя один запрос. Например, получить новость сразу со всеми связанными элементами.
Как мы видим из рисунка выше, множество накладных ресурсов по технологии step-by-step требуется на «прогревание» канала. Следовательно, технология one-step выигрывает в производительности по времени получения ответа.
Мы сравнили эти технологии по критериям ниже.
Step by step | One step | |
Производительность | низкая множество накладных расходов (сеть/транспорт, анализ запросов, формирование ответов и т.д.) | высокая |
Система управления знаниями | сложная множество методов под каждый объект и их кросc-функциональное взаимодействие | простая единый формат запроса/ответа |
Порог вхождения | относительно невысокий порог вхождения в архитектуру REST и написания «простых» http (s)-запросов | более высокий порог вхождения требуется знать специфику работы умного endpoint«a |
Вероятность возникновения ошибок | высокая | низкая вероятность возникновения ошибок при обработке |
Сложность интеграции новых систем | средняя | простая нет необходимости разрабатывать сложные механизмы для |
Как видно из таблицы выше, технология one step является более предпочтительной за исключением порога вхождения, но этот пункт будет практически «сходить на нет» после первичного погружения сотрудников.
В целом, принцип One step способствует созданию более удобных, эффективных и производительных информационных систем, способных обеспечить надежное и своевременное предоставление информации различным потребителям.
Выводы
В ходе трансформации нашей информационной системы из роли потребителя в роль поставщика мы выработали основные правила и принципы для обеспечения эффективного взаимодействия между различными системами. Основа этих правил состоит в единообразии и использовании принципа one step для предоставления максимально полной и связанной информации сразу в одном запросе. Стоит учитывать, что есть кейсы, где технология one step не всегда будет выглядеть предпочтительной, и это зависит от различных параметров, например, оставшийся срок жизни ИС, количество требуемых интерфейсов и т.д.
Подводя итоги, можно сделать следующие рекомендации:
При проектировании каких-либо интеграционных взаимодействий определите назначение системы в разрезе поставщик/потребитель.
Если вы являетесь поставщиком информации, то:
определите технологию отдачи информации — one step или step by step;
отдавайте собственную информацию. Собственная информация — данные, которые сгенерированы в самой системе. При этом неважно, как они в нее попали;
cтарайтесь отдавать «сырую» информацию, т.е. забирать ее прямо из источника, не модифицируя. Все изменения должны производиться потребителем на его стороне, потому что поставщик не может знать для каких целей и как потребитель будет использовать наши данные.
Если вы являетесь потребителем информации, то здесь, как правило, приходится использовать уже существующие методы интеграции.
Спасибо за внимание!
