Любое ведомство приходит к интеграции одинаково. Сначала появляются две системы, которые надо связать, – пишется прямой коннектор. Потом систем становится пять, потом двенадцать, и связей между ними уже под сотню. Каждая новая система тянет за собой десяток новых интерфейсов, а смена формата в одной ломает половину остальных. Этот момент – развилка: продолжать плодить точечные связи или строить шину данных. Разберём, когда какой путь оправдан.
Точечные коннекторы: дёшево на старте, дорого на десятой системе
Точечная интеграция (point-to-point) – это прямое соединение двух систем по согласованному формату. Её сила в простоте: связали два узла, проверили, забыли. Для двух-трёх систем это правильное решение, и платить за шину тут не за что.
Проблема в арифметике. Количество потенциальных связей растёт как N×(N−1)/2. Для пяти систем – до десяти интерфейсов, для десяти – до сорока пяти. На практике до полного графа не доходит, но рост всё равно нелинейный. Каждый интерфейс – это свой формат, своя обработка ошибок, свой журнал, своя точка отказа. Когда поставщик одной системы меняет версию API, вы правите не один коннектор, а все, что в неё упираются. Сопровождение такой паутины съедает бюджет быстрее, чем сама разработка.
И ещё одно: точечные связи плохо документируются. Через два года никто в ведомстве не помнит, какая система кому что шлёт. Это прямой риск при аттестации и при разборе инцидентов.
Шина данных: централизация форматов и контроля
Сервисная шина (ESB) разрывает прямые связи. Каждая система подключается к шине один раз, а шина берёт на себя маршрутизацию, преобразование форматов, гарантированную доставку и журналирование. Добавляете новую систему – описываете один адаптер к шине, а не связи со всеми остальными.
Шина окупается там, где систем много, форматы разнородны, а требования к надёжности высоки. Госсектор – типичный случай: реестры, бухгалтерия, документооборот, ведомственные АИС и внешние каналы вроде межведомственного электронного взаимодействия через СМЭВ. Шина даёт единую точку, где видно все потоки, где централизованно настраиваются права и где удобно снимать метрики.
Есть и инфраструктурный плюс. Шину логично разворачивать как набор сервисов в частном облаке на базе виртуализации – это упрощает масштабирование узлов маршрутизации и резервирование без покупки нового железа под каждый всплеск нагрузки.
Безопасность: единый периметр вместо россыпи дыр
Когда интеграция растёт стихийно, каждый коннектор несёт собственную аутентификацию, свои ключи и свои сертификаты. Уследить за этим зоопарком невозможно, а цена ошибки высока: история с компрометацией удостоверяющего центра DigiNotar показала, что один скомпрометированный элемент доверия рушит всю цепочку.
Шина централизует криптографию и контроль доступа. Сертификаты, шифрование каналов, подпись сообщений и проверка прав живут в одном месте, под единым регламентом. Это резко упрощает аттестацию по требованиям к защите информации и убирает целый класс «забытых» незащищённых стыков.
Что выбрать
Правило простое. До трёх-четырёх систем со стабильными форматами – точечные коннекторы, не усложняйте. Десяток и больше разнородных систем, жёсткие требования к надёжности и безопасности, перспектива роста – шина данных. Чаще всего разумен гибрид: шина как ядро для критичных потоков и пара прямых связей там, где они оправданы.
Главное – выбрать архитектуру осознанно, а не получить паутину связей по факту. Оба подхода имеет смысл закладывать под конкретную нагрузку ведомства – от аудита текущих интерфейсов до проектирования и внедрения шины данных.
