How Fliggy Built a Scalable Serverless Platform: Lessons for Cloud‑Native Development

Background

Fliggy's Serverless technology system was launched in April last year and has progressed for almost a year. After extensive infrastructure research and cross‑BU communication, the team defined goals to address front‑end/back‑end collaboration pain points, built the KongDao development platform and gateway, piloted business scenarios, merged multiple platforms (KongDao, Lander, DEF) into a unified FaaS platform, and now supports 14 Serverless business scenarios.

Historical Development

In 2012‑2013, Fliggy's core PC‑based business suffered from dynamic template conflicts between front‑end and back‑end teams. In 2014‑2015, a wireless backend team was created to glue data from PC to the wireless gateway Mtop, but repeated interface wrappers became unsustainable. By 2016‑2017, Mtop interface encapsulation shifted to industry back‑ends, and a Node BFF layer was introduced, yet weak front‑end operations and long‑tail machine waste prevented full BFF adoption. In 2018, platform‑level transformation turned vertical industry services into horizontal platforms, increasing middle‑layer fragmentation and raising collaboration costs, creating an urgent need for a lightweight, universal solution.

Opportunity

The rise of Serverless on public clouds offered a fragmented‑function (FaaS) approach that could solve the glue‑layer problems. With middleware teams providing container foundations and Midway Runtime support, Serverless became feasible for the Alibaba group.

Sky City Construction

The "Sky City – Serverless Technology System Construction" project was launched to build a unified Serverless stack for Fliggy's recommendation, interaction, and back‑office domains, aiming to upgrade the front‑end development model.

FaaS Platform Construction

The platform evolved through four phases:

Phase 1 – Self‑built KongDao for pilots : In June last year, the team delivered a unified management platform that encapsulated Aone APIs, providing end‑to‑end function development, service invocation, deployment, and runtime. WebIDE support enabled three pilot scenarios, yielding quantitative and qualitative performance data.

Phase 2 – Group co‑construction and multi‑platform merge : Integrated Fliggy KongDao, Taobao Lancer, and DEF, unified database structures and APIs, and enabled non‑cover releases and gray‑scale traffic routing. Functions were runnable, though usability needed improvement.

Phase 3 – Rich unified platform : Extended capabilities to support BU and product scenarios, added testing, monitoring, a generic HTTP gateway for back‑office use, defined Open‑API standards, introduced a lightweight pipeline for service orchestration, and delivered a Rax + FaaS integrated solution.

Phase 4 – Usage‑pain‑point optimization : Added function testing, quick invocation, and debug features on the function detail page, enhanced pipeline controls, and supported pre‑930 traffic switching.

KongDao Gateway Construction

Before functions can be consumed by end‑users, a gateway translates lower‑level HSF services to generic Mtop/HTTP, providing authentication, rate limiting, disaster recovery, logging, and monitoring. The gateway is in its third phase, focusing on capability enhancement.

Phase 1 : Basic integration with KongDao, delivering essential capabilities for pilot usage.

Phase 2 : Co‑built with the group to support non‑cover releases and gray‑scale traffic, pushing function metadata to remote groups and enabling monitoring.

Phase 3 : Emphasizes adaptable parameter specifications, stability, and capability expansion, completing logging, alerting, anti‑crawling, and DingTalk alarm integration.

Basic Support

FaaS Runtime : Provided by Alibaba's Node team, offering stable runtime, middleware demos, documentation, and bug‑fix communication.

Stability : Stress testing (e.g., a single pod handling 300 QPS), capacity planning, disaster‑recovery configurations, and monitoring are enforced. Deployment currently resides in Zhangbei; multi‑zone cloud deployment is planned.

Function Migration to Alibaba Cloud : Transitioned all functions from local clusters to cloud clusters, completing whitelist checks, migration, verification, and enabling unified monitoring and debugging.

Rax + FaaS Integrated Development : Defined client and cloud directory structures, built SDKs for gateway simulation and front‑end requests, added sandbox and service‑market support, and integrated with Fliggy's Clam engineering system for seamless CI/CD.

Business Scenario Serverless Support

To date, more than 22 functions have been Serverless‑enabled across domains such as high‑speed rail tours, visa Wi‑Fi, ticketing, discovery, and resource management, covering 14 pilot scenarios and generating over 10 million function calls per day in the recommendation domain.

Serverless empowers front‑end developers to build services, reduces Java and operational overhead, and streamlines interface development.

Evaluation and Future Plans

Serverless proves effective for data‑source merging, protocol conversion, and glue‑layer logic, offering an elegant bridge between cloud and client. However, development experience and stability still require collaborative improvements. The roadmap includes expanding capabilities, enhancing monitoring, and further integrating Rax + FaaS workflows.

Outlook

The team is pleased with the steady progress of Serverless under Alibaba's co‑construction and business pilots, and invites others to explore and contribute to the Serverless ecosystem.