Архитектура
Архитектурные уровни и границы ответственности MTB ESB Next Gen.
Архитектура платформы
MTB ESB Next Gen построена как набор специализированных компонентов. Каждый уровень решает ограниченный класс задач и может развиваться независимо в рамках согласованных контрактов.
Контекст платформы
Архитектурные уровни
1. Consumer channel
Внешняя граница платформы. Здесь потребитель находит API, регистрирует приложение, получает разрешённые credentials и вызывает стабильный HTTPS endpoint.
Основные элементы: Developer Portal, приложения, подписки, API Products и пользовательская документация.
2. API management
WSO2 API Manager принимает запрос и применяет платформенные правила:
- проверяет токен и права доступа;
- определяет канонический Consumer ID;
- применяет scopes, throttling и security policies;
- обеспечивает наличие request ID и trace context;
- передаёт запрос в согласованный backend flow.
Архитектурная граница
WSO2 не предназначен для реализации сложных многошаговых бизнес-процессов. Gateway должен оставаться предсказуемым и сфокусированным на управлении API-трафиком.
3. Transport and routing
Event Router и Kafka отделяют входной API-вызов от конкретного обработчика. Router выбирает маршрут по утверждённым правилам, а Kafka обеспечивает транспорт между компонентами.
Контракт маршрута включает topic, message key, формат envelope, correlation, timeout, retry и DLQ-поведение.
4. Orchestration
Kestra используется, когда результат требует последовательности или координации нескольких операций. Flow описывает шаги, зависимости, обработку ошибок и при необходимости компенсацию.
5. System integration
Адаптер преобразует канонический платформенный контракт в протокол и модель целевой системы. Изменения legacy-интерфейса локализуются в соответствующем адаптере.
6. Operations
Логи, метрики и distributed tracing проходят через все уровни. Операционная модель должна позволять найти запрос по X-External-Request-ID или traceparent и определить компонент, в котором остановилась обработка.
Сквозные аспекты
| Аспект | Как реализуется |
|---|---|
| Security | AuthN/AuthZ в Gateway, scopes, policies, secrets и TLS |
| Traceability | X-External-Request-ID, traceparent, структурированные логи |
| Idempotency | Idempotency-Key в scope конкретного consumer |
| Governance | API lifecycle, naming, каталоги, review и approval gates |
| Reliability | Timeout, retry, DLQ, callback и восстановление |
| Delivery | Версионируемые артефакты и контролируемое продвижение по окружениям |
Главные архитектурные правила
- Потребители используют только опубликованные endpoints платформы.
- API-контракт не должен раскрывать внутреннюю топологию Kafka или адрес целевой системы.
- Один идентификатор не используется одновременно для tracing, consumer identity и идемпотентности.
- Синхронный интерфейс не означает, что весь внутренний маршрут обязан быть синхронным.
- Stage и Prod являются отдельными контурами и не разделяют runtime-конфигурацию.
- Любой новый маршрут получает владельца, контракт и наблюдаемость до выхода в эксплуатацию.