وقتی کاربر مبدا، مقصد و تاریخ سفر را در یک سایت فروش بلیت وارد می کند، معمولا تنها چند ثانیه طول می کشد تا مجموعه ای از پروازها، ساعت ها، قیمت ها و شرایط مختلف به او نمایش داده شود. اما پشت همین جستجوی ساده، مجموعه ای از سرویس ها و فرآیندهای فنی در حال اجرا هستند.
یک موتور جستجوی پرواز باید بتواند درخواست کاربر را دریافت کند، اطلاعات را از منابع مختلف به دست آورد، داده های متفاوت را به یک ساختار قابل استفاده تبدیل کند، گزینه های مناسب را کنار هم قرار دهد و نتیجه را با سرعت و دقت بالا نمایش دهد. به همین دلیل، طراحی چنین سیستمی فقط به ساخت یک فرم جستجو محدود نمی شود. در یک معماری حرفه ای، بخش هایی مانند API، وب سرویس پرواز، GDS، پایگاه داده، سیستم کش، سرویس قیمت گذاری، موتور فیلتر و مرتب سازی و سیستم رزرواسیون باید بتوانند هماهنگ با یکدیگر کار کنند.
موتور جستجوی پرواز چیست؟
موتور جستجوی پرواز بخشی از یک سامانه فروش یا رزرواسیون است که درخواست سفر کاربر را دریافت و گزینه های قابل ارائه را از منابع مختلف جمع آوری می کند. این منابع می توانند شامل ایرلاین ها، GDS ها، وب سرویس های تامین کنندگان یا سایر سرویس های توزیع اطلاعات پرواز باشند.
در صنعت هوانوردی، GDS ها اطلاعاتی مانند قیمت و موجودی صندلی را از ایرلاین ها جمع آوری کرده و در اختیار آژانس های مسافرتی و برخی پلتفرم های فروش قرار می دهند. بنابراین یک سیستم جستجوی حرفه ای معمولا فقط با یک منبع اطلاعاتی کار نمی کند. هدف اصلی این است که داده های چند منبع را دریافت و به شکلی یکپارچه در اختیار کاربر قرار دهد.
معماری موتور جستجوی پرواز از چه بخش هایی تشکیل می شود؟
برای طراحی موتور جستجوی پرواز ابتدا باید مسیر حرکت اطلاعات مشخص شود. کاربر یک درخواست ارسال می کند، سیستم آن را پردازش می کند و سپس درخواست به منابع مناسب ارسال می شود. پس از دریافت پاسخ، داده ها باید پردازش شوند تا نتایج قابل مقایسه باشند. در نهایت اطلاعات مورد نیاز در رابط کاربری نمایش داده می شود.
به صورت ساده می توان این جریان را چنین در نظر گرفت:
درخواست کاربر ← لایه جستجو ← سرویس های تامین کننده ← پردازش و یکپارچه سازی داده ← فیلتر و مرتب سازی ← نمایش نتایج ← قیمت گذاری و تایید نهایی ← رزرو
هر کدام از این مراحل وظیفه متفاوتی دارند و ضعف در هر بخش می تواند روی سرعت، دقت یا تجربه کاربر تاثیر بگذارد.
مرحله اول؛ دریافت درخواست کاربر
همه چیز از اطلاعاتی شروع می شود که کاربر در فرم جستجو وارد می کند. مبدا، مقصد، تاریخ رفت، تاریخ برگشت، تعداد مسافران و نوع سفر از مهم ترین پارامترها هستند. اما سیستم نباید این اطلاعات را بدون پردازش به منابع مختلف ارسال کند. ابتدا باید ورودی ها اعتبارسنجی شوند و به فرمت مورد نیاز سرویس های مقصد تبدیل شوند. برای مثال، کد فرودگاه، قالب تاریخ، تعداد مسافران و نوع کابین باید به شکلی استاندارد در درخواست قرار بگیرند. این کار احتمال خطا و ارسال درخواست های نامعتبر را کاهش می دهد.
اتصال به منابع اطلاعات پرواز
بعد از آماده شدن درخواست، سیستم باید بتواند اطلاعات را از منابع مختلف دریافت کند. این بخش یکی از مهم ترین قسمت های معماری یک موتور جستجوی پرواز است. در این مرحله ممکن است سیستم از GDS، API مستقیم ایرلاین یا وب سرویس های تامین کنندگان استفاده کند. هر منبع ممکن است ساختار داده، فرمت پاسخ و قوانین متفاوتی داشته باشد. استانداردسازی ارتباط میان سیستم های مختلف در صنعت هوانوردی اهمیت زیادی دارد. IATA نیز روی ایجاد استانداردهای API و مدل های مشترک داده برای افزایش سازگاری میان سیستم ها تمرکز دارد.
نقش وب سرویس پرواز در جستجوی بلیت
وب سرویس پرواز یکی از اجزای مهم در اتصال سامانه فروش به منابع اطلاعاتی پرواز است. این سرویس می تواند امکان دریافت اطلاعاتی مانند برنامه پرواز، نرخ و ظرفیت را برای سیستم مقصد فراهم کند. در معماری موتور جستجوی پرواز، لایه وب سرویس بهتر است از بخش رابط کاربری جدا باشد. در این حالت اگر منبع اطلاعاتی تغییر کند، لازم نیست کل سامانه جستجو بازطراحی شود. برای مثال، یک آژانس می تواند اطلاعات چند تامین کننده را از طریق لایه های مختلف دریافت کند و نتیجه را در قالبی یکسان به موتور جستجو تحویل دهد. این رویکرد مدیریت منابع و توسعه آینده سیستم را ساده تر می کند.
GDS چه نقشی در معماری سیستم دارد؟
GDS یکی از منابع مهم توزیع اطلاعات پرواز در صنعت سفر است. این سیستم ها اطلاعاتی مانند برنامه پرواز، نرخ و موجودی را در اختیار کانال های توزیع و آژانس های مسافرتی قرار می دهند. در معماری موتور جستجوی پرواز، اتصال به GDS به این معنا نیست که تمام منطق سیستم باید به ساختار یک GDS وابسته باشد.
طراحی مناسب باید یک لایه میانی داشته باشد تا داده دریافتی از منابع مختلف را به ساختار استاندارد داخلی تبدیل کند. این موضوع زمانی اهمیت بیشتری پیدا می کند که یک سامانه با چند GDS یا چند تامین کننده کار کند. در چنین شرایطی، وابستگی مستقیم بخش های مختلف نرم افزار به یک منبع خاص می تواند توسعه و نگهداری سیستم را دشوار کند.
نرمال سازی داده ها؛ بخش مهمی که کاربر نمی بیند
یکی از چالش های اصلی طراحی موتور جستجوی پرواز، تفاوت ساختار داده های دریافتی از منابع مختلف است. ممکن است یک تامین کننده اطلاعات شرکت هواپیمایی را با یک ساختار ارسال کند و منبع دیگری همان اطلاعات را با ساختار متفاوتی ارائه دهد. حتی نحوه نمایش مدت پرواز، توقف، قوانین نرخ، بار مجاز و کلاس نرخی نیز ممکن است متفاوت باشد.
چبه همین دلیل یک لایه نرمال سازی در سیستم ضروری است. این لایه داده های دریافتی را به یک ساختار داخلی تبدیل می کند تا سایر بخش های سامانه مجبور نباشند برای هر تامین کننده منطق جداگانه داشته باشند. IATA نیز یکی از اهداف مدل داده صنعت هوانوردی را ایجاد واژگان و تعاریف مشترک برای افزایش سازگاری میان سیستم های مختلف معرفی می کند.
ترکیب و مقایسه نتایج پرواز
بعد از دریافت داده از منابع مختلف، سیستم باید بتواند نتایج را با یکدیگر مقایسه و ترکیب کند. در این مرحله ممکن است چند منبع برای یک مسیر مشخص، پرواز مشابهی را ارائه کنند. سیستم باید بتواند گزینه ها را شناسایی کند و از نمایش نتایج تکراری جلوگیری شود. همچنین لازم است اطلاعاتی مانند ساعت حرکت، ساعت رسیدن، مدت سفر، تعداد توقف، ایرلاین، نوع نرخ و قیمت در ساختار مشخصی قرار بگیرند. اینجاست که موتور جستجوی پرواز از یک سیستم ساده دریافت اطلاعات به یک لایه تصمیم گیری برای نمایش نتایج تبدیل می شود.
فیلتر و مرتب سازی نتایج چگونه انجام می شود؟
نمایش همه نتایج بدون امکان فیلتر کردن، تجربه مناسبی برای کاربر ایجاد نمی کند. به همین دلیل سیستم باید بتواند نتایج را بر اساس معیارهای مختلف پردازش کند. کاربر ممکن است بخواهد فقط پروازهای بدون توقف را ببیند، کمترین قیمت را پیدا کند یا پروازها را بر اساس ساعت حرکت مرتب کند. در این مرحله بهتر است فیلترها بعد از یکپارچه سازی داده ها اجرا شوند. در غیر این صورت ممکن است هر تامین کننده منطق متفاوتی برای فیلتر داشته باشد و نتیجه نهایی قابل پیش بینی نباشد.
قیمت نمایش داده شده همیشه قیمت نهایی نیست
یکی از نکات مهم در معماری موتور جستجوی پرواز، تفاوت میان نتیجه اولیه جستجو و قیمت قابل رزرو است. اطلاعات قیمت و موجودی ممکن است تغییر کند. به همین دلیل سیستم نباید صرفا به قیمت دریافت شده در مرحله ابتدایی جستجو اعتماد کند. در بسیاری از معماری ها، بعد از انتخاب یک گزینه، مرحله جداگانه ای برای بررسی مجدد قیمت و موجودی انجام می شود. این فرآیند کمک می کند قبل از ایجاد رزرو، اطلاعات مورد استفاده برای خرید دوباره بررسی شود. این مسئله برای سامانه های فروش بلیت اهمیت زیادی دارد، زیرا نمایش یک قیمت و عدم امکان رزرو آن می تواند اعتماد کاربر را کاهش دهد.
کش کردن اطلاعات؛ چگونه سرعت جستجو افزایش پیدا می کند؟
یکی از چالش های مهم سیستم های جستجوی پرواز، زمان پاسخ است. اگر سیستم برای هر درخواست مجبور باشد به تمام منابع متصل شود و منتظر پاسخ همه آنها بماند، سرعت جستجو کاهش پیدا می کند. استفاده صحیح از Cache می تواند در چنین شرایطی مفید باشد. برخی اطلاعات که برای مدت مشخصی قابل ذخیره هستند می توانند در حافظه یا لایه کش قرار بگیرند تا درخواست های مشابه سریع تر پاسخ داده شوند.
البته اطلاعات حساس مانند قیمت و موجودی باید با دقت بیشتری مدیریت شوند. کش کردن اطلاعات قدیمی بدون در نظر گرفتن زمان اعتبار آن می تواند باعث نمایش داده های نادرست شود. بنابراین طراحی کش فقط برای افزایش سرعت نیست؛ بلکه باید بین سرعت، تازگی داده و هزینه درخواست ها تعادل ایجاد کند.
سیستم رزرواسیون آنلاین در کجای معماری قرار می گیرد؟
جستجو فقط یکی از مراحل خرید بلیت است. پس از انتخاب پرواز، سیستم باید بتواند کاربر را وارد فرآیند رزرو و خرید کند. در یک سیستم رزرواسیون آنلاین، اطلاعات انتخاب شده باید به مرحله بررسی قیمت، ایجاد رزرو، دریافت اطلاعات مسافر، پرداخت و صدور بلیت منتقل شود. بنابراین بهتر است موتور جستجو و سیستم رزرواسیون از نظر منطقی به یکدیگر متصل باشند، اما وظایف آنها کاملا تفکیک شده باشد.
این تفکیک باعث می شود توسعه و مقیاس پذیری سیستم ساده تر شود و تغییر در بخش جستجو لزوما فرآیندهای رزرو و صدور را تحت تاثیر قرار ندهد. سیتی نت نیز در حوزه راه اندازی سایت های رزرو آنلاین بلیت، بر قابلیت هایی مانند جستجوی سریع، نمایش اطلاعات پرواز و امکان رزرو آنلاین تاکید کرده است.
API Gateway چه نقشی دارد؟
وقتی تعداد منابع و سرویس های متصل افزایش پیدا می کند، مدیریت ارتباط میان آنها دشوارتر می شود. API Gateway می تواند به عنوان یک نقطه کنترل برای دریافت و ارسال درخواست ها عمل کند. احراز هویت، کنترل دسترسی، مدیریت نرخ درخواست ها، ثبت لاگ و مسیریابی درخواست ها از جمله وظایفی هستند که می توانند در این لایه مدیریت شوند.
استانداردهای API مدرن صنعت هوانوردی نیز با هدف ایجاد ارتباط سازگارتر میان سیستم های مختلف توسعه پیدا کرده اند. IATA در برنامه Open API خود استانداردها و بهترین روش هایی مانند REST API و GraphQL API را دنبال می کند.
مدیریت خطا و قطعی منابع
هیچ سرویس خارجی همیشه در دسترس نیست. ممکن است یک GDS، API یا تامین کننده برای مدت کوتاهی پاسخ ندهد یا زمان پاسخ آن افزایش پیدا کند. یک معماری مناسب نباید با از دسترس خارج شدن یک منبع، کل فرآیند جستجو را متوقف کند. برای این شرایط می توان از Timeout، Retry کنترل شده، Circuit Breaker و سیستم ثبت خطا استفاده کرد. هدف این نیست که کاربر تمام مشکلات فنی پشت سیستم را ببیند. هدف این است که حتی در صورت اختلال یک منبع، سامانه تا حد امکان بتواند از سایر منابع نتیجه دریافت کند.
مقیاس پذیری موتور جستجوی پرواز
تعداد درخواست های جستجو در سایت های فروش بلیت می تواند در ساعات مختلف تغییر زیادی داشته باشد. بنابراین معماری باید به شکلی طراحی شود که در زمان افزایش ترافیک بتواند منابع بیشتری در اختیار سرویس جستجو قرار دهد. استفاده از معماری سرویس گرا، Load Balancer، پردازش غیرهمزمان و زیرساخت قابل توسعه می تواند به مدیریت این حجم کمک کند. البته انتخاب معماری باید بر اساس اندازه کسب و کار انجام شود. یک آژانس کوچک لزوما به همان زیرساختی نیاز ندارد که یک پلتفرم بزرگ فروش آنلاین بلیت به آن نیاز دارد.
امنیت در معماری سیستم جستجوی پرواز
سرعت بالا بدون امنیت کافی ارزش زیادی ندارد. سیستم باید در تمام مسیر ارتباط میان کاربر، سامانه فروش و تامین کنندگان، کنترل های امنیتی مناسبی داشته باشد. استفاده از ارتباط رمزنگاری شده، احراز هویت APIها، مدیریت صحیح کلیدهای دسترسی، کنترل سطح دسترسی و ثبت رویدادهای مهم از مواردی هستند که باید از مرحله طراحی در نظر گرفته شوند. همچنین اطلاعات حساس کاربران نباید بیشتر از میزان مورد نیاز ذخیره یا در لاگ های عمومی ثبت شوند.
تفاوت موتور جستجو با سیستم رزرواسیون
این دو مفهوم گاهی با یکدیگر اشتباه گرفته می شوند، در حالی که وظایف متفاوتی دارند. موتور جستجو مسئول پیدا کردن و ارائه گزینه های مناسب بر اساس درخواست کاربر است. سیستم رزرواسیون وظیفه مدیریت مراحل بعدی مانند ایجاد رزرو، ثبت اطلاعات مسافر، پرداخت و در نهایت فرآیند صدور را بر عهده دارد. در یک سامانه حرفه ای، این بخش ها باید با یکدیگر ارتباط داشته باشند، اما معماری آنها نباید به شکلی باشد که همه وظایف در یک بخش متمرکز شوند.
یک معماری مناسب چه ویژگی هایی دارد؟
طراحی یک موتور جستجوی پرواز موفق فقط به تعداد منابع متصل شده بستگی ندارد. کیفیت معماری زمانی مشخص می شود که سیستم بتواند با سرعت مناسب، داده های قابل اعتماد را از منابع مختلف دریافت و پردازش کند. قابلیت توسعه، تحمل خطا، امنیت، نرمال سازی داده ها، مدیریت کش، مقیاس پذیری و امکان اضافه کردن تامین کننده جدید از ویژگی هایی هستند که باید از ابتدا در نظر گرفته شوند. از طرف دیگر، معماری باید با نیاز کسب و کار هماهنگ باشد. ساختن یک زیرساخت بیش از حد پیچیده برای یک آژانس کوچک می تواند هزینه و نگهداری غیرضروری ایجاد کند.
برای طراحی موتور جستجوی پرواز از کجا شروع کنیم؟
اول باید مشخص شود سیستم قرار است برای چه کسب و کاری استفاده شود. نیاز یک آژانس مسافرتی با یک OTA بزرگ یا یک پلتفرم متصل به چندین تامین کننده یکسان نیست. در مرحله بعد، منابع اطلاعاتی، روش اتصال به آنها، ساختار داده داخلی، فرآیند جستجو، نحوه فیلتر و مرتب سازی و مسیر انتقال کاربر از جستجو تا رزرو مشخص می شود. پس از آن باید معیارهایی مانند زمان پاسخ، تعداد درخواست قابل پردازش، نرخ خطا و کیفیت نتایج تعریف شوند. این شاخص ها به تیم فنی کمک می کنند عملکرد واقعی سیستم را بعد از راه اندازی نیز ارزیابی کند.
چرا معماری درست روی تجربه کاربر تاثیر می گذارد؟
کاربر معمولا چیزی از API، GDS یا سرویس های پشت سیستم نمی بیند. چیزی که برای او اهمیت دارد این است که پرواز مورد نظر را سریع پیدا کند، قیمت قابل اعتماد ببیند و بدون خطای غیرمنتظره وارد فرآیند رزرو شود. بنابراین معماری فنی در نهایت باید به یک تجربه ساده برای کاربر منجر شود. سرعت جستجو، کیفیت نتایج، به روز بودن اطلاعات، امکان فیلتر کردن، نمایش شفاف شرایط پرواز و انتقال بدون مشکل به مرحله رزرو، خروجی قابل مشاهده یک معماری مناسب هستند.
نقش فناوری در توسعه موتورهای جستجوی پرواز
با افزایش تعداد کانال های فروش و منابع داده، معماری سیستم های جستجوی پرواز نیز به سمت ساختارهای منعطف تر حرکت می کند. APIهای استاندارد، معماری ماژولار و مدل های داده مشترک می توانند اتصال میان بازیگران مختلف صنعت را ساده تر کنند. IATA نیز در مسیر مدرن سازی فناوری هوانوردی بر معماری های ماژولار، استانداردهای API و حرکت به سمت مدل های مبتنی بر Offers و Orders تاکید دارد.
برای یک آژانس یا پلتفرم فروش بلیت، این تغییرات به معنای یک نکته مهم است: زیرساخت جستجو نباید فقط برای نیاز امروز ساخته شود. امکان اضافه کردن منبع جدید، تغییر تامین کننده، توسعه کانال های فروش و اتصال به سرویس های جدید باید از ابتدا در طراحی دیده شود. در نهایت، موتور جستجوی پرواز موفق سیستمی نیست که فقط تعداد زیادی پرواز را نمایش دهد؛ بلکه سیستمی است که بتواند اطلاعات متنوع را با سرعت، دقت و ساختار مناسب به یک تجربه قابل اعتماد برای خرید تبدیل کند.
