Как обещал, продолжение статьи, теперь уже прошлого года — habr.com/ru/post/474052
Итак, мы начали с общего обзора проблематики. Теперь, как обещано ранее – единая корзина, с неавиационному услугами. Начнем с архитектуры и далее, к основному процессу. И про структуру услуг и почему мне не нравится MongoDB, и почему мы пока её используем.
В описании решения я отошёл от архитектуры на обоих внедрениях и описываю ту архитектуру, которая у нас крайняя в ветке развития продукта.
Состав:
Web сервер, и он же балансировщик. Классический – Nginх, Vue.JS, PHP.
Сервер интеграции. Сервер приложений, с воркерами, обрабатывающими запросы к поставщикам услуг. Тут же расположен шлюз, предоставляющий сторонним front системам API.JSON, архитектурный стиль REST. И тут же живет модуль – Блоки.
Технологии:
• Vue.JS;
• PHP (Laravel), backend реализующий основную бизнес логику;
• Менеджер процессов FastCGI + Supervisor;
• Тут же интеграция с RabbitMQ (к оперативной базе и сервису информирования). BPMS процессов не используем, пока все процессы захардкорены, поэтому из шины только MQ;
• Характерная черта решения, это сразу две интеграции к ресурсным системам. Одна напрямую в API, для продаж. Вторая, через MQ и оперативную базу, для снижения нагрузки на основное подключение.
Сервер административных АРМов
Технологии:
• PHP (Laravel), управление агентскими сетями, поставщиками и работой с заказами. Как и выше, все процессы захардкорены, BPMS не использовали;
• Менеджер процессов FastCGI + Supervisor.
Файловый сервер. Тут живут — логи и документы, выпущенные поставщиками услуг. Хранить маршрут-квитанции нет смысла и мы их генерируем каждый раз, при запросе.
Технологии:
• PHP (Laravel), это наш backend инструмент;
• Менеджер процессов FastCGI + Supervisor;
• Nginx, пожелаем ему отбиться от отечественных рейдеров;
• Кластерная файловая система GlusterFS для статических файлов. Да, много файлов, в первую очередь PDF документов.
Сервер СУБД.
Технологии:
• MongoDB, БД услуг. Вот от чего мне хочется избавиться (но об этом подробнее ниже);
• PostgreSQL, БД административная. Для административных АРМов (валюты, с курсами IATA; настройки партнеров; пользователи; возвраты / обмены and etc);
• PostgreSQL, БД системы бронирования из блоков (расписание; блоки; рейсы; загрузка мест; тарифы; тарифные группы и классы обслуживания);
• Gearman — сервер очередей;
• REDIS — сервис кэширования данных, в первую очередь кэширование предложений, подгруженных из партнёрских систем. Например, при входе в корзину, мы формируем пул предложений от партнеров, и переходя в новые разделы корзины, подгружаем предложения из Redis, а не запрашиваем предложения от тематических партнеров. Цель — увеличение скорости работы корзины;
• PHP (Laravel). Как обычно — backend бизнес-процессов и как обычно, пока все процессы захардкорены.
Cервер оперативной базы.
Вот об этом немного подробнее, т.к. оперативная база — это особенность отрасли. Схемы про то, как данный архитектурный элемент участвует в основных процессах, даны далее (напомню, реализовано все сложнее, многие детали опущены, для упрощения понимания).
Общее назначение модуля — накапливание и актуализация информации о возможных предложениях клиентам, с целью формирования таковых (т.е. предложений по услугам) клиентам в процессах, в которых снижены требования к актуальности предложения, например — докупка услуг. Если, при прямой покупке, с e-commerce портала, важно обеспечить максимально актуальное предложение, то запрашиваем варианты напрямую в API поставщика. А если такой потребности нет, например при докупке услуг, вначале формируется рекламное предложение, которое вполне можно тянуть из промежуточной базы, снижая загрузку на основной интеграционный канал, что и делаем.
Технологии:
• MongoDB, БД услуг;
• Gearman — сервер очередей;
• PHP (Laravel).
Схема намеренно упрощенная, для общего понимания. Убраны большинство интеграционных потоков, и многое иное.
Прямые продажи, с сайта дистрибьютора.
1. Клиент выбрал предложение на сайте бронирования (поиск предложений из GDS — целая технология, но работа GDS, использование оперативной базы и пр., все это опустим, дабы не утонить в деталях);
2. GDS создает бронь;
3. GDS возвращает результаты;
4. Сайт бронирования перенаправил клиента в единую корзину (при продажах в стоке авиакомпании, есть другие варианты);
5. ЕК выполняет запрос в GDS на получение данных бронирования;
6. GDS возвращает параметры брони (внутренние процессы мы игнорируем);
7. ЕК формирует заказ;
8. ЕК выполняет запрос в системы поставщиков в асинхронном режиме, передавая данные бронирования;
9. Системы поставщиков формируют предложения;
10. ЕК получает данные по доступным предложениям услуг;
11. ESS передает сайту предложения по услугам;
12. Клиент выбирает услуги и переходит к оплате;
13. ЕК выполняет запросы в системы поставщиков в асинхронном режиме на бронирование услуг.
14. Система поставщика формирует брони;
15. Система поставщика возвращает брони в ЕК;
16. ЕК выполняет запросы в GDS на добавление услуг в раздел АЕ и записи SSR с номером заказа в PNR;
17. GDS обновляет раздел АЕ и добавляет запись SSR. На наше счастье, большие (увы это не про всех) GDS доросли до полноценного SOAP интерфейса и нам не нужны терминальные команды (эмуляция Green Screen);
18. GDS возвращает результат дозаписи PNR;
19. ЕК выполняет визуализацию корзины;
20. Клиент подтверждает заказ;
21. ЕК передает корзину на оплату;
22. Платежное решение выполняет оплату (тоже непростой процесс, но мы упростим, так как платежные процессы отдельная тема);
23. Платежное решение возвращает результат оплаты;
24. ЕК в асинхронном режиме выполняет запросы в системы поставщиков на подтверждения оплаты и получение документов поставщиков (ваучеров, полисов и пр.);
25. Система поставщика выпускает документы;
26. Система поставщика возвращает брони в ЕК;
27. ЕК выполняет запросы в GDS на выпуск документов (билеты, EMD);
28. GDS дописывает PNR;
29. GDS выпускает документы;
30. GDS меняет статусы PNR и услуг;
31. GDS возвращает результаты и документы;
32. ЕК дописывает документы в заказ;
33. ЕК выставляет статус — оплачено;
34. ЕК визуализирует результат клиенту;
35. ЕК выполняет запрос на информирование;
36. Модуль информирования, направляет email клиенту.
1. Агент вводит параметры перелета;
2. ЕК выполняет запрос в модуль Блоки;
3. Блок рассчитывает цену, исходя из текущего курса валют и добавляет сборы агентства, чей заказ, определяет доступность выполнения бронирования, исходя из финансовых квот;
4. Блоки возвращают предложения;
5. ЕК передает предложения в API, для визуализации агенту;
6. Агент подтвердил заказ;
7. ЕК запрашивает резервирование из блока мест;
8. Резервируются места на перелет;
9. Блоки возвращают бронь;
10. ЕК формирует заказ;
11. ЕК выполняет запрос в системы поставщиков в асинхронном режиме, передавая данные бронирования;
12. Системы поставщиков формируют предложения;
13. ЕК получает данные по доступным услугам;
14. ЕК запрашивает Блоки на доступность формирования заказа на выбранную сумму;
15. Блоки проверяют баланс и квоты;
16. Блоки возвращают результат;
17. ЕК передает предложения в API, для визуализации агенту;
18. Агент выбирает услуги и переходит к оплате;
19. ЕК выполняет запросы в системы поставщиков в асинхронном режиме на бронирование услуг;
20. Система поставщика формирует брони;
21. Система поставщика возвращает брони в ЕК;
22. ЕК передает корзину в API, для визуализации агенту;
23. Агент подтверждает заказ;
24. ЕК передает корзину на оплату;
25. Платежное решение выполняет оплату (то же непростой процесс, но мы упростим);
26. Платежное решение возвращает результат оплаты;
27. ЕК, в асинхронном режиме, выполняет запросы в системы поставщиков на подтверждения оплаты и получение документов поставщиков (ваучеров, полисов и пр.);
28. Система поставщика выпускает документы;
29. Система поставщика возвращает брони в ЕК;
30. ЕК выполняет запросы в GDS на выпуск документов (билеты, EMD);
31. GDS дописывает PNR;
32. GDS выпускает документы;
33. GDS меняет статусы PNR и услуг;
34. GDS возвращает результаты и документы;
35. ЕК дописывает документы в заказ;
36. ЕК выставляет статус оплачено;
37. ЕК передает в блоки статус и изменения брони;
38. Блоки дописывают бронь и выпускает маршрут-квитанцию;
39. Блоки возвращают результат;
40. ЕК передает результаты (документы, PNR, маршрут квитанцию), в API, для визуализации агенту;
41. ЕК выполняет запрос на информирование;
42. Модуль информирования, направляет email клиенту.
В продолжение, про MongoDB...
Итак, мы начали с общего обзора проблематики. Теперь, как обещано ранее – единая корзина, с неавиационному услугами. Начнем с архитектуры и далее, к основному процессу. И про структуру услуг и почему мне не нравится MongoDB, и почему мы пока её используем.
В описании решения я отошёл от архитектуры на обоих внедрениях и описываю ту архитектуру, которая у нас крайняя в ветке развития продукта.
Общая архитектура
Состав:
Web сервер, и он же балансировщик. Классический – Nginх, Vue.JS, PHP.
Сервер интеграции. Сервер приложений, с воркерами, обрабатывающими запросы к поставщикам услуг. Тут же расположен шлюз, предоставляющий сторонним front системам API.JSON, архитектурный стиль REST. И тут же живет модуль – Блоки.
Технологии:
• Vue.JS;
• PHP (Laravel), backend реализующий основную бизнес логику;
• Менеджер процессов FastCGI + Supervisor;
• Тут же интеграция с RabbitMQ (к оперативной базе и сервису информирования). BPMS процессов не используем, пока все процессы захардкорены, поэтому из шины только MQ;
• Характерная черта решения, это сразу две интеграции к ресурсным системам. Одна напрямую в API, для продаж. Вторая, через MQ и оперативную базу, для снижения нагрузки на основное подключение.
Сервер административных АРМов
Технологии:
• PHP (Laravel), управление агентскими сетями, поставщиками и работой с заказами. Как и выше, все процессы захардкорены, BPMS не использовали;
• Менеджер процессов FastCGI + Supervisor.
Файловый сервер. Тут живут — логи и документы, выпущенные поставщиками услуг. Хранить маршрут-квитанции нет смысла и мы их генерируем каждый раз, при запросе.
Технологии:
• PHP (Laravel), это наш backend инструмент;
• Менеджер процессов FastCGI + Supervisor;
• Nginx, пожелаем ему отбиться от отечественных рейдеров;
• Кластерная файловая система GlusterFS для статических файлов. Да, много файлов, в первую очередь PDF документов.
Сервер СУБД.
Технологии:
• MongoDB, БД услуг. Вот от чего мне хочется избавиться (но об этом подробнее ниже);
• PostgreSQL, БД административная. Для административных АРМов (валюты, с курсами IATA; настройки партнеров; пользователи; возвраты / обмены and etc);
• PostgreSQL, БД системы бронирования из блоков (расписание; блоки; рейсы; загрузка мест; тарифы; тарифные группы и классы обслуживания);
• Gearman — сервер очередей;
• REDIS — сервис кэширования данных, в первую очередь кэширование предложений, подгруженных из партнёрских систем. Например, при входе в корзину, мы формируем пул предложений от партнеров, и переходя в новые разделы корзины, подгружаем предложения из Redis, а не запрашиваем предложения от тематических партнеров. Цель — увеличение скорости работы корзины;
• PHP (Laravel). Как обычно — backend бизнес-процессов и как обычно, пока все процессы захардкорены.
Cервер оперативной базы.
Вот об этом немного подробнее, т.к. оперативная база — это особенность отрасли. Схемы про то, как данный архитектурный элемент участвует в основных процессах, даны далее (напомню, реализовано все сложнее, многие детали опущены, для упрощения понимания).
Общее назначение модуля — накапливание и актуализация информации о возможных предложениях клиентам, с целью формирования таковых (т.е. предложений по услугам) клиентам в процессах, в которых снижены требования к актуальности предложения, например — докупка услуг. Если, при прямой покупке, с e-commerce портала, важно обеспечить максимально актуальное предложение, то запрашиваем варианты напрямую в API поставщика. А если такой потребности нет, например при докупке услуг, вначале формируется рекламное предложение, которое вполне можно тянуть из промежуточной базы, снижая загрузку на основной интеграционный канал, что и делаем.
Технологии:
• MongoDB, БД услуг;
• Gearman — сервер очередей;
• PHP (Laravel).
Схемы работы единой корзины
Общая архитектурная схема
Схема намеренно упрощенная, для общего понимания. Убраны большинство интеграционных потоков, и многое иное.
Бизнес-процесс продажи в единой корзине
Прямые продажи, с сайта дистрибьютора.
1. Клиент выбрал предложение на сайте бронирования (поиск предложений из GDS — целая технология, но работа GDS, использование оперативной базы и пр., все это опустим, дабы не утонить в деталях);
2. GDS создает бронь;
3. GDS возвращает результаты;
4. Сайт бронирования перенаправил клиента в единую корзину (при продажах в стоке авиакомпании, есть другие варианты);
5. ЕК выполняет запрос в GDS на получение данных бронирования;
6. GDS возвращает параметры брони (внутренние процессы мы игнорируем);
7. ЕК формирует заказ;
8. ЕК выполняет запрос в системы поставщиков в асинхронном режиме, передавая данные бронирования;
9. Системы поставщиков формируют предложения;
10. ЕК получает данные по доступным предложениям услуг;
11. ESS передает сайту предложения по услугам;
12. Клиент выбирает услуги и переходит к оплате;
13. ЕК выполняет запросы в системы поставщиков в асинхронном режиме на бронирование услуг.
14. Система поставщика формирует брони;
15. Система поставщика возвращает брони в ЕК;
16. ЕК выполняет запросы в GDS на добавление услуг в раздел АЕ и записи SSR с номером заказа в PNR;
17. GDS обновляет раздел АЕ и добавляет запись SSR. На наше счастье, большие (увы это не про всех) GDS доросли до полноценного SOAP интерфейса и нам не нужны терминальные команды (эмуляция Green Screen);
18. GDS возвращает результат дозаписи PNR;
19. ЕК выполняет визуализацию корзины;
20. Клиент подтверждает заказ;
21. ЕК передает корзину на оплату;
22. Платежное решение выполняет оплату (тоже непростой процесс, но мы упростим, так как платежные процессы отдельная тема);
23. Платежное решение возвращает результат оплаты;
24. ЕК в асинхронном режиме выполняет запросы в системы поставщиков на подтверждения оплаты и получение документов поставщиков (ваучеров, полисов и пр.);
25. Система поставщика выпускает документы;
26. Система поставщика возвращает брони в ЕК;
27. ЕК выполняет запросы в GDS на выпуск документов (билеты, EMD);
28. GDS дописывает PNR;
29. GDS выпускает документы;
30. GDS меняет статусы PNR и услуг;
31. GDS возвращает результаты и документы;
32. ЕК дописывает документы в заказ;
33. ЕК выставляет статус — оплачено;
34. ЕК визуализирует результат клиенту;
35. ЕК выполняет запрос на информирование;
36. Модуль информирования, направляет email клиенту.
Бизнес-процесс продаж билетов из Блоков в единой корзине
1. Агент вводит параметры перелета;
2. ЕК выполняет запрос в модуль Блоки;
3. Блок рассчитывает цену, исходя из текущего курса валют и добавляет сборы агентства, чей заказ, определяет доступность выполнения бронирования, исходя из финансовых квот;
4. Блоки возвращают предложения;
5. ЕК передает предложения в API, для визуализации агенту;
6. Агент подтвердил заказ;
7. ЕК запрашивает резервирование из блока мест;
8. Резервируются места на перелет;
9. Блоки возвращают бронь;
10. ЕК формирует заказ;
11. ЕК выполняет запрос в системы поставщиков в асинхронном режиме, передавая данные бронирования;
12. Системы поставщиков формируют предложения;
13. ЕК получает данные по доступным услугам;
14. ЕК запрашивает Блоки на доступность формирования заказа на выбранную сумму;
15. Блоки проверяют баланс и квоты;
16. Блоки возвращают результат;
17. ЕК передает предложения в API, для визуализации агенту;
18. Агент выбирает услуги и переходит к оплате;
19. ЕК выполняет запросы в системы поставщиков в асинхронном режиме на бронирование услуг;
20. Система поставщика формирует брони;
21. Система поставщика возвращает брони в ЕК;
22. ЕК передает корзину в API, для визуализации агенту;
23. Агент подтверждает заказ;
24. ЕК передает корзину на оплату;
25. Платежное решение выполняет оплату (то же непростой процесс, но мы упростим);
26. Платежное решение возвращает результат оплаты;
27. ЕК, в асинхронном режиме, выполняет запросы в системы поставщиков на подтверждения оплаты и получение документов поставщиков (ваучеров, полисов и пр.);
28. Система поставщика выпускает документы;
29. Система поставщика возвращает брони в ЕК;
30. ЕК выполняет запросы в GDS на выпуск документов (билеты, EMD);
31. GDS дописывает PNR;
32. GDS выпускает документы;
33. GDS меняет статусы PNR и услуг;
34. GDS возвращает результаты и документы;
35. ЕК дописывает документы в заказ;
36. ЕК выставляет статус оплачено;
37. ЕК передает в блоки статус и изменения брони;
38. Блоки дописывают бронь и выпускает маршрут-квитанцию;
39. Блоки возвращают результат;
40. ЕК передает результаты (документы, PNR, маршрут квитанцию), в API, для визуализации агенту;
41. ЕК выполняет запрос на информирование;
42. Модуль информирования, направляет email клиенту.
В продолжение, про MongoDB...