Архитектура e-travel сервиса Movista (Анзор Кардан, HelloConf MTS-2020) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) |
||
(не показано 13 промежуточных версий этого же участника) | |||
;{{SpeakerInfo}}: {{Speaker|Анзор Кардан}} <blockquote> Как мы разработали архитектуру сервиса по продаже мультимодального маршрута. Пользователи хотят покупать готовые маршруты. При покупке билетов в онлайн, пользователям приходится самостоятельно искать способы добраться из точки А в точку Б, строить маршруты и сравнивать варианты поездки с учетом множества факторов (стоимости, времени, вида транспорта и т.д.), тратя время на планирование. На западе существует множество сервисов, облегчающих задачу (Omio, Rome2Rio, Qixxit), и мы решили создать такой же удобный сервис в России, который помогает путешественникам найти готовые маршруты в зависимости от их потребностей и возможностей. В данном докладе мы делимся опытом проектирования архитектуры нашего сервиса Movista. * Проблема - соединить три вида модальности! Разные бизнес-процессы и технологии продаж билетов, отсутствие единой точки интеграции и отраслевых стандартов, что делать? * С чего начать проектирование сервиса: ** Изучение протоколов (API) поставщиков и выявление ограничений в технологиях продаж ** Определение базовых сущностей будущего протокола (API) ** Унификация Workflow покупки 3-х видов модальности ** Разработка объектной модели и собственного протокола (API) :Как проверить что мы все сделали правильно? ;Архитектура пакетного шлюза Movista: Пакетный шлюз (ПШ) это набор из 2-х открытых сервисов - (API услуги и API пакета) и внутреннего сервиса (API калькулятора цен). Основная задача ПШ - работа с API поставщиками для выполнения бизнес-логики продаж билетов. Работа с поставщиками одного типа услуг (например Авиа) ведется в рамках одного сервиса услуги (коннектора). За маршрутизацию запросов из открытых API в соответствующие коннекторы отвечает «модель доступа к услугам». Взаимодействие сервиса услуги (коннектора) с конкретным поставщиком осуществляется через "адаптер", реализующий логику работы API поставщика. За маршрутизацию запросов из сервиса услуги к конкретному поставщику отвечает «модель доступа к поставщикам». ;Преимущества: * Возможность подключать/отключать конкретных поставщиков без влияния на основной бизнес-процесс * Возможность быстрой интеграции новых поставщиков транспортных и нетранспортных услуг. Гипотеза о востребованности сервиса по продаже мультимодальных маршрутов подтвердилась, и наша технология продаж находится в тренде e-travel рынка. </blockquote> {{VideoSection}} {{vimeoembed|240322300|800|450}} {{youtubelink|3k07mS4c0nc}}{{letscomment}} {{SlidesSection}} [[File:Архитектура e-travel сервиса Movista (Анзор Кардан, HelloConf MTS-2020).pdf|left|page=-|300px]] {{----}} [[File:{{#setmainimage:Архитектура e-travel сервиса Movista (Анзор Кардан, HelloConf MTS-2020)!.jpg}}|center|640px]] {{LinksSection}} <!-- <blockquote>[©]</blockquote> --> {{vklink|1852}} {{fblink|2651135435139461}} <references/> <!-- topub --> [[Категория:HelloConf MTS-2020]] [[Категория:Draft]]Архитектура информационных систем]] {{stats|disqus_comments=0|refresh_time=2021-08-31T16:49:39.715425|vimeo_plays=12|youtube_comments=0|youtube_plays=92}} |
Текущая версия на 10:03, 24 октября 2021
- Докладчик
- Анзор Кардан
Как мы разработали архитектуру сервиса по продаже мультимодального маршрута.
Пользователи хотят покупать готовые маршруты. При покупке билетов в онлайн, пользователям приходится самостоятельно искать способы добраться из точки А в точку Б, строить маршруты и сравнивать варианты поездки с учетом множества факторов (стоимости, времени, вида транспорта и т.д.), тратя время на планирование. На западе существует множество сервисов, облегчающих задачу (Omio, Rome2Rio, Qixxit), и мы решили создать такой же удобный сервис в России, который помогает путешественникам найти готовые маршруты в зависимости от их потребностей и возможностей. В данном докладе мы делимся опытом проектирования архитектуры нашего сервиса Movista.
- Проблема - соединить три вида модальности! Разные бизнес-процессы и технологии продаж билетов, отсутствие единой точки интеграции и отраслевых стандартов, что делать?
- С чего начать проектирование сервиса:
- Изучение протоколов (API) поставщиков и выявление ограничений в технологиях продаж
- Определение базовых сущностей будущего протокола (API)
- Унификация Workflow покупки 3-х видов модальности
- Разработка объектной модели и собственного протокола (API)
- Как проверить что мы все сделали правильно?
- Архитектура пакетного шлюза Movista
- Пакетный шлюз (ПШ) это набор из 2-х открытых сервисов - (API услуги и API пакета) и внутреннего сервиса (API калькулятора цен). Основная задача ПШ - работа с API поставщиками для выполнения бизнес-логики продаж билетов. Работа с поставщиками одного типа услуг (например Авиа) ведется в рамках одного сервиса услуги (коннектора). За маршрутизацию запросов из открытых API в соответствующие коннекторы отвечает «модель доступа к услугам». Взаимодействие сервиса услуги (коннектора) с конкретным поставщиком осуществляется через "адаптер", реализующий логику работы API поставщика. За маршрутизацию запросов из сервиса услуги к конкретному поставщику отвечает «модель доступа к поставщикам».
- Преимущества
- Возможность подключать/отключать конкретных поставщиков без влияния на основной бизнес-процесс
- Возможность быстрой интеграции новых поставщиков транспортных и нетранспортных услуг.
Гипотеза о востребованности сервиса по продаже мультимодальных маршрутов подтвердилась, и наша технология продаж находится в тренде e-travel рынка.
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Презентация
Примечания и ссылки
Plays:104 Comments:0