Гибрид на практике: Как мы подняли API-шлюз на Linux для древней AIX-системы биллинга

Представьте дракона, который хранит золото: он могуч, мудр, но разговаривает на языке, который уже никто не понимает. Именно таким драконом была старая биллинговая система на AIX в одном крупном телекоме. А мы должны были научить её общаться со всем миром через REST API. Вот как мы строили мост между эпохами.

Старая система на AIX была подобна мощному, но замкнутому в себе дракону.

Легенда о драконе, или Почему всё затеяли

Система биллинга была монолитом на IBM AIX с базой данных Oracle. Она обрабатывала миллионы транзакций ежедневно. Её надежность была безупречной — 99.99% uptime за 15 лет. Но у неё был фундаментальный изъян: общалась она только через древний протокол IBM MQ и пачку самописных сокетов.

Когда бизнес захотел запустить мобильное приложение, личный кабинет и интеграцию с партнёрами через API, оказалось, что:

1. Разработчики боялись подходить к системе, написанной на PL/I и COBOL.
2. Любой новый запрос к биллингу требовал месяцев согласований и разработки на стороне AIX.
3. Безопасность была построена на принципе «ну её в отдельный сегмент сети».

Нужен был выход. И он лежал в создании современного API-фасада на Linux, который стал бы переводчиком между REST-запросами из внешнего мира и MQL-сообщениями в сердце дракона.

Архитектурная схема: Строим мост через пропасть

Вот как выглядела итоговая архитектура решения:

Ключевые компоненты моста:

1. API-шлюз Kong на Linux-кластере: Выступил единой точкой входа. Он занимался маршрутизацией, ограничением скорости (rate limiting) и базовой аутентификацией.
2. Адаптер-переводчик (Python/Java): Самая важная часть. Этот сервис трансформировал JSON из REST-запроса в строгий XML-формат, понятный AIX-системе, и помещал его в очередь IBM MQ.
3. IBM MQ Queue Manager: Мост в буквальном смысле. Очередь сообщений, развернутая непосредственно на AIX-сервере, стала буфером и точкой гарантированной доставки.
4. Служба-обработчик на стороне AIX: Небольшая, но жизненно важная программа на C, которая слушала очередь MQ, забирала XML, вызывала нужную функцию биллинга через внутренний API и возвращала результат обратно в очередь.

Мост между эпохами: современный Linux-кластер и надежные системы на AIX.

Проклятие дракона: С какими проблемами столкнулись

1. Синхронность vs Асинхронность. Биллинг на AIX работал в пакетном режиме. Запрос «узнай баланс» мог выполняться 2 секунды, а «рассчитай сложный тариф» — 20 секунд. Решение: Мы реализовали схему с двумя типами ответов. Для простых запросов — синхронное ожидание (до 5 сек). Для сложных — немедленный ответ «принято в обработку» с выдачей номера запроса, по которому результат можно было получить позже.
2. Безопасность и «доверие». AIX-система не доверяла никому. Пришлось внедрять двухуровневую аутентификацию. Kong проверял API-ключ, а адаптер на стороне Linux добавлял к сообщению для AIX цифровую подпись на основе общего секретного ключа, хранимого в аппаратном Security Module.
3. Мониторинг и логирование. Как понять, где сбой — в Linux-слое или уже в AIX? Мы развернули единый ELK-стек (Elasticsearch, Logstash, Kibana) на Linux, куда стекались логи со всех компонентов. Ключевой метрикой стала скорость прохождения сообщения через очередь MQ.

Магия, которая сработала: Ключи к успеху

• Минимальное вторжение в AIX. Мы не переписывали биллинг. Мы добавили лишь маленькую службу-слушателя MQ. Это успокоило и руководство, и команду сопровождения.
• Масштабирование на стороне Linux. Вся нагрузка от внешних пользователей ложилась на кластер Linux. Если требовалось обслужить больше запросов, мы просто добавляли инстансы адаптера или ноды Kong. Дракон оставался в своем неизменном состоянии.
• Отказоустойчивость. Очередь MQ гарантировала, что ни одно сообщение не потеряется. Если адаптер на Linux падал, сообщения накапливались в очереди и обрабатывались, когда служба восстанавливалась.

Результат: Дракон заговорил на языке REST

Через четыре месяца после старта проекта:

1. Мобильное приложение запрашивало баланс и детализацию звонков через /api/v1/balance/{phone}.
2. Веб-портал отправлял платежи через POST на /api/v1/payment.
3. Партнеры могли проверять статус услуг через стандартные REST-вызовы.
4. Команда сопровождения AIX спала спокойно — их система работала в прежнем режиме, только вместо одного монолитного коннекта у неё появился один универсальный вход из MQ.
5. Разработчики фронтенда перестали бояться биллинга и работали с ним, как с любым другим современным API.

Философский итог: Этот проект стал идеальным воплощением принципа Инь-Ян. AIX (Ян) остался непоколебимым центром, хранителем данных и бизнес-логики. Linux (Инь) стал гибкой, масштабируемой оболочкой, которая адаптировала этот центр к быстро меняющемуся миру. Мы не ломали старое. Мы аккуратно надели на него новый интерфейс. И заставили дракона не просто говорить, а петь на языке современной цифровой экономики.