Удилим внимание больше интеграционной архитектуре, так как для архитектра это наиболее ответственный
слой. Ответсвенность архитектора в этом слое максимальная, так за наполнение самих модулей отвечают
разработчики, за строки – их TeamLead, за востребованность – ProducOwner, за их работоспособность -
техническая поддержка, а вот за техническое взаимодействие – архитекторы. В этом слое связи могут
быть представлены как в гарфическом виде (в стрелок на схемах между системами),
так и табличном – в виде описания поставщика, потребителя и контракта (обязательства поставщика перед
исполнителем). Первый вид более наглядный на общей схеме, а второй позволяет дать более дательные
характеристики внутри.
В графическом виде связи, зависимости от того, находятся они внутри или с наружи подразделяют на
внутренние и внешние. При этом внутрении связи при более детальном масштабе становятся
внешними. Стрелки могут быть оформлены с разной степенью детализации: как интеграции
с интеграционными системами и как информационные потоки между функциональными системами. В первом
случае они описывают возможность самой системы к интеграции так таковой, во втором – функциональную возможность
работы нескольких систем вместе, при котором сервисные модули не указываются. Представлении
стрелки указываеют в направлении от поставщика к потребителю, что соответствует
направлению информационного потока. Сам информационный поток включает передачу в процессах, поток
управления, передачу данных, репликации и другое.
В текстовом виде связи описывают не только само взаимодействие, направление, какие-то основные
параметры, по типу протокола, а детальные парамтеры. Обычно, описываются детальные парамтеры поставщика,
а необходимы параметры потребителю решаются на при согласовании. Парамтеры, которые обязуется предоставлять
поставщик называются контрактом. Контракт может создавать с учётом требований
потребитебя (для интеграционного потока между функциональными системами), а может быть в виде оферты
(интеграции с интеграционными серви). В зависимости от, являются параметры функциональными или
нефункционльными, они будет описываться или API, или SLA.
Контракт на всю систему описываются более общими характеристиками, общим из которых является
уровень критичности во ремени и в рамках ущерба. Критичность данных категоризируют по
анонимности (данные пластиковых карт, банковская тайна, персональные данные и другие данные, не
подлежащие распространению) и данные изменению (номера счётов, величины денежных средств и другие данные,
чувствительные к изменениям).
Сама система интеграция может быть с осуществелена различным образом, таким как:
* прямая интеграция (связь по API точка-точка, приемущества: минимум накладных расходов, недостатки: требуется двухсторонная доработка систем, сложность управления изменениями, сложность масштабирования, нет переиспользования);
* использованием шлюзов (связь через API интеграционого слоя, такого как очередь с файрволл, достоинства:
минимум накладных расходов, унифицированное API, недостатки: сложность управления изменениями, сложность
масштабирования, нет переиспользования);
* корпоративных шин данных или корпоративная сервисная шина (ESB, Enterprise Service Bus) предоставляет ассинхронную зонтичную
интеграция на объединениии принципов событийного и сервисного подходов (SOA, service-oriented architecture). Корпоративная
шина данных умеет гибко маршрутизировать сообщения от одних сервисов к другим. (достоинтсва:
унификация, переиспользвоание за счёт SOA, заменяемость сервисов за счёт SOA, недостатки: дорогое во
многих оношениях решение, время доставки от десятков милисекунд);
* Service Mesh, как и ESB, является зонтичной, но приложениям не нужно с ней интегрироваться, так как приложения
запущенные в контейнеризированной среде сразу получают интеграцию. (микросервисы, достоиство: минимум накладных расходов, не
заметно для разработчиков приложений);
* интеграционные файловые шлюзы и файловая передача точка-точка (перегрузка файлов). Файловая передача точка-точка, это
таже передача точка-точка, но позволяет передавать большие даные в обмен
за скорость передачи (достоинство: возможно передача очень больших объёмов данных, высокая гарантия
доставки, слабая связанность интегрируемых систем, больший контроль, широковещательный режим, недостатки: скорость передачи,
возможность рассинхронизации, большие требования к безопасности). Для взаимодействия используются протоколы доступа CIFS (Common
Internet File System), NFS (Network File System расширяет локльную файловую систему) и S3 (Simple Storage Service предоставляет доступ к объектному хранилищу, такому как Minio и Ceph) и протоколы предачи HTTPS (HTTP + SSL), SFTP (SSH + SSL) и
FTPS (FTP + SSL). С точки зрениния записи можно разелить на блочные (диск) и объектное (запись в key-value
базу данных: Bucket).
Общаться системы могут различными сопособами:
* интеграционный запрос (обычный синхронный запрос-ответ),
* удалённый вызов процедуры (RPC),
* отправлка команды в очередь (от поставщику к потребителю напрямую через очередь событий),
* публикация-подписка, Push-Sub (отравка событий в общую очередь, из которой заранее неопределённые отавителем системы извлекают группы событий),
* пакетная передача данных,
* передача файлов в хранилище,
* потоковая передача данных.
Сами взаимодействия должны быть описаны, и желательно унифицированы. Для описания функциональных или нефункционльных параметров (время ответа, доступность, размер сообщения, полоса пропускания) взаимодействий между поставщиком и потребителем используется Контракт, который обязуется выполнять поставщик. Функциональные параметры описываются с помощью Application Programming Interface (API). API сервиса могут быть разделены на группы, по формату сообщения (DTO, JSON, XML, бинарный) или протоколу (HTTP, REST, SOAP). В представлении разработчкиков API рисуется как список путей (URL) и описание полей в HTTP запросах, но это очень узкое представление, так API может быть реализовано не только как сетевые синхронные протоколы (HTTP, TCP, UDP), но и как сетевые ассинхронные протоколы (MQ, Apache Kafka Protocol), файловые форматы (пути к папкам и формат данных). В контракте API важно указать: ID, название, версия, назначение, шаблон, спецификация входных и выходных параметров. Сам API содрежат методы (побуждения к действию потребителя на приём данных, изменение, уделение и т.п.). Передоваемы в методе параметры описываются спецификацией по методу, например, с помощью OpenAPI или Swagger. Для многих языков, и в первую очередь для языка Java, по можно сгенерировать автоматически спецификацию на OpenAPI используя Swagger по Javadoc аннотациям (по специальным комментаримям) в коде. Спецификация будет отображаться как в текстовом форматах (JSON и YAML), так и в графическом. Для удобства проектирования можно воспользоваться Swagger Editor (https://swagger.io/tools/swagger-editor/). Это помогает оргинизовать автоматическое контрактное тестирование, представляя в графическом виде и сообщая ошибки в структуре. В общем наличие спецификации помогает организовать API-first разработку, когда сперва пишется спецификация API, а уже под неё разрабатывается код приложения, реализиуюй его. Например, нам нужно разработать API работы с объектом, для чего OpenAPI предоставляет разделы: